Fix ERROR_MUTUAL_AUTH_FAILED (0X00000575) Fast

What's going on with 0x00000575?

You're trying to RDP into a server or access a network share, and boom—you hit ERROR_MUTUAL_AUTH_FAILED (0x00000575). The system tells you mutual authentication failed, which is Microsoft-speak for "I don't trust you and you don't trust me." This usually happens when Kerberos or NTLM can't confirm both sides of the handshake.

I've seen this most often when:

• A domain admin tries to RDP into a server that's off the domain (or vice versa)
• Time is off by more than 5 minutes between client and server
• SPNs are duplicated or missing for a service account
• Kerberos tickets are stale or corrupted

Let's walk through the fixes in order. Start with the 30-second check, then move down if it's still broken.

Fix 1: Sync your clocks (30 seconds)

This is stupidly simple, but I can't tell you how many times I've watched a sysadmin spend 20 minutes rebuilding a server only to find the CMOS battery was dead. Kerberos requires the client and server clocks to be within 5 minutes of each other. NTLM is a little more forgiving, but still fussy.

1. On the client: Right-click the clock → Adjust date/time → turn on Set time automatically.
2. On the server: Do the same. If they're both domain-joined, they should sync from the domain controller.
3. Open Command Prompt as admin and run:

   w32tm /resync

   If that fails, force it:

   w32tm /config /manualpeerlist:pool.ntp.org /syncfromflags:manual /reliable:yes /update
   net stop w32time && net start w32time
   w32tm /resync

4. Test your RDP again. If it works, you're done.

Fix 2: Clear stale Kerberos tickets (5 minutes)

Time is fine? Let's flush the auth tokens. Kerberos tickets can go bad if they were issued before a clock correction, or if a user password changed mid-session. This is my go-to for "it worked yesterday" scenarios.

1. On the client machine, open Command Prompt as admin.
2. Run:

   klist purge

   This nukes all cached Kerberos tickets.
3. Optional but thorough: Run klist sessions to see what's hanging, then klist purge -li 0x3e7 to clear system-level tickets too.
4. Log off and log back in. This forces a fresh TGT request from the domain controller.
5. Try connecting again. If the error disappears, you're golden.

If you're on a workgroup machine or non-domain setup, skip to Fix 3—Kerberos isn't your issue.

Fix 3: Fix Service Principal Names (15+ minutes)

This one's more involved. ERROR_MUTUAL_AUTH_FAILED often comes from a bad or duplicate SPN. For example, you set up a service account to run SQL Server or IIS, and it has an SPN like HTTP/servername.domain.com. If that SPN is registered on two different accounts, Kerberos throws a fit.

1. On a domain controller or machine with RSAT tools, open PowerShell as admin.
2. Check for duplicates on the target server name:

   setspn -Q HTTP/server.domain.com

   Replace HTTP/server.domain.com with whatever SPN your service is using. If it returns multiple accounts, you've got a duplicate.
3. Remove the duplicate SPN from the wrong account:

   setspn -D HTTP/server.domain.com wrongaccount

4. If the SPN is missing entirely, add it to the service account:

   setspn -A HTTP/server.domain.com correctaccount

5. Wait a few seconds for replication, then test the connection.

I've also seen this error when someone changes a computer name without updating the SPNs. If you recently renamed a server, run setspn -X to find conflicts, then setspn -A the correct ones.

Still stuck? A few more edge cases

• NTLM disabled on the server: Check Group Policy under Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options. Look for Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers. If it's set to Deny all, change it to Allow all or Audit.
• Firewall blocking Kerberos ports: Kerberos uses UDP/TCP 88. Make sure it's open between client and domain controller.
• IPv6 issues: If you're on a domain with broken IPv6, try disabling IPv6 on the client network adapter temporarily to force Kerberos over IPv4.

If nothing above worked, drop the server name and try connecting via IP address. If that works but the hostname doesn't, you've got a DNS or SPN mismatch. Run nslookup servername to confirm it resolves correctly.

Pro tip from my help desk days: Before you go deep into SPN trouble, always check the system event logs on both sides. Filter for Kerberos errors (event ID 4, 7, 27) and NTLM errors (event ID 8001, 8002). They'll point you straight at the culprit.