---
title: "Fix the \"trust relationship failed\" domain sign-in error in Windows"
canonical: https://saasranked.com/guides/trust-relationship-failed/
applies_to: Domain-joined Windows clients, Windows Server member servers, Windows PowerShell 5.1
checked: 2026-09-24 (against Microsoft's documentation)
updated: 2026-09-24
---

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

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

- While domain sign-in fails, you can still sign in with a local user account or cached credentials [1].
- The System log shows Event 3210 from the NETLOGON source when the secure channel is broken [1].
- Test-ComputerSecureChannel returns True if the channel works and False if it doesn't; its Repair parameter needs a member of the local Administrators group [3].
- Microsoft's repair is nltest /sc_reset:domain_name or Test-ComputerSecureChannel -Repair -Credential *, run with domain admin credentials, then a restart [2].
- Test-ComputerSecureChannel works only on domain member computers; on domain controllers, use netdom.exe or nltest.exe [3].

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 [2]. 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 [5]. 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 [1]. The System log in Event Viewer shows Event 3210 from NETLOGON. It says the computer "could not authenticate" with a domain controller [1].

## Before you start

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

## Fixes

1. **Check that the domain controller is reachable.** In Command Prompt, find the domain controller the computer uses [5]:

    ```cmd
    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 [5]. If there is no connection, fix the network path first [5].

2. **Test the secure channel.** In PowerShell, run this command [5]:

    ```powershell
    Test-ComputerSecureChannel -Verbose
    ```

    It returns **True** if the channel works and **False** if it doesn't [3]. If it returns True, try signing in with your domain account again [5].

3. **Repair the secure channel.** Run this command and enter domain admin credentials when asked [2]:

    ```powershell
    Test-ComputerSecureChannel -Repair -Credential *
    ```

    The **Repair** parameter removes and rebuilds the channel set up by the NetLogon service [3]. From Command Prompt, you can run this command instead, with your domain name in place of domain_name [2]:

    ```cmd
    nltest /sc_reset:domain_name
    ```

    Restart the computer afterwards [2].

4. **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 [4]:

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

    Put your own domain controller and admin account in place of DC01 and Domain01\Admin01 [4]. Then run Test-ComputerSecureChannel again to check the result [3].

5. **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 [5]. Its examples pass a domain account to the **Remove-Computer** and **Add-Computer** cmdlets, and both restart the computer [5]. The Add-Computer example also uses a local administrator account [5].

## 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 [2]. 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 [6].

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

```cmd
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 [1]. 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 [2]. Active Directory replication problems and a domain controller restored from backup are others [6].

**Can I just rejoin the computer to the domain?** Yes. Microsoft calls rejoining a valid solution [1]. If the error keeps coming back, Microsoft suggests finding the root cause instead [1].

**Can I run Test-ComputerSecureChannel on a domain controller?** No. On domain controllers it returns false positive errors [3]. Use netdom.exe or nltest.exe to check and reset their secure channels [3].

## Sources

1. [Broken trust relationship between domain-joined device and its domain](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/broken-trust-relationship-domain-joined-device-its-domain-secure-channel-issues), Microsoft Learn, accessed 2026-09-24
2. [Active Directory has a newer password value than client device](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/active-directory-has-newer-password-value-than-client-device), Microsoft Learn, accessed 2026-09-24
3. [Test-ComputerSecureChannel](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/test-computersecurechannel?view=powershell-5.1), Microsoft Learn, accessed 2026-09-24
4. [Reset-ComputerMachinePassword](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.management/reset-computermachinepassword?view=powershell-5.1), Microsoft Learn, accessed 2026-09-24
5. [Troubleshoot a failed trust relationship in an Azure Windows VM](https://learn.microsoft.com/en-us/troubleshoot/azure/virtual-machines/windows/troubleshoot-broken-secure-channel), Microsoft Learn, accessed 2026-09-24
6. [Client device has a newer password value than Active Directory](https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/client-device-has-newer-password-value-than-active-directory), Microsoft Learn, accessed 2026-09-24

Checked against Microsoft's documentation on 24 Sept 2026.