STATUS_UNSUPPORTED_PREAUTH (0XC0000351) Kerberos Fix
Kerberos pre-auth mechanism mismatch between client and DC. Usually from a domain controller or client with outdated crypto settings.
The 30-Second Fix: Check the Client's Kerberos Encryption
What's actually happening here is that your computer presented a pre-authentication timestamp that the domain controller couldn't decrypt. The DC expected a specific encryption type — likely AES256 — but got something else, usually RC4 or DES. This happens most often after a Windows update or when a non-domain-joined machine tries to authenticate.
First, check what encryption types your client supports. Open an elevated PowerShell and run:
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
If you see a SupportedEncryptionTypes DWORD, note its value. If it's missing, that's fine — Windows defaults to all types. But if it's set to 0x7 (RC4 + DES + AES128) or lower, you're likely missing AES256, which many modern DCs require.
The quick fix: set it to 0x7FFFFFFF (allow all), or 0x18 (AES128 + AES256 only). Run this:
New-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters -Name SupportedEncryptionTypes -Value 0x7FFFFFFF -PropertyType DWORD -Force
Reboot the machine. If the error disappears, you're done. This works about 60% of the time — the client was blocking stronger encryption.
The 5-Minute Fix: Domain Controller Audit and Policy Check
If the client fix didn't help, the problem might be on the DC side. The DC might not be offering the encryption type your client uses, or the pre-auth data is corrupted.
Enable Kerberos logging on the DC. Open Event Viewer, go to Windows Logs > Security, and look for event ID 4768 (Kerberos TGT requested) and 4771 (pre-authentication failed). The failure code 0x1F or 0x12 usually accompanies 0XC0000351.
Now check the DC's group policy. Open Group Policy Management, edit the Default Domain Controllers Policy, and go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Find Network security: Configure encryption types allowed for Kerberos. Make sure AES256_HMAC_SHA1 is checked. Uncheck RC4 if it's checked — you don't want weak crypto lingering.
Then on the same DC, verify the supported encryption types registry key exists:
Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
If it's missing, create it with value 0x7FFFFFFF, same as the client. Run gpupdate /force and restart the Kerberos Key Distribution Center service (kdc) — or just reboot the DC if that's practical.
The reason this works is that the KDC uses its own encryption type list when generating the pre-authentication challenge. If the list doesn't include the client's supported type, the handshake fails before any ticket is issued.
The 15+ Minute Fix: Network Capture and Manual Decryption
If neither of the above resolved it, you're dealing with a deeper mismatch — perhaps a time skew, a misconfigured trust, or a third-party Kerberos stack (like from a Linux box or a network appliance).
Install WireShark (or use netsh trace) and capture the Kerberos exchange. Filter on kerberos and look for the KRB_ERROR packet with error code KDC_ERR_PREAUTH_FAILED (0x1F).
Export the capture to a .pcapng file. Open it in WireShark and follow the TCP stream for the Kerberos packets. Pay attention to ETYPE-INFO2 in the KRB_AS_REQ. This is the list of encryption types the client claims to support. If the list is empty or contains only RC4 (type 23), but the DC only offers AES (type 18), you'll get this error.
Now check the client's registry again — but this time, look deeper. Some applications (like VMware Horizon or Citrix) override the system Kerberos settings via their own registry keys. Check:
HKLM\SOFTWARE\Wow6432Node\[VendorName]\Kerberos
If you find any SupportedEncryptionTypes there, that application's settings override the system-level key. You'll need to either remove that key or set it to the same value (0x7FFFFFFF).
As a last resort — and I mean last — you can force the DC to downgrade to RC4. This is bad for security, but it works. On the DC's registry, add:
HKLM\SYSTEM\CurrentControlSet\Services\Kdc\AllowRc4
Set to DWORD 1 and reboot the DC. This tells the KDC to accept RC4 pre-authentication even if the policy says otherwise. Don't leave this on. Once the client authenticates, remove the key.
One more thing: check the system clock. A drift greater than 5 minutes between client and DC will cause pre-auth failures that look like crypto errors. Run w32tm /query /status on both machines. If they're off, reconfigure time sync.
That's it. Start with the registry fix on the client — that's your most likely win. Move to the DC policy if it persists. Only break out the network capture for the nasty edge cases.
Was this solution helpful?