Error 1789 trust relationship failed: rebuilding a broken secure channel

Fix it now

Microsoft publishes 1789 as “The trust relationship between this workstation and the primary domain failed”, with the sign-in message adding that you can sign in using a local user or cached credentials. Despite the wording it is not about a trust between domains: this computer’s account password no longer matches the copy in Active Directory. Repair it in place rather than rejoining.

nltest /sc_query:corp.example.com
nltest /sc_reset:corp.example.com

1. Sign in with a local administrator account, or a domain account that still has cached credentials.
2. Test the channel. Microsoft’s documented output for a broken one is Trusted DC Connection Status Status = 5 0x5 ERROR_ACCESS_DENIED.
3. Reset it with nltest /sc_reset:<domain>, or from PowerShell with Test-ComputerSecureChannel -Repair -Credential *. Both are Microsoft’s documented repairs for this case.
4. Restart the computer, which Microsoft gives as the step after the reset, then sign in with a domain account.

Test-ComputerSecureChannel -Repair requires membership of the local Administrators group on the machine you are repairing, and the credential you supply needs rights over the computer object in the domain.

If a domain sign-in succeeds after the restart, you are done. If not, the next section covers what the secure channel is and the four ways the two copies drift apart.

Why it happens

Every domain-joined computer holds an account in Active Directory with a password, exactly as a user does. Windows keeps its copy as an LSA secret; the directory keeps its copy on the computer object, timestamped as pwdLastSet. Net Logon changes the password on a schedule and writes both. The two copies must agree for the machine to open a secure channel to a domain controller, and that channel is what carries authentication on the computer’s behalf. Without it the machine cannot ask a domain controller to authenticate anybody, including you.

Microsoft describes the failure in two directions and they are worth naming separately, because the remedy differs. Either the client holds an older password than Active Directory, or Active Directory holds an older password than the client. The first is the common case and is what a snapshot revert, a bare-metal restore, a system restore point, an unexpected shutdown or a non-persistent virtual desktop produces: the machine’s copy goes back in time while the directory keeps the newer one.

The corroborating evidence sits on the machine and on the domain controller. Microsoft documents Net Logon event 3210 for this scenario: this computer could not authenticate with the named domain controller and therefore might deny logon requests, which may be caused by another computer on the same network using the same name or by the password for this computer account not being recognised. In the Net Logon log the same failure reads as a session setup that cannot authenticate, followed by “new password is bad, try old one”.

That last line is why some of these heal themselves. Windows keeps a current and a previous password, so a short-lived mismatch can be forgiven. Outside that window the channel fails for good, and you see 1789 at the sign-in screen. Two neighbouring codes narrow it further: 1787, ERROR_NO_TRUST_SAM_ACCOUNT, is “The security database on the server does not have a computer account for this workstation trust relationship”, and 1786, ERROR_NO_TRUST_LSA_SECRET, is “The workstation does not have a trust secret”.

Full reference

The codes

The two directions, and how to tell them apart

That second row is the one people miss. If the domain controller you are repairing against has itself gone back in time, or if the computer object has not replicated, a successful reset writes a password that the next domain controller the machine talks to will not recognise. Where the estate has more than one domain controller, target a healthy one explicitly with Reset-ComputerMachinePassword -Server <dc> and confirm the change has replicated before declaring victory.

The repair commands

What not to do first

• Do not leave the domain and rejoin as an opening move. Rejoining under the same name after removing the object typically produces a new object with a new security identifier, so memberships and anything keyed to the old identifier are lost. A repair keeps the original object.
• Do not delete the computer object to make the repair work. That converts a five-minute fix into a rebuild.
• Do not disable the machine’s automatic password change to stop this recurring. It is a security decision dressed as a convenience, and it does not address why the two copies diverged.
• Do not repair against whichever domain controller answers first if you already know one of them was restored.

Checking the name registry values

Microsoft’s secure channel guidance includes a check that is easy to skip and occasionally the whole answer: confirm that the ComputerName value under the ComputerName key, and the hostname value under the Tcpip parameters key, both hold the actual computer name rather than a fully qualified one. A machine whose name values disagree with what it registered in the directory behaves exactly like a machine whose password is wrong, and no number of resets will settle it.

Activation is a separate system

A reverted or restored machine often shows an activation prompt at the same time as this error, and the two get bundled together. They are unrelated. Repairing the secure channel does not activate Windows, and re-entering a product key does not repair the secure channel. Fix them independently, and be suspicious of any advice that treats one as the cure for the other.

Every code this article covers

Confirm the fix worked

1. nltest /sc_query:<domain> names a domain controller and reports success rather than ERROR_ACCESS_DENIED.
2. Test-ComputerSecureChannel returns true without the repair switch.
3. A domain user with no cached credentials signs in at the console after a restart.
4. No new Net Logon event 3210 appears on the machine over a working day.
5. gpupdate /force completes on the repaired machine.

Questions people ask about this