Fix ERROR_NO_TRUST_LSA_SECRET (0X000006FA) on Windows Domain

Why You’re Seeing 0X000006FA

I know this error is infuriating. It pops up when you try to log into a domain-joined Windows system, and suddenly you’re staring at a login box that won’t accept any credentials. The actual message is “The workstation does not have a trust secret.” That’s Microsoft’s way of saying the secure channel between your PC and the domain controller (DC) is broken. The local machine’s copy of the shared secret (the LSA secret) doesn’t match what the DC expects.

This happens more often than you’d think. Common triggers: restoring a VM snapshot that rolled back the computer account password (which changes every 30 days by default), cloning a virtual machine without sysprep, or a network glitch during password rotation. I’ve seen it on Windows 10 22H2, Server 2019, and Server 2022 after a DC upgrade gone sideways.

Don’t panic. You don’t need to unjoin and rejoin the domain. That’s a last resort. Let’s fix the trust without touching your user profiles or Group Policy.

Cause #1: Computer Account Password Mismatch (Most Common)

The machine account in Active Directory has a password (the LSA secret) that’s updated every 30 days. If your PC’s local copy and the DC’s copy don’t match, you get 0X000006FA. The quickest fix is to reset the secure channel using Netdom or nltest.

Fix: Reset the Secure Channel with Netdom

You’ll need a domain admin account. If you can’t log in locally with a cached credential (like a local admin), boot into Safe Mode with Networking and use a local admin account. From there:

1. Open Command Prompt as Administrator.
2. Run this command, replacing YourDomain.com with your actual domain and YourDC with a domain controller name:

   netdom resetpwd /s:YourDC /ud:YourDomain\Administrator /pd:*

   You’ll be prompted for the admin password.
3. Wait for “The machine account password for this computer was successfully reset.”
4. Reboot and try logging in with your domain account.

This command directly updates the LSA secret on both sides. It’s my go-to because it’s atomic — doesn’t require rebooting the DC or messing with ADSI Edit.

Alternative: Use nltest

If netdom isn’t available (it’s not on Home editions, but you shouldn’t be running Home on a domain anyway), use nltest:

nltest /sc_reset:YourDomain.com

This forces a renegotiation of the secure channel. It works about 80% of the time. If it fails with “Status = 5 0x5 ERROR_ACCESS_DENIED,” you’re not running as admin, or the local cached credentials are stale.

Cause #2: Corrupted LSA Database or Registry Keys

Less common but nasty: the LSA secrets store (under HKLM\SECURITY hive) gets corrupted. This can happen after a failed security update, a crash during password rotation, or malware that messed with the registry. The symptom is persistent 0X000006FA even after a netdom resetpwd that reported success.

Fix: Delete and Recreate the LSA Secret Key

Warning: This requires a reboot and can break other services if done wrong. Do this only after backing up the registry.

1. Open Regedit as Administrator.
2. Navigate to HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets. You’ll see a subkey named $MACHINE.ACC.
3. Right-click $MACHINE.ACC and select Export — save it as a backup.
4. Delete the $MACHINE.ACC key.
5. Reboot the machine. Windows will regenerate the key on startup.
6. Run netdom resetpwd again. The trust should now reset cleanly.

I’ve done this on Windows Server 2016 boxes post-CrowdStrike updates that corrupted the SECURITY hive. It’s safe if you follow the steps. If you see errors after reboot like “The trust relationship failed,” you might need to rejoin the domain anyway — but try the reset first.

Cause #3: DNS Resolution Failure or DC Unavailability

Sometimes the error isn’t about the secret itself, but your machine can’t contact a domain controller to verify it. This is especially sneaky because the error text still says “trust secret.” If you’ve tried the above fixes and they fail silently, check DNS.

Fix: Validate DNS and Connectivity

1. Run ipconfig /all and note the DNS server listed. It should point to a domain controller (e.g., 192.168.1.10), not a public DNS like 8.8.8.8.
2. Test resolution:

nslookup yourdomain.com

If it returns “Non-existent domain” or an external IP, your DNS is wrong.

3. Change your network adapter’s DNS to the domain controller’s IP:

netsh interface ip set dns "Ethernet" static 192.168.1.10

4. Flush DNS and restart the Netlogon service:

ipconfig /flushdns
net stop netlogon && net start netlogon

5. Retry nltest /sc_reset:YourDomain.com.

I’ve seen this error pop up when a site’s DNS server failed and the backup was external. The DC was reachable by IP but not by name. Adding a static entry in C:\Windows\System32\drivers\etc\hosts as a temporary workaround saved the day: 192.168.1.10 DC01.yourdomain.com.

Quick-Reference Summary Table

That’s the playbook. Start with netdom resetpwd — it works for 9 out of 10 cases. If that fails, move down the list. And if you’re still stuck after all three, you might have a deeper AD issue (like a tombstoned computer object). Check the object in Active Directory Users and Computers; if it’s missing or disabled, you’ll need to rejoin. But that’s rare. The fixes above will get you back online fast.