First, the 30-second fix: Check the obvious
I know this error is infuriating, especially when it pops up mid-login. But before you start resetting accounts or rebuilding trust, do a quick sanity check.
This error means the secure channel between two domains (or a domain and a workstation) has been severed. The most common trigger? Someone changed the machine's password (the computer account password, not a user password) or the system clock is off by more than five minutes. Kerberos is picky about time.
- Verify the date and time on the client machine. Right-click the clock, choose Adjust date/time, and make sure it's synced. If it's off, toggle Set time automatically off and on again.
- If time looks good, try a simple reboot. Yeah, it sounds lame, but a reboot often clears a temporary session or token issue that's masquerading as a trust failure.
- Still failing? Try logging in with a local account (e.g.,
.\Administrator) to confirm the machine itself is alive and the issue is only with domain authentication.
If that didn't save you, move on. This next step fixes the majority of cases.
Moderate fix (5 minutes): Reset the machine account trust
This is the real fix for most of you. The computer account in AD has gotten out of sync with the local machine's stored password. You'll need domain admin credentials for this. Skip this if you're not a domain admin — head to the advanced section.
From the affected workstation, run PowerShell as administrator:
Test-ComputerSecureChannel -Repair -Credential (Get-Credential)Enter a domain admin's username and password when prompted. The -Repair flag forces a reset of the secure channel. That's it. If it comes back True, reboot and try logging in.
No PowerShell? Use the old-school netdom command:
netdom resetpwd /Server:<DCName> /UserD:<AdminUser> /PasswordD:*Replace <DCName> with your domain controller, and <AdminUser> with a domain admin. You'll be prompted for the password.
This trips up a lot of people because the error message mentions "primary domain and the trusted domain," which makes you think it's a cross-domain trust (like between two AD forests). In my experience, 80% of the time it's just a workstation that lost its secure channel to its own domain. So try this before you go rebuilding forest trusts.
Advanced fix (15+ minutes): Rejoin the domain or rebuild the trust
If the reset didn't work, or if you're dealing with a true inter-domain trust (like a child domain to a parent, or a separate forest), we go deeper.
Scenario A: Cross-domain trust is broken
You see this error on a domain controller trying to authenticate against another domain. The trust relationship between the two domains is corrupt. You'll need to verify and potentially re-create it.
On the domain controller, open Active Directory Domains and Trusts. Find the trust, right-click it, and select Properties. Go to the Trust tab and click Validate. It'll ask for credentials for the other domain. If validation fails, you need to remove and re-add the trust.
To remove:
netdom trust <OtherDomain> /domain:<YourDomain> /remove /bothThen re-add:
netdom trust <OtherDomain> /domain:<YourDomain> /add /both /realmReplace the placeholders with your actual domain names. Then set the trust type (external, forest, etc.) via the GUI or scripts. This is delicate, so have a rollback plan.
Scenario B: Workstation can't rejoin even with admin rights
If the secure channel repair fails, or you don't have admin rights on the machine, the nuclear option is to unjoin and rejoin the domain. This always works, but it's a pain because you lose the machine's SID, and any local profiles tied to domain users will get new profiles.
Here's the clean way to do it without leaving a stale account:
- Use the ADUC (Active Directory Users and Computers) console on a domain controller to reset the computer account: right-click the machine, select Reset Account. This resets the machine password in AD.
- On the workstation, run PowerShell as admin and type:
Reset-ComputerMachinePassword -Credential (Get-Credential) -Server <DCName>If that fails, then do the full unjoin/rejoin:
Remove-Computer -UnjoinDomaincredential (Get-Credential) -Force
Add-Computer -DomainName <YourDomain> -Credential (Get-Credential) -RestartI hate recommending this because of the profile headache, but sometimes it's the only thing that sticks.
When all else fails
Check DNS. Yes, DNS. I've seen 0x6FC errors caused by a workstation pointing to a dead DNS server, making it unable to find the domain controller. Run nslookup and confirm your DC resolves. Fix DNS and the trust issue disappears like magic.
Also, check if the computer object is in a different OU or has been accidentally deleted. You can find the object in AD, and if it's missing, that's a bigger issue — you'll need to rejoin anyway.
One last tip: If you're in a hybrid Azure AD setup, sometimes the on-prem trust works fine but the Azure side is out of sync. Run dsregcmd /status to check the device registration state.
You've got this. Most cases are fixed by the moderate step, so don't panic. But if you're stuck, drop a comment below and I'll help you troubleshoot further.