Fix STATUS_KDC_UNKNOWN_ETYPE 0xC00002FD encryption error

Kerberos auth fails when the KDC doesn't support the encryption type requested by the client. Classic cause: old domain controller or misconfigured registry.

You're staring down STATUS_KDC_UNKNOWN_ETYPE (0xC00002FD). Translation: the Kerberos Key Distribution Center (KDC) got a request with an encryption type it doesn't support. This usually pops up when a Windows 10/11 client tries to authenticate against an older domain controller (Server 2008 R2 or 2012 R2) that has certain cipher suites disabled. Or when the krbtgt account's encryption keys got corrupted during a domain migration. Another common trigger: someone disabled RC4 in Group Policy but forgot to check if AES was actually enabled on the DC side.

Root Cause

Kerberos uses encryption types like RC4-HMAC, AES128-CTS-HMAC-SHA1-96, and AES256-CTS-HMAC-SHA1-96. The client says "I want to use AES256." The KDC says "I don't have that key." Boom — error 0xC00002FD. The culprit is almost always one of three things:

The krbtgt account's password hash was never updated to include AES keys (common on DCs upgraded from old domains).
Registry policy on the DC explicitly disables the requested encryption type (e.g., HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters with SupportedEncryptionTypes set wrong).
The client's Kerberos configuration only allows an etype not available on the DC (rare, but happens with custom security templates).

The Fix

Don't bother reinstalling Kerberos or rebuilding the domain. That's overkill. Do this:

Check DC encryption support. On a domain controller, open Command Prompt as admin and run:
```
klist -li 0x3e7
```
Look for the krbtgt ticket's encryption type. If you only see RSADSI RC4-HMAC and the client wants AES, that's your problem.
Verify the krbtgt keys. Run this PowerShell on a DC:
```
Get-ADUser krbtgt -Properties msDS-KeyVersionNumber, msDS-SupportedEncryptionTypes
```
If msDS-SupportedEncryptionTypes is missing or set to a low value (like 4 for RC4 only), you need to regenerate the keys.
Regenerate krbtgt password. This is safe if you do it right. Run on a DC with RSAT tools:
```
Reset-ADAccountPassword -Identity krbtgt -ResetPasswordOnNextLogon:$false

Set-ADUser krbtgt -PasswordNeverExpires:$true
```
Then force replication:
```
repadmin /syncall /AdeP
```
Wait 15 minutes for replication to finish.
Check registry on the DC. Open Regedit, go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters. If SupportedEncryptionTypes exists, set it to 0x7FFFFFFF (enables everything) or 0x20000000 (AES256 + RC4). Reboot the DC.
Flush Kerberos tickets on the client. On the affected machine, run:
```
klist purge

ipconfig /flushdns
```
Then reboot or lock/unlock the user account.

Still Failing?

If the error persists, check these:

Event ID 29 on the DC — gives the exact etype the client wanted. Look in System log under Kerberos source.
Double-check Group Policy — no policy disabling AES under Computer Config > Windows Settings > Security Settings > Network Security: Configure encryption types allowed for Kerberos. If you see that, set it to all four boxes.
Cross-domain trust issues — if this is a trust between forests, you might need to run ksetup /setenctypeattr on the trust relationship. I've seen this exact error when the trust only used DES (don't ask why).
Check the client's clock skew — if time is off by more than 5 minutes, Kerberos fails before encryption negotiation even starts. Sync with the DC using w32tm /resync.

One last thing: if you're on Server 2022 and still getting this, it's almost certainly a broken krbtgt. Run the password reset again and give it a full 30 minutes for replication. Patience beats panic.