Fix ERROR_NO_TRUST_SAM_ACCOUNT (0X000006FB) Step by Step

What is ERROR_NO_TRUST_SAM_ACCOUNT (0X000006FB)?

This error hits when Windows can't authenticate your login against the domain controller. The SAM (Security Account Manager) account for your PC's trust relationship is missing or mismatched. You'll see this after a system restore, cloning a hard drive, or if the computer account got deleted on the server side. The message says something like: "The trust relationship between this workstation and the primary domain failed." It's frustrating, but it's fixable.

Let's start with the fastest fix. If that doesn't work, go to the next one.

Fix 1: Quick Reboot (30 seconds)

Yes, I'm starting with the obvious one. Sometimes the trust failure is a temporary network hiccup. Reboot the machine. After it comes back up, try logging in again with your domain credentials. If it works, you're done. If you still see 0X000006FB, move on.

Fix 2: Disconnect and Reconnect to Network (2 minutes)

This works about 15% of the time in my experience. The machine might be trying to reach a domain controller that's offline. Here's what to do:

1. Disconnect the network cable or turn off Wi-Fi.
2. Reboot the machine. Log in with a local account (e.g., .\Administrator) if you have local admin credentials. If you don't remember the local admin password, you're stuck with Fix 3 or 4.
3. Once logged in locally, reconnect the network. Then open Command Prompt as administrator.
4. Run: nltest /sc_query:yourdomain.com (replace with your domain name). Look for the status. If it shows anything other than success, proceed to Fix 3.

This step usually confirms the trust is broken. You'll see an error like "ERROR_NO_TRUST_SAM_ACCOUNT" in the output. That's your confirmation.

Fix 3: Use Netdom to Reset the Trust (5 minutes)

This is the sweet spot. It works for 90% of users. You'll need domain admin credentials for this, not just local admin. If you have a second machine on the domain, run this from there. If not, you'll need to log in locally on the broken machine and run it with a domain admin account.

Step-by-step using Netdom:

1. Log in to the broken machine using a local administrator account. (If you can't, go to Fix 4.)
2. Open Command Prompt as administrator. Right-click Start, choose "Command Prompt (Admin)" or "Windows PowerShell (Admin)".
3. Type this command and press Enter:
   netdom resetpwd /server:DC01.yourdomain.com /userd:yourdomain.com\adminuser /passwordd:*
   Replace DC01.yourdomain.com with your domain controller's name, and yourdomain.com\adminuser with a domain admin account.
4. You'll be prompted for the password. Type it in (it won't show asterisks, that's normal). Press Enter.
5. Wait 10-15 seconds. You should see:
   "The machine account password for the local machine has been successfully reset."
6. Reboot the machine. Try logging in with your domain account. It should work now.

If you get an "Access denied" error, your domain admin account doesn't have rights. That's rare but check with your IT admin. Also, make sure the domain controller name is correct. Run nslookup yourdomain.com to verify it resolves.

Fix 4: Rejoin the Domain with PowerShell (15+ minutes)

This is the nuclear option. It works even if you can't log in locally. You'll need a domain admin account and the computer's local admin password. If you don't have either, you'll have to reinstall Windows. Sorry.

If you have local admin access:

1. Log in locally as .\Administrator (or another local admin).
2. Open PowerShell as administrator.
3. Remove the machine from the domain:
   Remove-Computer -ComputerName $env:COMPUTERNAME -UnjoinDomainCredential yourdomain.com\adminuser -WorkgroupName "WORKGROUP" -Force -Restart
   When prompted, enter the domain admin password. The machine will reboot.
4. After reboot, log in locally again. Then rejoin the domain:
   Add-Computer -DomainName yourdomain.com -Credential yourdomain.com\adminuser -Restart
   Enter the admin password again. Machine reboots.
5. Log in with your domain account. Should work.

If you can't log in locally (dead end):

Boot from a Windows installation USB. Choose Repair your computer > Troubleshoot > Command Prompt. From there, you can reset the local admin password using net user administrator * (if you know the old password) or use a third-party tool like Hiren's BootCD. Then follow the steps above.

Once back in the domain, verify with:
nltest /sc_query:yourdomain.com
It should show "The command completed successfully" and the trust type as "Primary Domain".

Why does this happen anyway?

Most common cause: Someone restored an old snapshot of the domain controller without checking the computer accounts. Or you cloned a disk with Sysprep not run. The machine's password (stored locally and in Active Directory) gets out of sync. Windows requires them to match exactly. When they don't, you get 0X000006FB.

Another sneaky cause: The computer account got deleted from AD by mistake. Check Active Directory Users and Computers. If the machine's name isn't in the Computers container, you'll need to rejoin from scratch (Fix 4).

Prevention tips

• Always run Sysprep before cloning Windows machines.
• Don't roll back domain controllers to snapshots. Use authoritative restore instead.
• Set the computer account password to reset automatically (it does by default every 30 days).

That's it. Start with the reboot, move through the netdom reset, and only go nuclear if you have to. Most days, Fix 3 is all you need.