Windows Server · Troubleshooting

Fix: The Trust Relationship Between This Workstation and the Primary Domain Failed

By Muhd Radhi Wahab, Editor · Updated 9 August 2026 · Active Directory

The short answer

Sign in with a local administrator account (type .\Administrator at the sign-in screen), open PowerShell as administrator, and run Test-ComputerSecureChannel -Repair. If that returns False or errors, run Reset-ComputerMachinePassword -Server <DCName> -Credential <domain>\<admin> instead. Both re-synchronise the computer's password with Active Directory and fix the error without removing the machine from the domain — no reboot in most cases.

You sit down at a domain PC, type your usual credentials, and Windows refuses them with: "The trust relationship between this workstation and the primary domain failed." It looks alarming, but the domain has not lost your account and your files are safe. What has actually broken is a single shared secret — the computer's own machine account password — and it can nearly always be repaired in under a minute from PowerShell.

This guide explains what the secure channel is and why it breaks, then walks the modern fixes in order: the one-line Test-ComputerSecureChannel repair, the Reset-ComputerMachinePassword fallback, and — for completeness — the old "remove and rejoin the domain" routine, with a clear note on why you should reach for it last. It closes with how to stop the problem coming back.

The repair path — work top to bottom and stop as soon as domain sign-in succeeds.

What "the trust relationship failed" actually means

When a computer joins an Active Directory domain, it gets its own account — a computer object — with a password, exactly like a user. That password is used to build a secure channel: an authenticated connection between the machine and a domain controller, handled by the Netlogon service, that proves the computer is who it claims to be before any user is allowed to log on with domain credentials.

Windows changes this machine account password automatically, by default roughly every 30 days — Microsoft's reference for the Domain member: Maximum machine account password age policy states that in Active Directory-based domains each device has an account and password and domain members submit a password change every 30 days by default. Both sides — the local computer and Active Directory — must hold the same value. The trust error appears when they fall out of sync, so the domain controller rejects the computer's attempt to open a secure channel. The usual culprits are:

Restoring an old snapshot or image. Rolling a VM back to a state captured before the last password change reinstates a stale password the domain no longer accepts. This is by far the most common cause.
The machine was off too long. A computer left switched off or disconnected past the change window can drift out of sync (though modern Windows tolerates this better than it used to).
A duplicate computer account. Cloning a machine without Sysprep, or manually recreating the object, leaves two accounts fighting over the same name.
Time skew. A clock more than five minutes off breaks the Kerberos authentication the channel depends on.

First, sign in with a local account

Because the domain can't authenticate the machine, your cached domain login may be refused. At the sign-in screen choose Other user and enter .\Administrator (the .\ means "this computer") or ComputerName\LocalAdmin, then the local password. You need a local administrator to run the repair commands below.

Method 1 — Repair the secure channel (fastest)

The Test-ComputerSecureChannel cmdlet checks whether the channel between the computer and its domain is healthy, returning True or False. Add -Repair and it removes and rebuilds the Netlogon channel, resetting the machine password on both sides. This is the first thing to try because it is a single line and needs no reboot.

Open PowerShell as administrator (right-click Start › Terminal (Admin), or search for PowerShell and choose Run as administrator).
Test the channel first to confirm the diagnosis:
```
Test-ComputerSecureChannel -Verbose
```
A result of False confirms the secure channel is broken.
Repair it:
```
Test-ComputerSecureChannel -Repair
```
If the machine can't reach a domain controller automatically, or the current user lacks rights, point it at a specific DC and supply a domain credential:
```
Test-ComputerSecureChannel -Repair -Server "dc01.contoso.com" -Credential (Get-Credential)
```
When it returns True, sign out and log back in with your domain account.

You must run this from an elevated prompt, and the account running -Repair must be a member of the local Administrators group. The -Credential parameter is specifically intended for the repair operation, so use it whenever the logged-on user doesn't have permission to reset the account in Active Directory. All three points come straight from the Test-ComputerSecureChannel cmdlet reference, which also notes the cmdlet works only on domain member computers, not domain controllers.

Method 2 — Reset the machine account password

If Test-ComputerSecureChannel -Repair can't fix it — for example it returns False or reports it can't contact a controller — reset the machine password directly with Reset-ComputerMachinePassword. This cmdlet resets the local computer's account password and writes the new value to Active Directory in one step; Microsoft Learn's Reset-ComputerMachinePassword reference describes it as changing the computer account password used to authenticate to the domain controllers, with -Server naming the domain controller to use.

In the same elevated PowerShell window, run:

Reset-ComputerMachinePassword -Server "dc01.contoso.com" -Credential (Get-Credential)

At the prompt, enter a domain administrator (or an account delegated rights to reset the computer object), in the form contoso\adminuser.
Point -Server at a domain controller the machine can actually reach on the network.
Sign out and log back in with your domain account to confirm the trust is restored.

The classic command-line alternative

If you prefer the legacy tool, netdom does the same job from an elevated prompt:

netdom resetpwd /server:dc01.contoso.com /userd:contoso\adminuser /passwordd:*

The * makes it prompt for the password rather than showing it on screen. Netdom ships as part of the Remote Server Administration Tools. Both it and the PowerShell cmdlets work through the same Netlogon service under the hood.

Method 3 — Remove and rejoin the domain (last resort)

The traditional fix — and the one most older guides jump to first — is to take the computer out of the domain, put it in a workgroup, reboot, then join it back. It works, but it is heavier and slower than the repairs above, so treat it as a fallback for the rare case where the computer object has genuinely been deleted or is corrupt.

Signed in locally, open Settings › System › About (or sysdm.cpl) and note the domain and computer name.
Change the machine to a temporary workgroup and restart when prompted.
In Active Directory Users and Computers, reset (do not delete) the existing computer account if it still exists, so the name is free to rejoin cleanly.
Rejoin the machine to the domain with a domain credential and restart again.

Why the PowerShell way is better

Rejoining forces one or two reboots and can delete and recreate the computer account, which resets its security identifier relationships and may break anything that referenced the old object. Repairing the secure channel with Method 1 or 2 only updates the shared password — the account, its group memberships and its applied Group Policy all stay intact, and the machine is usable again in seconds. Only rejoin when the account itself is gone.

Prevention

A few habits stop the trust breaking in the first place:

Be careful with snapshots and images. Don't roll a domain-joined VM back to a state older than the machine password age; if you must, run Test-ComputerSecureChannel -Repair immediately afterward.
Always Sysprep before cloning. Generalising a template image gives every clone a unique identity instead of a duplicate machine account.
Keep clocks in sync. If a machine's time has drifted, run w32tm /resync; a skew over five minutes blocks Kerberos and the secure channel with it.
Leave the password policy alone. Don't disable the automatic machine password change on clients unless you have a specific, documented reason.

Symptom reference — confirm it really is the secure channel

The sign-in message is only one of the things a broken secure channel produces, and the others tell you more. Each row below is a symptom Microsoft lists for this exact fault in Broken trust relationship between a domain-joined device and its domain, which puts the cause down to one of two things: the client holds an older password than Active Directory, or Active Directory holds an older password than the client (a restored domain controller, or a replication problem).

What you see	Where	What it tells you
The trust relationship between this workstation and the primary domain failed.	At sign-in	Domain credentials are refused, but you can still sign in with a local user or cached credentials — which is how you get in to run the repair. Go to Method 1.
Event 3210 from source NETLOGON: this computer could not authenticate with a Windows domain controller, and therefore might deny logon requests.	System log, on the client	Microsoft gives two possible causes in the event text itself: another computer on the same network is using the same name, or the password for this computer account is not recognised. Rule out a duplicate name before you repair anything.
`Trusted DC Connection Status Status = 5 0x5 ERROR_ACCESS_DENIED` from `nltest /sc_query:<domain>`	Command prompt, on the client	A positive confirmation that the secure channel is broken rather than a network fault. A healthy machine returns `Status = 0 0x0 NERR_Success` and names the trusted DC.
`NlSessionSetup: Session setup: cannot I_NetServerAuthenticate 0xc0000022` followed by `new password is bad, try old one`	Netlogon debug log, if enabled	The domain controller rejected both the current and the previous machine password, so the two sides are more than one password change apart. Reset it outright — Method 2.
Event 5722 from NETLOGON: the session setup from the computer failed to authenticate; the following error occurred: Access is denied.	System log, on the domain controller	Not automatically a fault. Microsoft notes it is also logged when a computer routinely updates its account password. It's a real problem when the event time doesn't match the account's `pwdLastSet` value — which points at a duplicate computer name or a computer account that was reset.

Microsoft's guidance on Event 5722 is documented separately in Event ID 5722 is logged, including how to decode pwdLastSet with nltest /time: and compare it against the time in the event.

Related Windows Server guides

Setting up the environment behind this error? See how to set up Active Directory on Windows Server and how to add a domain controller for resilience. If policy isn't reaching your machines either, our guide to fixing Group Policy that won't apply covers the next thing to check.

Frequently asked

What causes the trust relationship between the workstation and the domain to fail?

Every domain-joined computer holds a machine account password that it shares with Active Directory and changes automatically about every 30 days. The trust breaks when the copy stored on the computer no longer matches the copy in Active Directory. That most often happens after you restore a machine from an old snapshot or image taken before the last password change, leave a computer switched off past the change window, or create a second computer object with the same name. When the two passwords disagree, the secure channel that authenticates the computer to the domain can no longer be established, and Windows shows the trust relationship error at sign-in.

Can I fix the trust relationship without rejoining the domain?

Yes. In almost every case you can repair the secure channel in place with PowerShell and never touch the domain membership. Sign in with a local administrator account, open an elevated PowerShell window, and run Test-ComputerSecureChannel -Repair, or Reset-ComputerMachinePassword with a domain administrator credential. Both resynchronise the machine account password with Active Directory. This keeps the existing computer object, its group memberships and its applied Group Policy, and usually needs no restart, so it is faster and cleaner than removing and re-adding the machine.

Why is the PowerShell repair better than removing and rejoining the domain?

The old rejoin method drops the computer out of the domain and adds it back, which can delete and recreate the computer account. That resets its object in Active Directory, can break group memberships that referenced it, requires at least one and usually two reboots, and risks orphaning the original account. Repairing the secure channel with Test-ComputerSecureChannel -Repair or Reset-ComputerMachinePassword only updates the machine password on both sides. The account, its history and its policy links stay intact, and the machine is usable again in seconds without a reboot.

How do I get into a computer showing the trust relationship error so I can fix it?

Because the domain can no longer authenticate the computer, cached domain credentials may be refused, so sign in with a local administrator account instead. At the sign-in screen, switch the user and type .\Administrator (the dot and backslash mean a local account) or ComputerName\LocalAdmin, then the local password. Once you are on the desktop you can open an elevated PowerShell prompt and run the repair commands, supplying a domain administrator credential when prompted. If no local administrator account is enabled, you may need to boot into recovery to enable one before you can repair the channel.

How can I prevent the trust relationship from failing again?

Keep the machine account password in sync. Avoid rolling virtual machines back to snapshots older than the machine password age, and if you must restore an old image, repair the channel straight afterwards. Always run Sysprep before cloning a template so each clone gets a unique identity rather than a duplicate machine account. Keep clocks accurate, because a time skew greater than five minutes blocks the Kerberos authentication the secure channel relies on. Finally, do not disable the automatic machine password change on clients unless you have a specific, well understood reason to.