“The trust relationship between this workstation and the primary domain failed” means your PC’s secret machine password no longer matches the copy Active Directory holds, so the domain refuses to trust it. The quickest fix is to sign in with a local administrator account, open PowerShell as administrator and run Test-ComputerSecureChannel -Repair -Credential (Get-Credential) with a domain admin account. If that fails, reset the machine password with Reset-ComputerMachinePassword, and only as a last resort remove the PC from the domain and join it again. On a work laptop you don’t manage, this is a job for your IT team, since every fix needs domain admin rights.
What admins on Microsoft Q&A ran into
Three threads on Microsoft Q&A show the pattern well: the fix itself is quick, but the error keeps coming back until you find why the passwords drifted.
“Rejoining works, but it comes back”
An admin running a Windows Server 2022 domain described users who randomly could not sign in, locally or over Remote Desktop. Removing the PC from the domain and rejoining fixed it each time, but they wanted the root cause. Microsoft’s reply listed the usual suspects: clock drift between client and domain controller, DNS or network problems, machines that are off the network when their roughly 30-day password change comes due, stale or duplicate computer accounts, and tightened security policies. It also suggested repairing the channel with Test-ComputerSecureChannel -Repair instead of rejoining. No answer was marked as accepted.
“The error is back the next day, on many PCs”
In a second thread, a Windows Server 2019 domain had several Windows 11 PCs hitting the error at sign-in, again coming back the day after a rejoin. Microsoft staff suggested checking the connection to the domain controller and running Test-ComputerSecureChannel. The poster reported the cmdlet returned True, and the thread ended unresolved. That’s a useful clue: when the channel tests healthy but the error persists, look at duplicate PC names, time sync or replication between domain controllers instead of repairing the same PC again.
“Is there a fix that doesn’t need a reboot?”
A locked thread migrated from the old Microsoft community, which Q&A shows with 40+ “same question” votes, laid out three options: unjoin and rejoin, run Test-ComputerSecureChannel -Repair, or rejoin through System Properties. The PowerShell repair is the one that skips the restart, which is why it’s the first thing to try below.
Why the trust relationship between workstation and domain fails
Every domain-joined PC has its own computer account in Active Directory with a password only the PC and the domain controllers know. By default the PC changes that password every 30 days, according to Microsoft’s Maximum machine account password age policy. The trust (the “secure channel”) breaks when the two copies stop matching. Microsoft’s secure channel troubleshooting article and other sources point to the same handful of causes:
| What happened | Why it breaks the trust |
|---|---|
| PC or VM restored from an old snapshot, image or restore point | The PC goes back to an older machine password that Active Directory has already replaced |
| PC cloned without Sysprep, or two PCs share one name | Two machines fight over one computer account and keep changing its password |
| Computer account reset or deleted in Active Directory | The domain’s copy changes, but the PC still holds the old one |
| PC’s clock is far off from the domain controller | Kerberos rejects the sign-in; Microsoft’s default clock tolerance is 5 minutes |
| DNS or network can’t reach a domain controller | The PC can’t verify or update its password at all |
Microsoft’s Directory Services blog post on this error describes a real case of the second row: a branch office reimaged old PCs using the same names as newer ones, and the two sets kept breaking each other’s trust in a loop.
Before you start: get a local admin login
Domain accounts can’t authenticate while the trust is broken, so you need a way in that doesn’t depend on the domain. Use a local administrator account on the PC. People who’ve signed in to that PC before may still get in with cached domain credentials, but a domain user who never signed in there will just see the error again, as Petri’s guide explains.
Warning: don’t remove the PC from the domain until you’ve confirmed a local admin account and its password work. After an unjoin, domain accounts can’t sign in, and without a local login you could be left reinstalling Windows.
Fix 1: Check the network and the clock
Rule out the simple stuff first, because no password fix helps a PC that can’t reach a domain controller.
- Sign in with the local admin account and open Command Prompt.
- Run set | find /i “LOGONSERVER” to see which domain controller the PC last used, then ping that controller by its full name.
- Run ipconfig /all and check that the DNS servers listed are your domain’s DNS servers, not your router or a public DNS.
- Compare the PC’s time and time zone with a domain controller. A gap of more than 5 minutes is enough to break Kerberos.
Fix 2: Repair the secure channel with PowerShell
This is the fastest fix and usually doesn’t need a restart. Microsoft’s Test-ComputerSecureChannel documentation says it checks the trust and, with -Repair, removes and rebuilds the Netlogon channel.
- Right-click Start, choose Windows PowerShell (Admin) or Terminal (Admin), and accept the prompt.
- Run Test-ComputerSecureChannel -Verbose. True means the trust is fine; False means it’s broken.
- If it’s False, run Test-ComputerSecureChannel -Repair -Credential (Get-Credential) and enter a domain account allowed to manage computer accounts, in the form DOMAINusername.
- Run the test again. Once it says True, sign out and sign in with your domain account.
You can add -Server with a domain controller name if the PC keeps picking an unreachable one. This cmdlet is for member PCs only; on a domain controller it can give false results.
Fix 3: Reset the machine account password
If the repair fails, reset the password directly with Reset-ComputerMachinePassword in an administrator PowerShell window:
Reset-ComputerMachinePassword -Server DC01.yourdomain.local -Credential YOURDOMAINAdmin
Swap in your own domain controller name and admin account; you’ll be asked for the password. Then restart and sign in with your domain account. An admin can also run it remotely through Invoke-Command if PowerShell remoting works on that PC.
Older guides tell you to use netdom resetpwd on the workstation. Microsoft’s current netdom resetpwd page describes it as a tool for domain controllers that ships with the AD DS role or RSAT, so on an ordinary Windows 10 or 11 PC the PowerShell cmdlet is the cleaner choice.
One thing not to do: right-clicking the computer in Active Directory Users and Computers and choosing Reset Account on its own. Microsoft’s Directory Services post explains that this sets a default password the PC won’t know, so the trust stays broken until the PC is rejoined.
Fix 4: Remove the PC from the domain and join it again
This always works if the PC can reach a domain controller, but it takes two restarts and more admin work than the other fixes. Use it when Fixes 2 and 3 fail.
With PowerShell
- In an administrator PowerShell window, run Remove-Computer -UnjoinDomainCredential YOURDOMAINAdmin -PassThru -Verbose -Restart. Microsoft’s Remove-Computer page notes this disables the PC’s domain account and moves it to a workgroup.
- After the restart, sign in with the local admin account.
- Run Add-Computer -DomainName yourdomain.local -Credential YOURDOMAINAdmin -Restart. Per Microsoft’s Add-Computer page, if you name a specific domain controller with -Server, use its full name (FQDN); that became a requirement in August 2024.
- Sign in with your domain account after the PC restarts.
With Settings in Windows 10 or 11
- Go to Settings > Accounts > Access work or school.
- Select the entry with your domain name, choose Disconnect, confirm, and restart.
- Sign in with the local account and return to Access work or school.
- Choose Connect, then Join this device to a local Active Directory domain.
- Type the domain name, enter domain admin credentials, and restart.
If the rejoin fails with a duplicate account error, delete or reset the old computer object in Active Directory first, then join again.
Stop the error coming back
A one-off is usually a restore or a laptop that’s been in a drawer. Repeat offenders need a root cause:
- Snapshots and images: after rolling back a VM or restoring an image, run Test-ComputerSecureChannel before anyone signs in.
- Cloned PCs: generalize images with Sysprep, and check for two machines using one name.
- Time: make sure clients sync time with the domain hierarchy.
- Don’t stretch the password age to hide it. Microsoft warns that lengthening or disabling machine password changes gives attackers more time to brute-force machine accounts.
Microsoft’s old KB 2914474 also describes an intermittent version of this error on Windows 7 SP1 and Windows Server 2008 R2 SP1 fixed by a hotfix; current Windows versions aren’t affected by that specific bug.
Frequently asked questions
How often does a domain PC change its machine password?
Every 30 days by default. Admins can set the Domain member: Maximum machine account password age policy anywhere from 1 to 999 days, but Microsoft recommends keeping it around 30.
Can I fix the trust relationship error without a local admin account?
Only if the PC can still be reached some other way, such as a remote PowerShell session from an admin’s machine. Without any local admin login, Microsoft’s tools can’t run on the PC, and Petri warns you may end up reimaging it. Never remove a PC from the domain until you’ve confirmed a local account works.
Is the trust relationship error a virus or a hack?
Almost never. It means the PC’s machine account password no longer matches the one stored in Active Directory, which usually happens after a restore, a clone, or a long time off the network.
Why does the error say ‘primary domain’?
The primary domain is simply the Active Directory domain the PC is joined to. The message means the PC can’t prove its identity to that domain’s controllers.
Does Test-ComputerSecureChannel work on a domain controller?
No. Microsoft says it can return false results on domain controllers and recommends netdom or nltest there instead. It’s meant for member computers like workstations and servers.
Sources
- Microsoft Learn: Troubleshoot a failed trust relationship
- Microsoft Learn: Test-ComputerSecureChannel
- Microsoft Learn: Reset-ComputerMachinePassword
- Microsoft Learn: Remove-Computer and Add-Computer
- Microsoft Learn: Maximum machine account password age
- Microsoft Directory Services blog (archive)
- Petri IT Knowledgebase
- Microsoft Q&A threads: Windows Server 2022 domain, Windows Server 2019 domain, fix without reboot
Featured image: Polina Zimmerman / Pexels
