Fix STATUS_NO_TRUST_LSA_SECRET (0XC000018A)

Quick answer

Run netdom reset /domain: /UserO:Administrator /PasswordO:* on the workstation, or rejoin the domain from scratch.

What's actually happening

Error 0XC000018A means the local LSA database on your Windows machine doesn't hold a trust secret – the encrypted password shared with your domain controller. This secret proves your workstation is legit. It gets deleted or corrupted when the machine account password is reset out of band (e.g., another admin removed and re-added the computer object in AD), when the system is restored from a backup older than the password change, or after a domain controller restore that doesn't replicate forward. You'll see this as a login failure – the workstation refuses to authenticate to the domain, usually right after a reboot or a network change.

Fix steps

1. Verify the error – Check the System event log for Event ID 5722 or 5719 alongside 0XC000018A. Also run nltest /sc_verify: from an elevated command prompt. If it returns The trust password is not known, you're confirmed.
2. Reset the secure channel with netdom – On the affected workstation, open an elevated command prompt as Administrator. Run:
   

   netdom reset %COMPUTERNAME% /domain:yourdomain.com /UserO:Administrator /PasswordO:*

   Type the domain admin password when prompted. This resets the machine account password on both sides – the workstation LSA and the AD object. The key: netdom flips the password to a new random value and updates AD, so the trust secret matches again. Test with nltest /sc_verify:yourdomain.com – you should see Success.
3. Reboot and test – Restart the workstation. Try a domain login. If you still get the error, move to alternative fixes.

Alternative fixes

Rejoin the domain

If netdom fails (maybe the computer object is orphaned), rejoin:

1. Unjoin: go to System Properties > Computer Name > Change, set to a workgroup (e.g., WORKGROUP). Restart.
2. Rejoin: same place, join the domain. Provide domain admin credentials. This creates a fresh machine account and trust secret. Restart again.
3. This is the nuclear option – it nukes all local SIDs from domain groups, so recreate any domain user profile references later.

Force secure channel reset via PowerShell

On Windows 10/11 or Server 2016+, you can use Reset-ComputerMachinePassword:

Reset-ComputerMachinePassword -Server  -Credential (Get-Credential)

This does roughly the same as netdom but via the AD PowerShell module. It's cleaner if you're already scripting.

Prevention tip

The root cause is almost always a machine account password mismatch. Don't delete and re-add computer objects in AD as a workaround – that breaks the trust. Instead, always use netdom reset or Reset-ComputerMachinePassword. Also, avoid restoring workstations from snapshots or backups older than 30 days – that's the default machine password change interval (though it can be up to 30 days in some environments). Set a scheduled task to run nltest /sc_verify weekly and alert on failure. Catch it before users notice.

One more thing: if you're in a multi-domain forest and the trust is cross-forest, this error can also appear when the inter-forest trust secret expires. Same fix applies – reset the trust with netdom trust /reset on the DC side.