Trust relationship failed: error 0xC000018D between the PC and the domain

Fix it now

“The trust relationship between this workstation and the primary domain failed” means the computer’s own account password no longer matches the copy Active Directory holds. No user account is at fault and no data is lost. In most cases the repair takes two commands and does not require leaving the domain.

nltest /sc_query:contoso.local
Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

1. Sign in with a local administrator account. The domain account will not work until this is fixed.
2. Confirm a domain controller is actually reachable with nltest /dsgetdc:contoso.local. If that fails, the fault is network or DNS and none of the rest applies.
3. Read the nltest /sc_query output. Microsoft documents this failure as returning “Status = 5 0x5 ERROR_ACCESS_DENIED” from that command.
4. Repair the secure channel with the third command, supplying a domain account with rights to reset the computer object.
5. If that cmdlet is unavailable, use Reset-ComputerMachinePassword -Server dc01.contoso.local -Credential (Get-Credential) instead.
6. Reboot and sign in with the domain account.

Check the System log for NETLOGON Event 3210 and for a NlSessionSetup entry reading “cannot I_NetServerAuthenticate 0xc0000022”. Microsoft names both as symptoms of this fault, and they confirm the diagnosis before you change anything.

If a domain sign-in works, you are done. If the machine has no domain option at all, the next section explains why, and it is not something a command fixes.

Why it happens

Joining a domain creates an object in Active Directory for the machine itself, with a password the machine generates and changes on its own schedule. That password secures the secure channel: the private conversation between the machine and a domain controller that carries every Kerberos and NTLM operation the machine performs on its own behalf. Break it and nothing that depends on the domain works, including the logon you are trying to perform.

Microsoft names two causes, and they are opposites of each other. Either the client has an older password than the directory holds, or the directory has an older password than the client – which happens when a domain controller is restored to a previous state, or when replication is not working. Restoring a machine from an image or snapshot older than its last password change produces the first. Deleting and recreating the computer object gives the machine an identity it knows nothing about. Cloning without generalising leaves two computers sharing one object, each changing the password out from under the other.

It is worth separating this from the codes that travel with it, because two of them are not about the machine password at all. 0x8007051F is Win32 1311, “There are currently no logon servers available to service the logon request.” 0x8007054B is Win32 1355, “The specified domain either does not exist or could not be contacted.” A laptop on a home network with no VPN, or a machine whose DNS points at a public resolver rather than a domain controller, produces very similar-looking failures for an entirely different reason and no amount of secure channel repair will help.

Full reference

The codes, and which are about the trust at all

If you want a code you can quote to somebody, use 0x800706FD. Its published wording is the same sentence the user sees on the logon screen, so nobody has to take anyone’s word for what it means. 0xC000018D turns up in the same situation and Microsoft publishes no text for it, so describe it by what it accompanies rather than asserting a meaning.

What Microsoft names as the symptoms

• The message “The trust relationship between this workstation and the primary domain failed. You can sign in using a local user or cached credentials.”
• NETLOGON Event 3210 in the System event log.
• An error log entry reading “NlSessionSetup: Session setup: cannot I_NetServerAuthenticate 0xc0000022”.
• nltest /sc_query:<domain> returning “Trusted DC Connection Status Status = 5 0x5 ERROR_ACCESS_DENIED”.

Those four together are as close to a definitive diagnosis as this fault offers, and they take two minutes to collect. Collect them before you start changing things, because the repair looks the same whether or not it was the right repair.

Joining a domain: which editions can

Microsoft publishes the list of client editions that can join a domain: Enterprise, Enterprise N, Pro, Pro N, Pro Education, Pro Education N, Pro for Workstations, and Pro N for Workstations. Home is not on it. If System Properties has no domain option at all – the field absent rather than greyed out – that is what you are looking at, and no registry change or third-party tool alters it.

Repairing rather than rejoining

Repair against a controller you trust to be current. If the directory’s copy of the password is the stale one because a controller was restored or replication is broken, repairing against that controller writes a value that will be overwritten, and the machine falls out again a few hours later looking like an intermittent fault.

Every code this article covers

Confirm the fix worked

1. Test-ComputerSecureChannel returns True.
2. Sign in with a domain account rather than the local administrator.
3. nltest /sc_query:contoso.local reports a healthy connection to a named controller.
4. Open a domain resource that failed earlier, such as a mapped drive, and confirm it opens without prompting.
5. Check the System log the following day for a repeat, which would point at replication rather than at this machine.

Questions people ask about this