Fix STATUS_NO_KERB_KEY 0XC0000322 in 3 Steps

Why You're Seeing This Error

I know this error is infuriating — especially when it pops up mid-workflow and kills access to a file share, SQL database, or remote management tool. The exact trigger varies, but I've seen it most often on Windows Server 2016 and 2019 after a domain controller reboot or when a server's computer account password gets out of sync. The error code 0xC0000322 maps to STATUS_NO_KERB_KEY, meaning the Kerberos Key Distribution Center (KDC) on the target server can't find a usable key for authentication.

The bad news: it's not always obvious which fix works. The good news: I've broken this down into three tiers. Start with the simplest fix (30 seconds), then the moderate fix (5 minutes), then the advanced fix (15+ minutes). You can stop the moment the error disappears.

Simple Fix (30 Seconds) — Check Time Sync

This one trips up even experienced admins. Kerberos is brutally time-sensitive — if the client and server clocks drift more than 5 minutes by default (the default tolerance in Windows domains), the KDC rejects the ticket request with 0xC0000322.

Here's what you do:

On the server or client showing the error, open Command Prompt as Administrator.
Run
```
w32tm /query /status
```
to check the current time source and offset.
If the offset is more than a few seconds, sync immediately:
```
w32tm /resync /nowait
```

If resync fails, force it:

w32tm /config /syncfromflags:domhier /update && net stop w32time && net start w32time

Test the connection again. If the error disappears, you're done. If not, move on.

Why this works: I've seen a Hyper-V host with 3-minute drift cause this error across all guest VMs. Syncing the host fixed the entire farm. Don't skip this step — it's the fastest and most common fix.

Moderate Fix (5 Minutes) — Verify and Fix SPNs

If time is fine, the next culprit is a missing or duplicate Service Principal Name (SPN). The KDC uses SPNs to map a service to a specific server account. When the SPN is wrong, the KDC can't issue a key, and you get 0xC0000322.

This usually happens after you rename a server, move it to a different OU, or clone a VM without sysprep.

Steps:

On a domain controller (or from a machine with RSAT), open PowerShell as Administrator.
Identify the SPNs for the service that's failing. For example, if it's a SQL Server named SRV-DB01, run:
```
setspn -L SRV-DB01
```
Look for duplicate SPNs across the domain:
```
setspn -X
```
This lists any SPNs registered to multiple accounts. Duplicates cause the KDC to pick the wrong one.
If you find a duplicate, remove the extra one:
```
setspn -D  
```
If the SPN is missing entirely (say, for HTTP or HOST), add it:
```
setspn -A HTTP/SRV-DB01.contoso.com contoso\SRV-DB01$
```

After fixing SPNs, purge the Kerberos ticket cache on the client:

klist purge

Then retry the connection.

Real-world scenario: I once helped a team that cloned a file server VM without sysprep. The clone had the same SPNs as the original, causing random 0xC0000322 errors for users. Running setspn -X and removing the duplicate from the clone fixed it instantly.

Advanced Fix (15+ Minutes) — Reset the Server's AD Account Password

If time and SPNs are clean, the server's computer account password in Active Directory is likely out of sync with the local machine. This happens when you restore a server from backup, promote/demote a DC, or the server has been offline for months.

You'll need Domain Admin credentials for this — or delegated rights to reset computer accounts.

On the problematic server, open PowerShell as Administrator.
Reset the machine account password locally:
```
Reset-ComputerMachinePassword -Server  -Credential (Get-Credential)
```
Replace <DCName> with a domain controller's name (preferably one that's working).
If that fails, use the classic netdom command:
```
netdom resetpwd /s: /ud:\ /pd:*
```
You'll be prompted for the admin password.
After the reset, restart the server to flush all Kerberos tickets.
Optionally, verify the new password is in sync by checking the ms-DS-MachineAccountQuota attribute or running
```
nltest /sc_verify:
```

Why this takes 15+ minutes: The reset itself is fast, but you might need to restart services or the whole server. Also, if the server is a domain controller, you'll need to run

netdom resetpwd

on another DC first, then seize roles if necessary. That's a separate process — for non-DC servers, the above is sufficient.

Pro tip: Before the reset, check the event logs on the server under System and Security for Event ID 5723 or 3210. Those explicitly say the computer account password is wrong. If you see them, skip to this fix.

When to Call in the Heavy Artillery

Rarely, the issue is deeper — like a forest trust misconfiguration or a missing root CA for Smart Card authentication. If you've done all three steps above and still get 0xC0000322, check:

DNS: Can the client resolve the target server's hostname? Run
```
nslookup 
```
and verify the result matches the server's IP.
Kerberos logs: Enable Kerberos logging on the client via registry:
```
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
```
Add a DWORD LogLevel = 0x1. Then reproduce the error and check System event log for Kerberos entries.
Group Policy: Check if a GPO is setting the Network security: Restrict NTLM policies. Kerberos falls back to NTLM, but if NTLM is restricted, you get weird errors.

But honestly, 90% of the time, one of the three fixes above resolves it. Start with time sync, then SPNs, then the password reset. You've got this.