Why does the trust relationship break?

Either the computer has an older machine password than Active Directory, or Active Directory has an older one than the computer. Causes Microsoft lists include reverting a virtual machine to an old snapshot, restoring from a backup or an old restore point, and a sudden power loss. Active Directory replication problems and a domain controller restored from backup are others.

Can I just rejoin the computer to the domain?

Yes. Microsoft calls rejoining a valid solution. If the error keeps coming back, Microsoft suggests finding the root cause instead.

Can I run Test-ComputerSecureChannel on a domain controller?

No. On domain controllers it returns false positive errors. Use netdom.exe or nltest.exe to check and reset their secure channels.

Fix the "trust relationship failed" domain sign-in error in Windows

This error means the computer can't set up a secure channel with a domain controller, because its machine password doesn't match the copy in Active Directory^1,5. Sign in with a local account or cached credentials. Then run Test-ComputerSecureChannel -Repair -Credential * with domain admin credentials and restart². If that fails, reset the machine password with Reset-ComputerMachinePassword^4,5.

What the error means

A computer that is joined to a domain talks to domain controllers over a secure channel. The channel depends on a machine password that must match the copy in Active Directory⁵. When the two values differ, the computer can't authenticate, and domain sign-in fails with this error^1,5.

You can still sign in with a local user or cached credentials¹. The System log in Event Viewer shows Event 3210 from NETLOGON. It says the computer "could not authenticate" with a domain controller¹.

Before you start

Sign in with a local account or cached credentials. Domain credentials won't work until the channel is repaired¹.
Open PowerShell with Run as administrator. Test-ComputerSecureChannel needs it, and its Repair parameter needs a member of the local Administrators group³.
Have domain admin credentials ready. Microsoft's repair commands run with them².
Use these steps on a client or member server only. On a domain controller, Test-ComputerSecureChannel returns false positive errors³.
The repair ends with a restart, so save your work first².

Fixes

Check that the domain controller is reachable. In Command Prompt, find the domain controller the computer uses⁵:
Command Prompt
```
set | find /i "LOGONSERVER"
```
Then test the network connection to that domain controller's fully qualified domain name, for example with the Test-Connection cmdlet⁵. If there is no connection, fix the network path first⁵.
Test the secure channel. In PowerShell, run this command⁵:
PowerShell
```
Test-ComputerSecureChannel -Verbose
```
It returns True if the channel works and False if it doesn't³. If it returns True, try signing in with your domain account again⁵.
Repair the secure channel. Run this command and enter domain admin credentials when asked²:
PowerShell
```
Test-ComputerSecureChannel -Repair -Credential *
```
The Repair parameter removes and rebuilds the channel set up by the NetLogon service³. From Command Prompt, you can run this command instead, with your domain name in place of domain_name²:
Command Prompt
```
nltest /sc_reset:domain_name
```
Restart the computer afterwards².
Reset the machine password. If the repair fails, reset the password the computer uses to authenticate to domain controllers^4,5. This example uses the DC01 domain controller and an account that may reset computer passwords⁴:
PowerShell
```
Reset-ComputerMachinePassword -Server "DC01" -Credential Domain01\Admin01
```
Put your own domain controller and admin account in place of DC01 and Domain01\Admin01⁴. Then run Test-ComputerSecureChannel again to check the result³.
Remove the computer from the domain and join it again. Microsoft lists this as the last option when a password reset doesn't restore the channel⁵. Its examples pass a domain account to the Remove-Computer and Add-Computer cmdlets, and both restart the computer⁵. The Add-Computer example also uses a local administrator account⁵.

If nothing works

If the error comes back, find out why the passwords drift apart. Microsoft's articles compare the computer's password date with the pwdLastSet value in Active Directory^1,2.

When Active Directory holds the newer password, look for a virtual machine reverted to an old snapshot, a restore from backup or an old restore point, or a power loss². When the computer holds the newer password, check Active Directory replication and domain controller health. Microsoft says that case can't be fixed on the computer itself⁶.

Also check that two registry values hold the computer's real name, not its fully qualified domain name¹:

Command Prompt

Reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName /v ComputerName
Reg query HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Services\Tcpip\Parameters /v hostname

Questions

Why does the trust relationship break?: Either the computer has an older machine password than Active Directory, or Active Directory has an older one than the computer¹. Causes Microsoft lists include reverting a virtual machine to an old snapshot, restoring from a backup or an old restore point, and a sudden power loss². Active Directory replication problems and a domain controller restored from backup are others⁶.
Can I just rejoin the computer to the domain?: Yes. Microsoft calls rejoining a valid solution¹. If the error keeps coming back, Microsoft suggests finding the root cause instead¹.
Can I run Test-ComputerSecureChannel on a domain controller?: No. On domain controllers it returns false positive errors³. Use netdom.exe or nltest.exe to check and reset their secure channels³.

24 Sept 2026: Published.