Don't rejoin to fix: The trust relationship between this workstation and the primary domain failed

Originally published April 2012, refreshed 2026.

This is one of the oldest posts on this domain, kept at its original address because people still search for the error it fixes. It is off the main topic of the site, which is checking files and content, so it lives in the archive; the history of this domain and its archive pages explains why it is still here.

The advice has aged well. The commands have been checked against Microsoft's current documentation, and one tool the 2012 post mentioned, netdom resetpwd, now comes with an important limit that is noted below.

The error

You try to sign in to a domain-joined Windows computer with a domain account and get:

The trust relationship between this workstation and the primary domain failed.

Microsoft's troubleshooting article on broken trust relationships lists the other symptoms. You can still sign in with a local account or cached credentials. The System event log shows Event 3210 from NETLOGON, saying the computer could not authenticate with a domain controller. And nltest /sc_query:contoso.com reports ERROR_ACCESS_DENIED.

The common advice is to remove the computer from the domain and join it again. That works, but it is slow, needs a domain account with join rights, and on some servers it is not possible at all. The 2012 post was written after exactly that happened on a test certificate authority: as the post noted, Windows would not let that machine be renamed or removed from the domain.

Why the trust relationship breaks

Every domain-joined computer has its own account in Active Directory, with a password that the computer and the domain both store and that changes automatically from time to time. The secure channel between the computer and its domain controllers depends on the two copies agreeing.

Microsoft's article names the two usual ways they drift apart:

• The computer has an older password than Active Directory. The classic case, and the one behind the original post, is reverting a virtual machine to a snapshot taken months earlier. The snapshot is missing every password change the machine made since.
• Active Directory has an older password than the computer. This happens when a domain controller is restored to an earlier state, or when replication between domain controllers is failing.

Either way the fix is the same: give the computer and the domain a fresh, matching password.

Find out which side is older

If the error keeps coming back, it helps to know which copy of the password fell behind. Microsoft's article uses three terms for this:

• LSA secret: the protected storage where Windows keeps the computer's copy of its domain password.
• CupdTime: the last time that local copy was updated, stored in the registry under the computer's $MACHINE.ACC secret.
• pwdLastSet: the attribute on the computer object in Active Directory that records when the domain's copy last changed.

Comparing the two dates tells you which scenario you are in. A local copy older than pwdLastSet points to a reverted snapshot or a restored disk image. A pwdLastSet older than the local copy points to a domain controller that was restored or is not receiving replication. The article links a separate solution page for each case, and the repair below works for both.

Test the secure channel

Sign in with a local administrator account (or with cached domain credentials, if they still work) and open Windows PowerShell as administrator. Then check the channel:

Test-ComputerSecureChannel -Verbose

Microsoft's Test-ComputerSecureChannel reference says the cmdlet returns $true if the channel is working and $false if it is not, and -Verbose adds a sentence explaining the result. To test against a particular domain controller, add -Server "DCName.fabrikam.com".

One warning from the same page: the cmdlet only works on domain member computers. On a domain controller it returns false positive errors, and Microsoft points to netdom.exe or nltest.exe instead.

Repair it with Test-ComputerSecureChannel -Repair

If the test returns False, the same cmdlet can rebuild the channel:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

-Repair removes and then rebuilds the channel established by the NetLogon service. To use it, you must be a member of the local Administrators group. -Credential takes a user name such as Domain01\User01 or a credential object from Get-Credential; give it a domain account that is allowed to reset this computer's account.

Run the test again. When it returns True, restart the computer and sign in with your domain account.

When the channel is healthy again, the verbose test says so in plain words. Microsoft's example output reads:

VERBOSE: "The secure channel between 'SERVER01' and 'net.fabrikam.com' is alive and working correctly."

If the repair returns an error instead, check that the account you gave has the right to reset computer accounts in that domain, and that the computer can reach a domain controller at all.

Reset it with Reset-ComputerMachinePassword

The 2012 post recommended this cmdlet, which it described as new in PowerShell 3.0, and it is still the most direct fix. It changes the computer account password that the computer uses to authenticate to domain controllers.

Microsoft's Reset-ComputerMachinePassword reference gives this example, which names a domain controller and a domain account with permission to reset the password:

Reset-ComputerMachinePassword -Server "DC01" -Credential Domain01\Admin01

If you type a user name, the cmdlet prompts for the password. To keep the credential in a variable, as the original post suggested for scripts, use Get-Credential:

$cred = Get-Credential
Reset-ComputerMachinePassword -Server "DC01" -Credential $cred

Restart, then sign in with the domain account.

Both cmdlets are documented for Windows PowerShell 5.1, the version built into Windows, so open Windows PowerShell from the Start menu to run them.

A correction to the 2012 post: netdom resetpwd

The original post mentioned netdom resetpwd as another way to reset a computer password. Microsoft's current netdom resetpwd reference narrows that: it resets the machine account password for a domain controller, must be run on that domain controller, and does not support member servers or remote machines.

So for a workstation or member server, use the PowerShell cmdlets above. Keep netdom resetpwd for a domain controller whose own secure channel is broken, run from a Command Prompt opened as administrator on that controller:

netdom resetpwd /server:MyDC /userd:admin /passwordd:*

When you do need to rejoin

Rejoining is still a valid fix, and Microsoft says so. Use it when the repair does not take, for example when the computer's account has been deleted from Active Directory, or when Event 3210 suggests another computer on the network is using the same name.

Rejoining hides the cause, though. Microsoft's note on this is direct: if the trust keeps breaking, rejoining will not tell you why. Look for the patterns behind it, such as virtual machines being reverted to old snapshots, a domain controller restored from backup, or replication errors between domain controllers.

Two checks if the repair fails

Make sure you can reach a domain controller at all. A laptop away from the office may need the corporate VPN before any of these commands can succeed; the old support desk on this domain gave that exact advice for its Active Directory tools.

Check the computer name too. Microsoft's article suggests confirming that the computer name registry values hold the short computer name rather than a fully qualified domain name.

More from the archive

This domain's other archive page is about a different Windows chore: editing environment variables, from Varpanel to setx. Questions from the old support desk about file hashes are collected on the file hash support page.

Sources

1. Microsoft Learn, Test-ComputerSecureChannel (Windows PowerShell 5.1)
2. Microsoft Learn, Reset-ComputerMachinePassword (Windows PowerShell 5.1)
3. Microsoft Learn, Broken trust relationship between domain-joined device and its domain
4. Microsoft Learn, netdom resetpwd

Questions

• Can I fix the trust relationship error without rejoining the domain?+

  Usually, yes. Test-ComputerSecureChannel -Repair or Reset-ComputerMachinePassword resets the computer's password with the domain without removing it from Active Directory.

• Why can I still sign in with a local account?+

  Because a local account is checked by the computer itself, not by a domain controller. Microsoft notes that local and cached credentials keep working while domain sign-in fails.

• Do these cmdlets work on a domain controller?+

  No. Microsoft says Test-ComputerSecureChannel gives false positive errors on domain controllers, and points to netdom.exe or nltest.exe for them instead.

• Does reverting a virtual machine snapshot cause this error?+

  It is a classic trigger. The snapshot holds an older computer password than Active Directory, so the two no longer agree after the revert.

• What permissions do I need to repair the secure channel?+

  Local administrator rights on the computer, plus a domain account with permission to reset the computer account password, entered through the Credential parameter.