The Trust Relationship Between This Workstation and the Primary Domain Failed

Introduction

A user reboots a server that has been running quietly for months, reaches the logon screen, types their domain credentials, and is told the trust relationship failed. Local accounts still work. Cached credentials might even have logged them in yesterday. Nothing about the domain has changed for anyone else — only this one machine is locked out.

This is one of the most misread errors in a Windows environment, because the wording points at “the domain” while the fault is almost always local to the single machine. The domain is fine. What has broken is the private password this computer shares with Active Directory, and once you understand that, the fix is quick and surgical.

What You’re Seeing

The headline is the logon-screen message, but the useful evidence is in the event log and in nltest. The System log carries a NETLOGON Event 3210, and a secure-channel query returns access denied:

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

# System log, Source: NETLOGON, Event ID: 3210
This computer could not authenticate with \\DC01.corp.example.com,
a Windows domain controller for domain CORP, and therefore this
computer might deny logon requests. This inability to authenticate
might be caused by another computer on the same network using the
same name or the password for this computer account is not recognized.

# Querying the secure channel returns access denied
C:\> nltest /sc_query:corp.example.com
Flags: 0
Trusted DC Connection Status Status = 5 0x5 ERROR_ACCESS_DENIED

What It Actually Means

When a computer joins a domain it is issued a password, exactly like a user account. That password is stored locally as an LSA secret and on the machine’s computer object in AD. Windows rotates it automatically — by default about every 30 days — and both copies update together. The secure channel is the authenticated session the machine builds with a Domain Controller using that shared password, and it is what lets domain logons, Group Policy, and Kerberos work.

The error appears when the two copies drift apart. Either the machine has an older password than AD, or AD has an older password than the machine. The classic trigger is restoring the computer from a snapshot or image taken before the last password rotation: the restored machine presents an old secret, AD has since moved on, and authentication is refused. Replication lag between DCs can produce the same effect — the machine changed its password against one DC, and it is now talking to another that has not received the update yet.

Step 1: Test the Secure Channel

Sign in with a local administrator account (or cached domain credentials if they still work), open an elevated PowerShell, and ask Windows directly whether the channel is healthy. Test-ComputerSecureChannel returns a plain True or False.

# Does the machine password still match AD? True or False.
Test-ComputerSecureChannel

# The classic native equivalent - same question, older tool
nltest /sc_query:corp.example.com

# Confirm the machine can even find a DC to talk to
nltest /dsgetdc:corp.example.com

Step 2: Repair Without Rejoining

The repair resets the machine password so both copies agree again. You need an account with permission to reset the computer object. This does not change the machine SID, does not require removing it from the domain, and in most cases does not even require a reboot.

# Repair the secure channel in place - the preferred fix
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

# If repair reports it cannot reset, force a new machine password
Reset-ComputerMachinePassword -Server DC01 -Credential (Get-Credential)

# Confirm the channel is healthy again
Test-ComputerSecureChannel

Common Causes

Almost every occurrence is one of these, roughly ordered from most to least common. The confirm column tells you how to prove which one you are looking at before you touch anything.

Working Through a Fix

Put it in order. Log in locally, confirm the machine can reach a DC with nltest /dsgetdc, and check the clock is within a few minutes of the domain. If discovery and time are fine, run Test-ComputerSecureChannel to confirm the mismatch, then Test-ComputerSecureChannel -Repair -Credential (Get-Credential) to reset the password. A final Test-ComputerSecureChannel should now return True, and domain logon works again — usually without a reboot.

Only two situations genuinely call for a rejoin: the computer object has been deleted from AD, or the machine is an ungeneralised clone. Everything else is a password resync. Reaching for “remove from domain and rejoin” as a reflex works, but it costs a reboot, a new object, and any per-machine group memberships — so it is the last resort, not the first move.

How to Prevent It

Most recurrences trace back to two habits. The first is restoring machines — especially virtual DCs and member servers — from snapshots older than the 30-day password window; when you must roll back, expect to repair the secure channel afterward, and treat it as a normal step rather than a surprise. The second is unhealthy replication: if machine password changes are not converging across DCs, a subset of computers will hit this intermittently. Monitor replication health so those updates land everywhere.

For virtual DCs specifically, prefer proper backup and restore over hypervisor snapshots, which is the same USN-rollback hazard covered alongside replication. And keep DNS and time healthy across the estate, because both surface as trust-looking failures when they drift. If a repair does not stick, the problem is underneath the trust — go and fix the channel to the DC, not the password.

Quick Reference

Final Thoughts

The trust-relationship error reads like a catastrophe and resolves like a formality once you stop taking the wording literally. It is not the domain and it is not the trust between domains — it is one machine holding a stale copy of its own password. Confirm the mismatch, reset it, move on.

The lasting value is knowing why it happened. A machine that hits this after a snapshot restore tells you something about your backup practice; one that hits it intermittently tells you something about your replication. Fix the password to clear the call, then read what the call was telling you.