Windows "The trust relationship between this workstation and the primary domain failed": fix it without rejoining
Fix "The trust relationship between this workstation and the primary domain failed": repair the computer account password with PowerShell, without rejoining the domain.
by OhSudo ··
A domain user tries to log in, and Windows refuses before even checking the password:
The trust relationship between this workstation and the primary domain failed.Every domain-joined computer has its own account in Active Directory, with its own password that it changes automatically, by default every 30 days. This message means the computer and the domain no longer agree on that password. The user’s account is fine, and so is the machine.
The usual causes are a VM restored from an old snapshot or backup (it came back with a password the domain already replaced), a computer object that was deleted or reset in Active Directory, or a machine cloned without Sysprep.
The old advice is to leave the domain and join it again. It works, but you rarely need it: the password can be repaired in place.
- This computeran old machine password (restored snapshot, clone)passwords don't match(fails)
- Active Directoryexpects the newer one(breaks here)so
- User login refusedtrust relationship failed
TL;DR
Log in with a local administrator account, then in an elevated PowerShell:
Test-ComputerSecureChannel -Verbose # False = the trust is brokenTest-ComputerSecureChannel -Repair -Credential CONTOSO\admin # repair itReset-ComputerMachinePassword -Server dc01 -Credential CONTOSO\admin # the alternativeNo restart is usually needed; log out and log in with the domain account.
1. Log in locally
Domain accounts can’t log in, so use a local administrator: at the login screen choose Other user and type .\Administrator, or the name of another local account, where .\ means “this computer”. If no local password is known, Windows LAPS may hold it, in Active Directory or Microsoft Entra ID.
Warning
These steps are for member machines, and the repair needs to reach a domain controller. A domain controller with replication or trust problems is a different job.
2. Confirm it
Test-ComputerSecureChannel -VerboseVERBOSE: The secure channel between the local computer and the domain contoso.local is broken.FalseFrom a Command Prompt, nltest /sc_verify:contoso.local gives the same answer.
If this says True, the trust is fine at this moment. Check the time and DNS (section 5).
3. Repair the password
Test-ComputerSecureChannel -Repair -Credential CONTOSO\adminThe account needs the right to reset that computer object. True means it’s fixed. If it fails, name a domain controller explicitly:
Reset-ComputerMachinePassword -Server dc01.contoso.local -Credential CONTOSO\adminThese cmdlets are in Windows PowerShell 5.1, not in PowerShell 7, so open powershell.exe. Without them, netdom does the same from an elevated prompt, where available:
netdom resetpwd /s:dc01.contoso.local /ud:CONTOSO\admin /pd:*4. If the computer object is gone: rejoin
When the object was deleted from Active Directory, there’s nothing left to repair. Check first:
Get-ADComputer -Identity WKS-042 # from a machine with the AD moduleThen rejoin, from the local administrator session:
Remove-Computer -UnjoinDomainCredential CONTOSO\admin -WorkgroupName TEMP -Restart -Force# after the restart, log in locally again:Add-Computer -DomainName contoso.local -Credential CONTOSO\admin -RestartDomain profiles stay on disk and users get them back. A rejoin creates a new computer object if the old one is gone, so anything assigned to it, like group memberships, has to be set again.
5. It keeps coming back
If the fix works and the error returns, find what keeps breaking it:
- Snapshots. Reverting a VM to a snapshot older than its last password change breaks the trust every time. After a restore, repair it as above.
- Two machines with the same name, often clones. They overwrite each other’s password. Generalize images with Sysprep, and check for duplicates.
- The clock. Kerberos refuses tickets when the difference to the domain is over 5 minutes by default. Check with
w32tm /query/status, and resynchronize withw32tm /resync. - DNS. The computer must find a domain controller. Its DNS must point to the domain’s DNS servers, not to a public resolver: check with
nltest /dsgetdc:contoso.local.
Shell, we have a problem!
Similar, but different: We can't sign you in with this credential because your domain isn't available usually means no domain controller can be reached right now: a network, VPN or DNS problem, not a broken trust. See the domain could not be contacted. The security database on the server does not have a computer account for this workstation trust relationship has the same fix as this article, or a rejoin if the object was deleted. For a remote management tool that can’t reach a machine, see The RPC server is unavailable. For a shared folder that won’t connect, see System error 53.
Found this useful? Share it.
Found a mistake? Let us know at contact@ohsudo.com.