Windows: The trust relationship between this workstation and the primary domain failed (1789)

Hi, it's BlueByte. A user tries to sign in on Monday morning and Windows answers with The trust relationship between this workstation and the primary domain failed. Their password is fine, the network is fine, and nobody touched the machine over the weekend — or so it seems. Nothing is broken on the domain side and no data is lost; the computer's own account password has drifted out of step with Active Directory. We'll walk through what the secure channel is, the three ways it breaks, the commands that confirm it, a one-line repair that needs no rejoin, and how to keep it from coming back.

What the message means: a computer account password that no longer matches

Every domain-joined computer has its own account and password in Active Directory, and the Netlogon service uses them to build a secure channel to a domain controller before any user is authenticated. The Windows error behind the dialog is ERROR_TRUSTED_RELATIONSHIP_FAILURE, 1789 (0x6FD). By default the computer submits a new password every 30 days — the "Domain member: Maximum machine account password age" policy — and the DC records it. If the machine later presents a password the DC has not seen, the channel cannot be built and every domain sign-in stops at this dialog. If the same user could still sign in with the network cable out, that was cached credentials, not a working trust.

A close cousin is The security database on the server does not have a computer account for this workstation trust relationship. — ERROR_NO_TRUST_SAM_ACCOUNT, 1787 (0x6FB). That one means the account itself is gone, and it needs a different fix.

Three ways the password drifts: snapshots, clones, and reset accounts

The machine was reverted to an older state. A VM snapshot, a backup restore, or a non-persistent image discards everything written after the capture — including a machine password change. Microsoft's guidance on non-persistent VDI says it plainly: "a password change that was made during normal operations would be lost as soon as the session ends." The DC has the new password, the reverted machine the old one.

A clone joined with the same name. Two installations sharing one computer account fight over the password; the policy documentation says to "give the two installations different computer names" instead. The most recent join wins and the other machine is locked out.

Someone reset or deleted the account in AD. "Reset Account" in Active Directory Users and Computers puts a known password on the account; deleting it produces 1787 instead of 1789.

One myth to drop: a machine powered off for months does not break. The computer initiates the change, not the DC; the docs say the policy exists so organizations can "stockpile pre-built computers that are put into production months later" without rejoining.

First, confirm the secure channel is actually broken

Sign in with a local administrator account (.\Administrator or your local admin), open PowerShell as administrator, and ask Netlogon directly:

Test-ComputerSecureChannel -Verbose

VERBOSE: Performing operation "Test-ComputerSecureChannel" on Target "WS-042".
False

False confirms the break. nltest shows the same with the status code attached, which tells 1789 and 1787 apart:

nltest /sc_query:corp.example.com

A healthy machine prints Trusted DC Connection Status Status = 0 0x0 NERR_Success; anything else is the break, and the named code is your cause. With RSAT installed, compare the DC's view of the password with the snapshot or restore date:

Get-ADComputer WS-042 -Properties PasswordLastSet | Select-Object Name, PasswordLastSet

Name    PasswordLastSet
----    ---------------
WS-042  2026-09-14 08:12:41

A PasswordLastSet later than the snapshot is the whole story: the DC saw a change the machine no longer remembers.

Fix 1: repair the channel in place — no rejoin needed

One cmdlet rebuilds the channel; it needs local administrator rights and a domain account allowed to reset the computer's password:

$cred = Get-Credential CORP\svc-join
Test-ComputerSecureChannel -Repair -Credential $cred -Verbose

VERBOSE: Performing operation "Test-ComputerSecureChannel" on Target "WS-042".
True

-Repair "removes and then rebuilds the channel established by the NetLogon service" — what nltest /sc_reset does too. To set a fresh password explicitly instead, the sibling cmdlet does that and returns nothing on success:

Reset-ComputerMachinePassword -Server dc01.corp.example.com -Credential CORP\svc-join

Sign out and back in with a domain account; the cmdlet lists no restart requirement. Profiles are untouched because the computer's identity never changed — only its password did.

Fix 2: when the account is gone (1787), rejoin the domain

A reset cannot recreate a deleted account, so this case is leave-and-rejoin. Since August 2024, domain-join hardening requires -Server to be the DC's FQDN:

$cred = Get-Credential CORP\svc-join
Remove-Computer -UnjoinDomainCredential $cred -WorkgroupName WORKGROUP -Force -Restart
# after the reboot, as local administrator:
Add-Computer -DomainName corp.example.com -Server dc01.corp.example.com -Credential $cred -Restart

Add-Computer "creates a domain account if the computer is added to the domain without an account", so the object returns under the same name. If Remove-Computer errors because it cannot find the account to disable, the account is already gone — carry on with Add-Computer after the restart. Domain profiles survive: the domain SIDs are unchanged, so C:\Users\jane maps back to the same account.

A real case: a snapshot rolled back over a Monday password change

An accounting VM had a snapshot taken on 5 September before a software upgrade. Netlogon rotated the machine password on 14 September at 08:12; the upgrade failed on the 15th and the VM was reverted to the snapshot. Monday's sign-in produced the 1789 dialog. Get-ADComputer showed PasswordLastSet of 14 September — nine days after the snapshot — which explained everything. The admin signed in as the local administrator, ran Test-ComputerSecureChannel -Repair -Credential CORP\svc-join, got True, and the user signed in on the next attempt. Under five minutes, no rejoin, no profile migration.

Check it end to end and keep it from drifting again

After either fix, confirm from a domain sign-in on the machine:

Test-ComputerSecureChannel
nltest /sc_query:corp.example.com

True and NERR_Success together mean the channel is up. To prevent a repeat: never revert a domain-joined VM to a snapshot older than the machine password age, and prune snapshots past 30 days; before capturing a golden image or a long-lived snapshot, force a fresh password with nltest /sc_change_pwd:corp.example.com so the captured state is current; sysprep clones so each gets its own name and account; and for non-persistent VDI, apply "Domain member: Disable machine account password changes" only to those images, with changes scheduled into maintenance windows as the docs recommend.

How this differs from "no logon servers" and the domain controller case

There are currently no logon servers available to service the logon request (1311) is a reachability problem — DNS or the network cannot find a DC — and the trust is intact; fix name resolution first. Error 1787 is the deleted-account case above and needs a rejoin. And if the machine showing the error is itself a domain controller, do not use Test-ComputerSecureChannel — the docs note it "returns false positive errors" on DCs; use netdom resetpwd /s:<other DC> /ud:CORP\admin /pd:* per Microsoft's domain controller procedure. Next time you see the dialog, run Test-ComputerSecureChannel -Verbose as a local admin before you touch AD — it tells you in one word whether the one-line repair will do.