Windows · Windows Server · high · Security, BitLocker & identity

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

The machine account password no longer matches what the domain holds, so the secure channel cannot be established.

What you see

Domain sign-in fails at the workstation with this message. A local administrator can still sign in. Very common after restoring a machine from a snapshot or an image.

What is actually wrong

The machine changes its own account password every 30 days. Restoring to a snapshot older than that leaves the machine holding a password the domain has since replaced. A duplicate computer object or a machine that has been off for months does the same.

Codes and articles

trust relationship0x800706FDEvent 5722Event 3210secure channel

Fixes (2)

Repair the secure channel without leaving the domain

Elevated PowerShell on the affected machine, signed in locally20 minuteslow riskreversible

Always try this before the remove-and-rejoin that everyone reaches for.

Sign in with a local administrator account. A cached domain account may work; a fresh one will not.
Confirm the channel is actually broken.
PowerShell
```
Test-ComputerSecureChannel -Verbose
```
Repair it, supplying domain credentials with permission to reset the computer object.
PowerShell
```
Test-ComputerSecureChannel -Repair -Credential (Get-Credential DOMAIN\admin)
```
This resets the machine account password on both sides in place. Removing the machine from the domain and rejoining does the same thing but destroys the computer object's group memberships, its BitLocker escrow and any Group Policy that targets it — which is why it is the wrong first move.

If that fails, reset the password with the netdom equivalent.

PowerShell

Reset-ComputerMachinePassword -Server DC01 -Credential (Get-Credential DOMAIN\admin)

Restart and sign in with a domain account.

Confirm it workedTest-ComputerSecureChannel returns True and domain sign-in works.

PowerShell

Test-ComputerSecureChannel

If you need to undo itNone needed — the account is back in a consistent state. Nothing was removed.

Rule out the causes that look identical

Elevated PowerShell30 minuteslow riskreversible

The repair failed, or nothing explains why it broke.

Check for a duplicate computer object in the directory — two objects with the same name is a common cause after a rebuild.

PowerShell

Get-ADComputer -Filter { Name -like 'LAPTOP01*' } -Properties whenCreated,PasswordLastSet | Format-Table Name,DistinguishedName,whenCreated,PasswordLastSet

Check the machine can reach a domain controller at all — a DNS fault produces the same message.
PowerShell
```
nltest /dsgetdc:yourdomain.localResolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.yourdomain.local
```
"Trust relationship failed" is also what Windows says when it cannot find a domain controller to ask. Confirming the machine can locate one separates a broken account from a broken network in one command.
Check the time. More than five minutes of skew breaks Kerberos and presents identically.
PowerShell
```
w32tm /query /statusw32tm /stripchart /computer:DC01 /samples:3 /dataonly
```

Only if the object is genuinely wrong, reset it in the directory and repair from the client.

PowerShell

Get-ADComputer LAPTOP01 | Reset-ComputerMachinePassword -ErrorAction SilentlyContinuedsmod computer 'CN=LAPTOP01,OU=Computers,DC=yourdomain,DC=local' -reset

Confirm it workednltest and Test-ComputerSecureChannel both succeed and sign-in works.

If you need to undo itNothing destructive was done. A deleted duplicate object can be restored from the AD Recycle Bin if enabled.

Where this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.