0X80090342

Fixing SEC_E_KDC_UNKNOWN_ETYPE (0x80090342) in Kerberos auth

Cybersecurity & Malware Intermediate 👁 0 views 📅 May 26, 2026

This Kerberos error means the KDC doesn't support the encryption type your client requested. It's almost always a crypto policy mismatch on the domain controller or client.

When this error hits

You're trying to authenticate to a domain resource — could be a SQL Server, a file share, or even a Windows Admin Center connection — and you get slapped with SEC_E_KDC_UNKNOWN_ETYPE (0x80090342). The full message reads "The encryption type requested is not supported by the KDC". This usually happens right after you've upgraded a domain controller from Server 2012 R2 to Server 2019 or 2022, or after you've tightened the Kerberos encryption policy via Group Policy. Another common trigger: you're running an older app that still tries to use RC4-HMAC, but the KDC now only advertises AES128 or AES256.

Root cause

Kerberos authentication negotiates an encryption type between the client and the Key Distribution Center (KDC). The KDC lists supported types in its msDS-SupportedEncryptionTypes attribute. The client requests one it can handle — if that type isn't in the KDC's list, you get 0x80090342. The real fix isn't guessing — it's checking what both sides actually support.

Fix it in 4 steps

  1. Check the KDC's supported encryption types — On a domain controller, open PowerShell as admin and run:
    Get-ADDomainController -Filter * | ForEach-Object {
      Get-ADObject $_.DistinguishedName -Properties msDS-SupportedEncryptionTypes
    }

    The output value is a bitmask. Decode it: 1 = RC4-HMAC, 2 = AES128-CTS-HMAC-SHA1-96, 4 = AES256-CTS-HMAC-SHA1-96, 8 = Future AES types. Default for Server 2016+ is 28 (RC4+AES128+AES256). If you see 24 (AES only) or 4 (AES256 only), that's your smoking gun.

  2. Update the KDC's encryption types — If you need RC4 back (because some legacy app cries for it), set the bitmask to 28. Run:
    Set-ADObject -Identity (Get-ADDomainController -Identity "YOUR-DC-NAME").DistinguishedName -Replace @{
      "msDS-SupportedEncryptionTypes" = 28
    }

    Replace YOUR-DC-NAME with the actual DC's hostname. No reboot needed — this takes effect on the next Kerberos request.

  3. Fix the client side — If the client is a Windows 10/11 machine that's been hardened to only use AES, but the KDC dropped AES (rare but possible if someone botched the policy), you need to allow the client to negotiate the right type. On the client machine, check the registry at:
    HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters

    Look for SupportedEncryptionTypes (DWORD). Set it to 0x7FFFFFFF to allow all types, or 0x1C (28) for RC4+AES128+AES256. This is a machine-wide setting — reboot after changing.

  4. Force re-auth — After the fix, clear cached Kerberos tickets on the client with:
    klist purge

    Then try the failing operation again. The client will re-negotiate with the updated encryption types.

Still failing? Check these

  • Check Group Policy — There's a policy called "Network security: Configure encryption types allowed for Kerberos" under Computer Config > Windows Settings > Security Settings > Local Policies > Security Options. If it's enabled and only AES is checked, RC4 won't work, even if the KDC's attribute says otherwise. Policy overrides the attribute.
  • Verify the client's OS version — Windows 7 and Server 2008 R2 don't support AES128/256 by default without a hotfix (KB2626953). If you're still running those, you're stuck with RC4 — and if the KDC dropped RC4, you're dead in the water. Upgrade or patch the client.
  • Use Network Monitor or Wireshark — Filter for kerberos and look at the ETYPE-INFO2 in the KRB-ERROR packet. It'll tell you exactly what encryption types the KDC is offering. Cross-check that against what your client requested in the AS-REQ.
  • Check time sync — This error can also show up if clocks are skewed (though 0x80090342 specifically points to encryption type mismatch). Run w32tm /query /status on the client and compare to the DC. If off by more than 5 minutes, Kerberos fails with a different error — but sometimes the error messages blur together.

The bottom line: 0x80090342 is always about a negotiation mismatch. Don't go reinstalling the KDC or resetting domain trusts — just check the encryption type lists on both sides and make them overlap.

Was this solution helpful?