“The trust relationship between this workstation and the primary domain failed”

A user tries to sign in to their work PC with their domain account and gets this instead of a desktop:

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

A local account still works. Sometimes a cached domain sign-in still works too. The PC is on the network, the domain controllers are up, and other people are fine. Only this one computer has lost its standing with the domain.

The fix is usually a two-minute PowerShell command, but only if you check a few things first. Run the repair blind and it can appear to work, then fail again a day later because the real cause was somewhere else. This article walks through the diagnosis first and the repair second.

Applies to: Windows 10, Windows 11 and Windows Server machines that are members of an Active Directory domain. It does not apply to domain controllers themselves: Microsoft notes that Test-ComputerSecureChannel returns false errors when run on a DC. Run every command in an elevated PowerShell window (right-click, Run as administrator) after signing in with the local administrator account.

What is going on

Every domain-joined computer has its own account in Active Directory (AD), and that account has a password. You never see it. Windows creates it when the PC joins the domain and changes it on its own, by default every 30 days. The PC and the domain controller (DC) use that shared secret to build a protected connection called the secure channel, which is managed by the Netlogon service. Every domain sign-in and every Group Policy refresh rides on that channel.

If the password stored on the PC and the password stored in AD stop matching, the DC no longer believes the PC is who it says it is. The secure channel will not form, and Windows reports a broken trust relationship. Nothing is wrong with the user account. Microsoft describes two ways to get there:

• The PC has an older password than AD. The password was changed in AD, but the PC missed or lost the change. Typical causes: a virtual machine reverted to an old snapshot, a PC restored from a backup or system restore point, a power cut at the wrong moment, or a machine that was switched off for longer than usual.
• AD has an older password than the PC. The PC changed its password but the DC it talked to lost that change. Typical causes: a domain controller restored from an old backup, an authoritative restore of the computer object, or Active Directory replication problems.

The second case cannot be fixed from the PC alone. The data has to be made consistent on the AD side first. Everything below is arranged so that you find out which case you are in before you change anything.

Diagnosis

1. Confirm the symptom and look at the event log

Sign in with the local administrator account (for example .\Administrator, the leading dot means “this computer”). Then look for the Netlogon error in the System log:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='NETLOGON'; Id=3210} -MaxEvents 3 |
  Format-List TimeCreated, Message

Event ID 3210 reads “This computer could not authenticate with \\<DC name>, a Windows domain controller for domain <DOMAIN>, and therefore this computer might deny logon requests.” Microsoft lists it as the usual companion to this error, but its absence does not rule the problem out. Note the time of the first one. It tells you roughly when the passwords drifted apart.

2. Rule out the network before blaming the password

A PC that cannot find a DC, or whose clock is far out, fails the same test as a PC with a bad password. Check both first. The next two articles in this series cover them in detail: Group Policy events 1053 and 1055 (name resolution) and Kerberos clock skew.

ipconfig /all
nltest /dsgetdc:<domain name>
w32tm /query /status

• ipconfig /all: the DNS servers listed must be servers that can answer for your AD domain. A home router or public DNS server cannot.
• nltest /dsgetdc:<domain name> asks DNS for the domain controllers and contacts them. A DC name and address means the PC can find AD. An error here (for example 1355, “the specified domain either does not exist or could not be contacted”) is a name resolution or connectivity problem, not a password problem. Fix that first.
• w32tm /query /status: Kerberos allows 5 minutes of clock difference by default. A clock further out than that will also stop sign-in.

3. Test the secure channel itself

Test-ComputerSecureChannel -Verbose
nltest /sc_query:<domain name>

Test-ComputerSecureChannel returns True when the channel works and False when it does not. With -Verbose it also prints a sentence about what it found. On a PC with mismatched passwords, nltest /sc_query typically shows Status = 5 0x5 ERROR_ACCESS_DENIED, which is the example Microsoft gives. Both tests failing, with the DC reachable and the clock correct, points at the machine account password.

4. Work out which side is newer

This decides whether the PC-side repair will hold. Ask what happened to this machine, or to the domain, around the time of the first Event 3210:

• Was this a virtual machine reverted to a snapshot, or a PC restored from an image or a restore point? In the System log, Kernel-General Event ID 12 shows the last startup time, and a sudden jump in event dates is a giveaway. Event ID 41 or 6008 mean an unclean shutdown.
• Was a domain controller restored from backup, or an AD object restored, recently? Are several unrelated PCs failing within days of each other? That points at the AD side. Check Active Directory replication and DC health before you repair clients.
• Is it one laptop that was off for a long time? That is the simplest case: the PC-side repair below is the right tool.

If you have the Active Directory module (part of the Remote Server Administration Tools, RSAT) on an admin machine, you can see when AD last saw a password change for the computer. Compare that with when the problem began:

Get-ADComputer -Identity <computer name> -Properties PasswordLastSet |
  Select-Object Name, PasswordLastSet, Enabled

Also check that the computer object still exists and is enabled. Microsoft notes the same error can appear when the computer account was deleted or became corrupt, which needs a different fix (restore the object, for example from the AD Recycle Bin if one is enabled).

Root cause

The computer account password held by the PC (an LSA secret stored on the PC) does not match the one in Active Directory, so the DC refuses to set up the Netlogon secure channel. One side is behind the other, usually because of a snapshot or backup restore, a long absence, or a DC that lost recent changes.

The fix

Do not delete the computer account, and do not rejoin the domain as your first move. Rejoining is a valid last resort, and Microsoft says so, but deleting the computer object throws away its group memberships, any delegated permissions, and the link to the BitLocker recovery key stored in AD. A new object is a new identity. The repair below keeps the same object and only fixes the password.

Before you start: secure the BitLocker recovery key

If the PC uses BitLocker, make sure its recovery password is saved somewhere you can read it without this PC. A repair should not trigger a recovery prompt, but a rejoin and some hardware changes can, and it is much easier to find the key now than at a blue recovery screen.

manage-bde -protectors -get C:

Look for the Numerical Password entry and its ID. In AD, the same key is stored under the computer object. If you want to push it there again, manage-bde -protectors -adbackup C: -id {key protector ID} does that, and needs the PC to reach a DC.

Step 1: repair the secure channel

This removes and rebuilds the channel and resets the machine password in one go. You need local administrator rights on the PC and credentials for a domain account that is allowed to reset computer passwords, such as a Domain Admin or a help desk account with that delegated right. Run it from the PC, not from a DC:

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

Enter the domain account in the pop-up (DOMAIN\username). The cmdlet returns True if the repair worked. Microsoft’s own secure channel guidance gives the equivalent in Command Prompt, which also takes domain admin credentials:

nltest /sc_reset:<domain name>

Restart the PC afterwards. Microsoft’s guidance for both scenarios ends with a restart.

Step 2: if the repair fails, reset the machine password directly

Reset-ComputerMachinePassword -Credential (Get-Credential)
Restart-Computer

This changes the computer account password using the credentials you give it. It produces no output when it works. Add -Server <DC name> if you want to pin it to one specific DC, which helps if you know a particular DC has the current data. Do not run it repeatedly against different DCs while replication is in doubt.

There is also a Netdom route that Microsoft documents on its domain-join page: netdom resetpwd /server:<DC name> /userd:DOMAIN\username /passwordd:*. It does the same job as the cmdlet.

Do not use “Reset Account” in Active Directory Users and Computers as the fix. It changes the password on the directory side, which is the opposite of what you need when the PC already holds a different one. Do this only if a Microsoft-documented step for your situation tells you to. Leave the computer object alone unless you are told to touch it by a step you have verified.

Last resort: leave and rejoin the domain

Only if both repairs failed, and only after you have the BitLocker key and a note of the computer object’s group memberships (in Active Directory Users and Computers, the Member Of tab). Try to keep the existing computer object so the group memberships and recovery key stay attached; which account you join with decides whether Windows can reuse the object or has to create a new one, so check the result afterwards. Do not delete the user’s C:\Users\<name> folder. Use System Properties (SystemPropertiesComputerName.exe), change the membership to a workgroup, restart, then join the domain again and restart once more. Expect to confirm the user’s profile, mapped drives and any certificates afterwards.

Verification

Test-ComputerSecureChannel -Verbose
nltest /sc_query:<domain name>

The first should print True and a line saying the secure channel is alive and working correctly. The second should show Status = 0 0x0 NERR_Success. Then lock or sign out and sign in with a normal domain account. Finally, check the System log for new NETLOGON 3210 events over the next day. If they return, the cause was not the PC.

Notes

• Fixed, then broken again? Look at why the passwords drifted. Snapshot-reverting VMs and non-persistent VDI desktops will do it every time. Those need a design fix (for example a persistent identity strategy for the image), not repeated repairs.
• Many PCs broken at once? Suspect the domain controller side: a restore, a replication failure or a dead DC. Start with AD replication health and DC time, not the clients.
• Do not “solve” it by disabling machine password changes. The registry value DisablePasswordChange and the policy “Domain member: Disable machine account password changes” exist, and Microsoft documents them, but its security baselines recommend leaving them off. Turning password rotation off hides this error and leaves the account password static.
• DNS, the clock and the secure channel share causes. A wrong DNS server stops the PC finding a DC (see Group Policy events 1053 and 1055). A clock more than 5 minutes out stops authentication (see Kerberos clock skew). Rule both out before you reset passwords.
• The Microsoft Learn pages this article was checked against are “Broken trust relationship between a domain-joined device and its domain due to secure channel issues” and the two scenario articles it links to, plus the reference pages for Test-ComputerSecureChannel and Reset-ComputerMachinePassword.

Still stuck? Post what Test-ComputerSecureChannel -Verbose, nltest /dsgetdc and nltest /sc_query print, plus what happened to the machine around the first Event 3210, in The Patch Panel and we will work through it. The best answer earns points on Top of the Stack.