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

Updated: October 2026

A user sits down on Monday, types their password, and Windows says the trust relationship between this workstation and the primary domain failed. The usual reflex is to pull the machine off the domain and rejoin it, which works and teaches you nothing. Here's the one-line fix that skips the rejoin, how to tell why it broke, and how to stop it happening across a fleet.

What the Error Means

Every domain-joined computer has its own account in Active Directory, with its own password. The computer keeps a copy of that password, and Active Directory keeps another. When the two copies match, the computer and the domain controller build a secure channel and domain logons work.

When the copies stop matching, the secure channel breaks. Domain logons fail with this error, but a local account or cached credentials still get you in. That detail matters, because it's how you get to a prompt to fix it.

The computer changes its own password every 30 days by default, per Microsoft's policy reference. Anything that rolls one side back to an older password breaks the match. The System log usually shows it as NETLOGON event 3210.

Fix It Without Rejoining the Domain

Sign in with a local admin account, or with cached domain credentials if the machine still accepts them. Open Windows PowerShell as administrator and run:

powershell
Test-ComputerSecureChannel -Repair -Credential DOMAIN\admin

Then restart. The cmdlet removes and rebuilds the secure channel through the Netlogon service, and it returns True when the channel works. You need local admin rights to run it, domain credentials that can reset the computer account, and a line of sight to a domain controller.

Two other commands do the same job when that one fails:

powershell
Reset-ComputerMachinePassword -Server DC01 -Credential DOMAIN\admin

console
nltest /sc_reset:yourdomain.local

Reset-ComputerMachinePassword sets a fresh password against the domain controller you name, which helps when one DC is misbehaving. nltest is the same repair from a plain command prompt. Both cmdlets live in Windows PowerShell 5.1, not PowerShell 7, so use the built-in shell. Our PowerShell commands guide covers the rest of the toolkit.

Rejoining still works as a last resort. Microsoft's own troubleshooting article calls it valid, then points out it won't tell you why the trust broke. If the same machine breaks again next month, you'll want the why.

Danny Moran runs the PowerShell repair on a live machine in under four minutes.

Check Which Side Is Wrong First

The mismatch has two possible directions, and Microsoft treats them as separate problems. Either the computer holds the newer password and Active Directory holds an old one, or the other way round.

Compare the computer object's pwdLastSet attribute in Active Directory with the date the device last changed its password. The device-side date sits in the registry under the LSA secrets, which Microsoft's data-collection guide walks through.

If Active Directory is the older side, the problem lives on the domain controllers. Microsoft lists replication issues, a DC restored from backup, or an authoritative restore of the computer object. Repairing the laptop won't hold until the domain side is healthy again.

If the device is the older side, something rolled the device back. That's the common case, and the next section covers it.

Why It Keeps Happening

Microsoft's list of causes for a device holding an older password is short, and each one is a rollback:

• Snapshot revert. A VM goes back to a checkpoint taken before its last password change.
• Bare-metal restore. A physical or virtual machine comes back from an old image backup.
• System restore point. Windows rolls back to an earlier state, logged as event 1208 or 8202.
• Power loss. An unclean shutdown right after a password change can lose the new secret, logged as event 41 or 6008.
• Cloned or non-persistent machines. Images and pooled VDI desktops reset to a snapshot at sign-out.

Microsoft's tip for spotting a rollback is to look for a jump in time in the event logs. A machine in daily use with no events between February and July has been somewhere it shouldn't. A very recent boot time, event 12, is the other clue.

Cloning catches people out the most. In this r/sysadmin thread, one reply describes someone cloning domain-joined workstations, then a tech rejoining each one by hand whenever it broke. Another reply offers the same PowerShell repair as a faster fix than rejoining.

Remote Laptops and VPNs

Remote laptops have their own version of this. A laptop needs to reach a domain controller to keep its password in step with Active Directory. If it only reaches the office through a VPN that connects after the user signs in, it can spend long stretches without that contact.

This case came up on r/sysadmin in October 2025. An MSP had a small client with one domain controller, four desktops and four laptops. Only the laptops kept losing trust, and they were the ones on VPN.

The replies point three ways. One commenter explains that Windows does its domain work at logon, so a VPN that comes up afterwards misses it. Others suggest checking time skew, since Kerberos fails when clocks drift more than a few minutes. The most upvoted replies ask whether those laptops need on-premises AD at all, and suggest joining them to Entra ID instead.

That last option is worth weighing for devices that never come into the office. Our Microsoft Intune review covers what managing them that way involves. If they stay domain-joined, a VPN that connects before logon keeps them in contact with a DC.

Stop It Across a Fleet

Prevention is mostly about not fighting the defaults.

Keep the machine account password age at 30 days. Microsoft recommends that value, and warns that disabling password changes gives an attacker more time to guess a machine account's password. Turning changes off to stop this error trades one problem for a worse one.

Treat snapshots as part of the risk. A checkpoint older than 30 days is likely to hold a stale machine password, so reverting a domain-joined VM means planning a secure channel repair straight after. The same goes for image-based restores.

Then check before users do. Test-ComputerSecureChannel returns True or False, which makes it easy to run on a schedule across every machine and alert on the failures. In OpenFrame, that's a scheduled script run across devices in bulk, with approval gates before any repair runs. Any RMM that runs scripts can do the same check.

Fix It Once, Then Find the Cause

The repair takes one line and a reboot. The cause takes a few minutes of reading event logs, and it's what stops the ticket coming back.

If the same machines keep dropping off the domain, look at what rolled them back or what kept them away from a DC. For the next logon-time failure on the list, our guide to fixing slow DNS lookups is the next read.