Fix Trusted Domain Failure 0xC000018C in 3 Steps

What Actually Triggers This Error

I see this most often after a machine has been offline for a stretch, or when someone renames a domain controller without properly updating the DNS records. Had a client last month whose entire print queue died because they moved a server to a different subnet and forgot to update the reverse lookup zone. The error shows up as STATUS_TRUSTED_DOMAIN_FAILURE (0XC000018C), usually when you're trying to log in with a domain account or access a network share. The system can't validate the trust relationship between the workstation and the domain controller.

The core problem is that the secure channel—the cryptographic handshake between the machine and the domain—is broken. Could be a password mismatch on the machine account, or the DC can't find the machine in DNS. Either way, you're locked out until you fix it. Let's run through the fixes in order, from least invasive to full reset.

Step 1: 30-Second Fix – Check DNS and Network Connectivity

Before you do anything drastic, rule out the obvious. Half the time, this error is just a DNS hiccup. Open a command prompt as administrator and run:

nslookup yourdomain.com
ipconfig /flushdns
ipconfig /registerdns

If nslookup fails to resolve your domain, your DNS settings are wrong. Check the network adapter's DNS server—it should point to your domain controller, not 8.8.8.8 or your ISP. On the client machine, run ipconfig /all and verify the DNS suffix matches your domain. Had a case where someone set a static IP with the wrong DNS server, and the domain trust broke after a reboot. Fixed it in under a minute by switching back to DHCP with the right DNS.

Also confirm the machine can ping the domain controller by FQDN: ping dc01.yourdomain.com. If that fails, check that the DC is actually online and reachable on the network. If it's a VM, make sure it didn't get moved to a different network switch.

Step 2: 5-Minute Fix – Reset the Machine Account Password

If DNS is fine, the machine account password might be out of sync. Windows changes this password every 30 days by default, but if the machine hasn't talked to a DC in a while, the stored password won't match what the DC has. You can fix this without a full unjoin/rejoin.

On the client machine, run PowerShell as administrator:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Enter domain admin credentials when prompted. This command resets the secure channel by updating the machine account password on both sides. I've used this on Windows 10 and Server 2019, works every time. If the command succeeds, reboot the machine and try logging in with a domain account.

If PowerShell isn't your thing, use nltest from an elevated command prompt:

nltest /sc_reset:yourdomain.com\dc01.yourdomain.com

Replace with your actual DC name. This forces a secure channel reset. Run nltest /sc_query:yourdomain.com afterward to verify it says Status = 0 0x0 NERR_Success. If it still shows an error, move to the next step.

Step 3: 15+ Minute Fix – Unjoin and Rejoin the Domain

When the secure channel repair fails, you're looking at a broken machine account. Maybe the object got deleted in AD, or the SID mismatch is too severe. You'll need to unjoin the domain, reboot, then rejoin. This is the nuclear option, but it's reliable.

First, log in with a local admin account. If you don't have one, enable the built-in administrator with net user administrator /active:yes and set a password. Then:

1. Go to Settings > System > About > Rename this PC (advanced).
2. Under Computer Name/Domain Changes, select "Workgroup" and enter a temporary workgroup name (like WORKGROUP). Click OK and reboot.
3. After reboot, go back to the same dialog, select "Domain", and enter your domain name. Provide domain admin credentials when prompted. Click OK and reboot again.

Don't skip the reboot between steps—Windows needs to flush the old trust. I've seen techs try to do it in one pass and it fails because the machine still holds the stale secure channel. Reboot both times.

If you're doing this remotely using PowerShell, the command is:

Remove-Computer -UnjoinDomaincredential (Get-Credential) -Force
Restart-Computer
Add-Computer -DomainName yourdomain.com -Credential (Get-Credential) -Restart

This takes two reboots but handles the whole process. Make sure you have local admin access before running the remove—if the domain is down, you'll be locked out.

When to Stop and Call in Help

If you've done the DNS check, the secure channel repair, and a full unjoin/rejoin, and the error still appears, something deeper is wrong. Check if the machine account exists in AD—use AD Users and Computers to verify it's not disabled or missing. Also look for duplicate machine accounts in the same OU. I once wasted an hour because a junior admin had created a second object with the same name in a different OU, and the DC got confused.

Another rare cause: time skew between the client and DC. Kerberos requires clocks to be within 5 minutes. Run w32tm /query /status on the client and compare with the DC. If they're off, fix with w32tm /resync or adjust the time manually.

If none of that works, open ADSI Edit and check the userAccountControl attribute of the machine account. Should be 4096 (WORKSTATION_TRUST_ACCOUNT). If it's anything else, you've got a corrupted object that needs to be deleted and recreated from scratch.

Bottom line: start with DNS, then repair the secure channel, then rejoin. That order catches 95% of cases. Skip the fluff, fix the trust, and get back to work.