Fix RPC_S_INVALID_AUTH_IDENTITY 0x000006D5 Error

This error pops up when Windows can't verify your login credentials during remote connections. It's a security context mismatch, not a hardware problem.

When does this error happen?

You'll see RPC_S_INVALID_AUTH_IDENTITY (0x000006D5) most often when you're trying to connect to a remote computer using Remote Desktop, PowerShell Remoting, or a mapped network drive. The exact trigger is usually after you've changed your Windows password or domain credentials. You might be trying to connect to a server or another PC on your network, and suddenly it says the security context is invalid. I've seen this a lot in corporate environments where people reset their passwords but don't clear their old cached credentials.

What causes error 0x000006D5?

The root cause is simple: Windows is holding onto old authentication tickets or cached credentials that don't match what the remote system expects. The Remote Procedure Call (RPC) service can't verify who you are because the security context—the ticket that proves your identity—is stale or corrupted. This isn't a network issue or a faulty cable. It's a credential mismatch.

Windows uses Kerberos by default for domain authentication. When you change your password, Kerberos tickets from your old password are still cached. The remote server sees an invalid ticket and refuses the connection. Sometimes it's a simple case of stored credentials in Credential Manager pointing to an old password.

Possible Cause	What Happens
Outdated Kerberos ticket	You changed your password but didn't log out/in again.
Stale credentials in Credential Manager	Windows saves old username/password for the remote resource.
Domain controller time sync issue	Kerberos is time-sensitive; if your PC clock is off by >5 minutes, tickets fail.
Corrupted RPC service state	RPC itself might need a restart to clear stale data.

How to fix RPC_S_INVALID_AUTH_IDENTITY

Here's the fix I've used hundreds of times. Follow these steps in order. Don't skip any.

Clear your cached credentials in Credential Manager.
Open Control Panel. Go to User Accounts > Credential Manager. Click "Windows Credentials." Look for any entry that matches the remote computer name or IP address you're trying to connect to. Click the arrow to expand it, then click "Remove." Confirm when prompted. After removing, close Credential Manager.

You should expect to see no entries related to that remote machine when you're done.
Flush the Kerberos ticket cache from an admin command prompt.
Right-click the Start button and pick "Windows Terminal (Admin)" or "Command Prompt (Admin)." Type this command and press Enter:
```
klist purge
```
You'll see a message saying "Current LogonId is 0:0x..." and then "Deleted all tickets for the session." That's how you know it worked. This wipes all cached Kerberos tickets so Windows has to request fresh ones.

Important: You need to be logged in as the user who's getting the error. Don't run this as a different admin account.
Restart the RPC service.
Open Services.msc (just hit Windows+R, type services.msc, press Enter). Scroll down to "Remote Procedure Call (RPC)." Right-click it and select "Restart." If that option is grayed out, right-click and pick "Stop," then right-click again and pick "Start." This forces RPC to drop any stale internal state.

After the restart, you'll see the status column change to "Running" again. That's your confirmation.
Log off and log back in.
This is the step most people skip. Just clearing credentials isn't enough if your current Windows session still has old tokens. Log off completely (Start > your profile icon > Sign out). Log back in with your current password. This forces a fresh Kerberos ticket grant from the domain controller.
Try the remote connection again.
Open Remote Desktop Connection or whatever tool you were using. Type the remote computer name or IP. Use your current credentials. It should connect now without showing 0x000006D5.

If it still fails after these steps

Check the clock on your local machine. Kerberos is strict about time. If your PC's system time is off by more than 5 minutes from the domain controller, tickets get rejected. Go to Settings > Time & Language > Date & Time. Toggle "Set time automatically" on and off to force a re-sync. Then run w32tm /resync in an admin command prompt to force a manual sync.

Another thing: if you're connecting to a computer that's not on the same domain, or you're using local accounts, the problem might be that you're trying to pass domain credentials to a machine that only accepts local accounts. In that case, prepend the username with the remote computer name: REMOTE-PC\username instead of DOMAIN\username.

If you're still stuck, check if the remote computer's RPC service is running. You can test that by pinging the remote IP and then running rpcping -s REMOTE_IP in a command prompt. If that fails, the remote machine has its own RPC problem.