Fix STATUS_NOLOGON_INTERDOMAIN_TRUST_ACCOUNT (0xC0000198)

Cause 1: Stale or Corrupt Computer Account in Active Directory

This is the big one. Nine times out of ten, 0xC0000198 hits because the computer account in AD doesn't match what's stored locally on the machine. This happens when a domain admin renames a computer, restores it from a backup taken before a domain join, or when two machines somehow end up with the same name. The error shows up right at login—before you even get a desktop—on Windows 10, Windows 11, Server 2016, 2019, or 2022.

The fix is straightforward: disjoin the machine from the domain, reboot, rejoin. Don't waste time mucking about with ADSI Edit on the first pass—just do the disjoin/rejoin dance.

Step-by-step fix (assuming you have local admin access):

1. Boot the machine. You won't get past login with the domain user, so use the local administrator account. If you don't know the local admin password, you'll need to reset it offline or use a recovery tool—that's a whole other article.
2. Open System Properties (Win + Pause, or sysdm.cpl from an admin command prompt).
3. Go to the Computer Name tab, click Change.
4. Select Workgroup, type any workgroup name (e.g., WORKGROUP), click OK. You'll be prompted for local admin credentials again.
5. Reboot.
6. After reboot, log in as local admin again. Open System Properties, click Change, select Domain, enter your domain name. Provide domain admin credentials when prompted.
7. Reboot again. Log in with the domain user—it should work now.

If you don't have the local admin password and can't reset it, you're stuck. Next time, store local admin creds in a password manager—don't rely on the domain for everything.

Cause 2: Duplicate or Misconfigured Trust Account in AD

Sometimes the problem is in Active Directory itself. A computer account might have gotten orphaned or has incorrect attributes—specifically, the userAccountControl flag. Trust accounts have a flag value that tells AD they're interdomain trust accounts, not normal computer accounts. If someone manually changed that flag through ADSI Edit or a script, or if the account was created as a trust account by mistake, you'll get this error.

This is less common than a stale account, but I've seen it when a junior admin tried to create a trust between domains and botched it.

Fix: Reset the machine account password and verify attributes

1. From a domain-joined machine, open an elevated PowerShell or Command Prompt.
2. Run Netdom resetpwd /Server:<DomainController> /UserD:<DomainAdmin> /PasswordD:*. Replace the placeholders with your DC name and domain admin account. Enter the password when prompted.
3. Alternatively, from the machine itself (if you can get local admin access), run nltest /sc_reset:<DomainName> to force a secure channel reset. That often bypasses the trust account flag check.
4. If that doesn't work, open ADSI Edit on a DC. Connect to the default naming context. Navigate to the computer account in question, right-click, Properties. Find userAccountControl. The value for a normal computer account should be 4096 (WORKSTATION_TRUST_ACCOUNT). If it's anything else—like 532480 for a trust account—change it to 4096. Click OK, reboot the affected machine, test login.

Don't go messing with ADSI Edit unless you're comfortable. One wrong attribute change can break more than just this one machine.

Cause 3: Machine Account Password Expired or Out of Sync

Every domain-joined machine has a password that rotates automatically every 30 days by default. If the machine was offline for longer than that (e.g., a laptop that sat in a drawer for two months), the password stored locally no longer matches what AD expects. The login process sees the mismatch and throws 0xC0000198 because it interprets the old password as a trust account credential.

This is especially common with VPN-joined machines that never connected back to the domain during the grace period.

Fix: Force a password sync without rejoining the domain

1. Boot to a local admin account (same as above).
2. Open an elevated Command Prompt.
3. Run nltest /sc_query:<DomainName>. If it returns anything other than success, proceed.
4. Run nltest /sc_reset:<DomainName>. This forces the machine to negotiate a new password with the domain controller.
5. If that fails, the account might be too far out of sync. In that case, use the Reset Account option in ADUC on the DC: right-click the computer account, select Reset Account, then from the affected machine, disjoin and rejoin as described in Cause 1.

One quick tip: if you're managing a fleet, set DomainMember: MaximumMachineAccountPasswordAge via Group Policy to a lower value—say 7 days—to reduce the chance of this happening on machines that go offline often.

Quick-Reference Summary Table

Bottom line: 0xC0000198 is almost always a trust account mismatch. Skip the registry edits and third-party tools—they won't fix the core issue. Disjoin and rejoin. If that doesn't work, check the AD flags. That's it.