KDC_ERR_ETYPE_NOTSUPP: Diagnosing Kerberos Encryption Type Mismatches After AD Hardening

Anatomy of a Kerberos Encryption Outage

It is 02:00 AM on a Sunday morning. The security engineering team has just linked a new domain baseline Group Policy Object across all Organisational Units, disabling legacy RC4-HMAC encryption to satisfy an upcoming compliance audit. By 06:30 AM, as the first regional manufacturing shifts log on, the escalation bridge detonates. Critical line-of-business applications fail to connect to back-end SQL Server databases with cryptic SSPI handshake errors, internal web applications display blank HTTP 500 error pages, and network file shares reject connections with access denied errors.

When you log into the primary domain controller to inspect the security log, you find thousands of instances of Security Event IDs 4768 and 4769 reporting failure code 0xe. Concurrently, the System event log is inundated with Event ID 14 warnings from the Kerberos-Key-Distribution-Center source: “While processing an AS request for target service krbtgt, the account did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1).”

Think of Kerberos encryption negotiation like an international currency exchange counter. You walk up to the exchange kiosk holding only British Pounds, asking for Japanese Yen. The teller behind the counter, however, has just implemented a strict policy stating that they only conduct transactions using Euros and US Dollars. Even though both you and the bank possess valid funds, the transaction cannot proceed because there is no common, mutually accepted currency between your request, the teller’s policy, and the vault’s inventory. The teller throws up their hands and turns you away.

In Active Directory, the Key Distribution Center (KDC) acts as that currency exchange teller. Whenever a client requests a Ticket Granting Ticket (TGT via AS-REQ) or a Service Ticket (TGS-REQ), it submits an ordered list of encryption algorithms it can process. The KDC compares this list against its own local security policies and the cryptographic keys stored on the target account object inside the Active Directory database (ntds.dit). If the overlapping set of supported algorithms is empty, the KDC halts negotiation immediately and returns KDC_ERR_ETYPE_NOTSUPP (RFC 4120 error code 14).

What the Error Looks Like: Telemetry & Event Artifacts

Because Kerberos authentication underpins nearly every transaction in an Active Directory forest, an encryption mismatch manifests across multiple tiers: client command-line utilities, workstation application event logs, and domain controller diagnostic telemetry.

1. Client-Side Symptoms & Command-Line Diagnostics

On a client machine or application server attempting to communicate with a target service, the failure frequently masquerades as a generic network or security failure:

• SQL Server: Cannot generate SSPI context. (Microsoft SQL Server, Error: -2146893042)
• SMB File Shares: The encryption type specified is not supported. (0xc00002fe / STATUS_KDC_UNKNOWN_ETYPE)
• PowerShell Remoting / WinRM: WinRM cannot process the request. The encryption type specified is not supported.
• Web Services (IIS): HTTP Error 401.1 or HTTP Error 500 when negotiating Kerberos tickets via Negotiate/SPNEGO.

When you attempt to request a service ticket manually on a client using klist.exe, the exact error code is returned:

Request a targeted service ticket from the command prompt to isolate the failure:

# Query a targeted service ticket for an application SPN
klist.exe get MSSQLSvc/sql01.corp.example.com:1433

klist : Retrieve ticket for MSSQLSvc/sql01.corp.example.com:1433 failed with error 0x80090342 (KDC_ERR_ETYPE_NOTSUPP).
The encryption type specified is not supported.

2. Domain Controller Security Event IDs 4768 and 4769

In the Security event log on domain controllers, the KDC logs an explicit failure audit event whenever a ticket request is rejected due to unsupported encryption.

When a user or machine account fails to obtain a Ticket Granting Ticket (TGT), the DC logs Event ID 4768:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Event ID:      4768
Task Category: Kerberos Authentication Service
Level:         Information
Keywords:      Audit Failure
Description:
A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:        app_service
    Supplied Realm Name: CORP.EXAMPLE.COM
    User ID:             CORP\app_service

Service Information:
    Service Name:        krbtgt/CORP.EXAMPLE.COM
    Service ID:          CORP\krbtgt

Network Information:
    Client Address:      ::ffff:10.10.20.45
    Client Port:         51892

Additional Information:
    Ticket Options:      0x40810010
    Result Code:         0xe
    Ticket Encryption:   0x0
    Pre-Auth Type:       -

When a client already holds a valid TGT but fails to obtain a Service Ticket for a back-end application Service Principal Name (SPN), the DC logs Event ID 4769:

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Event ID:      4769
Task Category: Kerberos Service Ticket Operations
Level:         Information
Keywords:      Audit Failure
Description:
A Kerberos service ticket was requested.

Account Information:
    Account Name:        jdoe@CORP.EXAMPLE.COM
    Account Domain:      CORP.EXAMPLE.COM
    Logon GUID:          {8b4d9a12-5f6e-41a2-9d3c-1b7e4f8a2091}

Service Information:
    Service Name:        MSSQLSvc/sql01.corp.example.com:1433
    Service ID:          CORP\svc_sqlapp

Network Information:
    Client Address:      ::ffff:10.10.10.105
    Client Port:         58412

Additional Information:
    Ticket Options:      0x40810000
    Ticket Encryption:   0xffffffff
    Failure Code:        0xe
    Transited Services:  -

3. KDC System Event IDs 14 and 16

While the Security log provides the transaction metadata, the System event log on the domain controller identifies the root cause through diagnostic events logged by the Microsoft-Windows-Kerberos-Key-Distribution-Center provider.

Event ID 14 is logged during initial authentication (AS-REQ), while Event ID 16 is logged during service ticket generation (TGS-REQ). These events explicitly display the algorithm mismatch:

Log Name:      System
Source:        Microsoft-Windows-Kerberos-Key-Distribution-Center
Event ID:      14
Level:         Warning
Description:
While processing an AS request for target service krbtgt, the account app_service did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes : 18 17. The accounts available etypes : 23.

Look closely at the numbers in the event description:

• Requested etypes (18, 17): The client requested AES-256 (etype 18) and AES-128 (etype 17).
• Accounts available etypes (23): The target account object in Active Directory only possesses an RC4-HMAC key (etype 23).

Because the intersection between {18, 17} and {23} is empty, the KDC cannot proceed.

What It Actually Means: Encryption Type Negotiation Decoded

To permanently resolve this failure across enterprise environments, administrators must understand how Windows systems negotiate encryption algorithms and how Active Directory stores cryptographic keys.

1. Kerberos Encryption Algorithms & RFC Numbers

Kerberos uses standardized integer identifiers defined in RFC 3961 and RFC 4120. Modern enterprise infrastructure involves three primary algorithm families:

2. The Negotiation Message Flow

During standard Kerberos authentication, encryption algorithm selection occurs dynamically between the client, the KDC, and the target service principal:

[Client Workstation] ─── (1) AS-REQ [Etypes: 18, 17] ─────────────────▶ [Domain Controller / KDC]
[Client Workstation] ◀── (2) Error: KDC_ERR_ETYPE_NOTSUPP (0xe) ─────── [Target Account has only Etype 23]

[Client Workstation] ─── (3) TGS-REQ [Target: MSSQLSvc, Etypes: 18, 17] ▶ [Domain Controller / KDC]
[Client Workstation] ◀── (4) Error: KDC_ERR_ETYPE_NOTSUPP (0xe) ─────── [SPN Object lacks Etypes 18, 17]

When the client requests a ticket, it passes an array of encryption types supported by its local security provider (LSASS) and permitted by local Group Policy. The KDC inspects the target account object (the user account for AS-REQ, or the service account linked to the SPN for TGS-REQ).

3. The msDS-SupportedEncryptionTypes Bitmask

Active Directory tracks an account’s cryptographic capabilities using the msDS-SupportedEncryptionTypes attribute. This attribute is stored as an integer bitmask on user, computer, and service account objects:

4. The Password Derivation Trap: Why the Checkbox Alone Fails

Here is the single most common reason administrators get burned during Kerberos hardening:

When you create an account in Active Directory or set its password, the Domain Controller computes cryptographic hashes of the cleartext password using various hashing algorithms:

• For NTLM and RC4-HMAC, it computes the MD4 hash of the UTF-16 password.
• For AES-128 and AES-256, it derives the key using PBKDF2 (HMAC-SHA1) with a specific Kerberos salt (composed of the domain realm and user principal name) running through 4,096 iterations.

If an account was created years ago in an older forest, or if its password was provisioned using legacy administrative scripts, the AES cryptographic keys do not exist in the ntds.dit database.

Opening Active Directory Users and Computers (ADUC) and checking the boxes for “This account supports Kerberos AES 128 bit encryption” and “This account supports Kerberos AES 256 bit encryption” merely updates the msDS-SupportedEncryptionTypes attribute metadata. It does not generate the cryptographic keys. The KDC reads the attribute, sees that AES is advertised, attempts to locate the AES keys inside the directory record to encrypt the ticket, finds them missing, and aborts with Event ID 14 or 16: “the account did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1).”

5. KB5021131 & DefaultDomainSupportedEncTypes

In response to CVE-2022-37966, Microsoft released security updates (KB5021131) altering how domain controllers handle encryption for accounts where msDS-SupportedEncryptionTypes is not explicitly set (which includes standard user accounts by default).

To govern fallback behaviour, Microsoft introduced the following registry value on domain controllers:

• Path: HKLM\System\CurrentControlSet\services\KDC
• Value: DefaultDomainSupportedEncTypes (REG_DWORD)

If this value is left at the initial update baseline (0x27, which includes DES, RC4, and AES Session Keys but omits standard AES ticket encryption), or if client workstations enforce strict AES-only policies via GPO, the KDC drops fallback requests, generating unexpected KDC_ERR_ETYPE_NOTSUPP events across the domain.

How to Diagnose: Step-by-Step Diagnostic Spine

When KDC_ERR_ETYPE_NOTSUPP strikes, follow this systematic diagnostic progression from the local client to the domain controller directory attributes.

Step 1: Inspect Client Ticket Cache & Isolate Target SPN

Begin on the client experiencing authentication failures. Determine whether the client holds a valid TGT and what encryption types are being negotiated for cached tickets:

Execute klist.exe to view currently cached Kerberos tickets and their encryption algorithms:

# Inspect all cached Kerberos tickets on the local client
klist.exe tickets

#0> Client: jdoe @ CORP.EXAMPLE.COM
    Server: krbtgt/CORP.EXAMPLE.COM @ CORP.EXAMPLE.COM
    KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
    Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
    Start Time: 10/27/2026 08:14:02 (local)
    End Time:   10/27/2026 18:14:02 (local)

#1> Client: jdoe @ CORP.EXAMPLE.COM
    Server: cifs/fileserver01.corp.example.com @ CORP.EXAMPLE.COM
    KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
    Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
    Start Time: 10/27/2026 08:15:10 (local)
    End Time:   10/27/2026 18:14:02 (local)

In the output above, ticket #0 (the TGT) negotiated AES-256, while ticket #1 (file share access) fell back to legacy RC4-HMAC. If a domain policy subsequently disables RC4, any renewal or new ticket request for fileserver01 will fail immediately.

Purge the local ticket cache and request an explicit service ticket to test the failure directly:

# Purge existing tickets from memory
klist.exe purge

# Trigger a targeted request for the failing service principal name
klist.exe get MSSQLSvc/sql01.corp.example.com:1433

Step 2: Verify Network Ports & Firewall Reachability

Before modifying directory attributes or registry keys, ensure that network transport is not dropping Kerberos packets. While standard Kerberos authentication uses UDP port 88, ticket requests involving large Kerberos tokens (such as users belonging to hundreds of security groups, or AES-encrypted PAC structures) exceed the standard 1,472-byte MTU and must fall back to TCP port 88.

Run PowerShell network tests against your domain controllers to verify all mandatory authentication ports:

# Test Kerberos TCP port 88 reachability to domain controllers
Test-NetConnection -ComputerName dc01.corp.example.com -Port 88

# Test LDAP TCP port 389 reachability for attribute queries
Test-NetConnection -ComputerName dc01.corp.example.com -Port 389

# Test SMB TCP port 445 reachability for policy retrieval
Test-NetConnection -ComputerName dc01.corp.example.com -Port 445

ComputerName     : dc01.corp.example.com
RemoteAddress    : 10.10.10.10
RemotePort       : 88
InterfaceAlias   : Production-VLAN
SourceAddress    : 10.10.20.45
TcpTestSucceeded : True

Step 3: Interrogate Domain Controller Security & System Event Logs

Connect to your domain controllers using PowerShell Remoting or an administrative console to interrogate recent Kerberos failure audits:

Query the Security log for Event IDs 4768 and 4769 reporting error code 0xe:

# Query recent Kerberos ticket failures reporting error code 0xe
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id      = 4768, 4769
} -MaxEvents 50 | Where-Object {
    $_.Message -match '0xe'
} | Select-Object TimeCreated, Id, @{Name='Target';Expression={$_.Properties[1].Value}}, Message

Query the System log for KDC Event IDs 14 and 16 to identify missing key IDs and algorithm sets:

# Query KDC warning events detailing missing encryption keys
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
    Id           = 14, 16
} -MaxEvents 20 | Select-Object TimeCreated, Id, Message | Format-List

Step 4: Audit Account msDS-SupportedEncryptionTypes & Password Age

Identify the service account or computer account hosting the target SPN that failed in Step 1. Inspect its configured encryption bitmask and determine when its password was last changed:

Interrogate the target service account attributes using the Active Directory module:

# Interrogate service account encryption metadata and password timestamp
Get-ADUser -Identity "svc_sqlapp" -Properties "msDS-SupportedEncryptionTypes", PasswordLastSet, ServicePrincipalNames | Select-Object Name, "msDS-SupportedEncryptionTypes", PasswordLastSet, @{Name='SPNs';Expression={$_.ServicePrincipalNames -join '; '}}

Name                          : svc_sqlapp
msDS-SupportedEncryptionTypes : 4
PasswordLastSet               : 11/14/2018 3:22:15 PM
SPNs                          : MSSQLSvc/sql01.corp.example.com:1433; MSSQLSvc/sql01.corp.example.com

Notice two critical issues in this output:

1. msDS-SupportedEncryptionTypes is set to 4 (which represents RC4-HMAC only).
2. PasswordLastSet is dated 2018. Even if the bitmask is updated to allow AES, the account possesses no AES keys in Active Directory until the password is changed.

Step 5: Audit Domain Controller KDC Registry Settings & GPOs

Check whether the domain controllers or member servers have local registry overrides restricting encryption types:

Query the domain controller KDC fallback registry key:

# Check the KDC fallback encryption configuration on the Domain Controller
reg.exe query "HKLM\System\CurrentControlSet\services\KDC" /v DefaultDomainSupportedEncTypes

HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC
    DefaultDomainSupportedEncTypes    REG_DWORD    0x27

Query the Kerberos client security policy on workstations or member servers:

# Check client-enforced Kerberos encryption policy
reg.exe query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" /v SupportedEncryptionTypes

If the client registry returns 0x18 (only AES128 and AES256 allowed) while the DC fallback is 0x27 (DES and RC4 allowed, but AES ticket encryption omitted), accounts with blank msDS-SupportedEncryptionTypes will trigger KDC_ERR_ETYPE_NOTSUPP.

Common Failure Scenarios: Root Cause & Fix

Use this reference matrix to isolate the exact cause of KDC_ERR_ETYPE_NOTSUPP and apply the verified remediation.

The Fix: Step-by-Step Remediation Playbook

Follow these procedures to eliminate KDC_ERR_ETYPE_NOTSUPP errors and safely harden your Active Directory forest against legacy ciphers.

1. Update Service Accounts & Force Cryptographic Key Derivation

When a service account or user account with an SPN is triggering Event ID 14 or 16, execute this two-step remediation: update the attribute bitmask, then perform a password reset.

Update the account’s msDS-SupportedEncryptionTypes attribute to enable AES128 (0x8) and AES256 (0x10). Setting the decimal value to 24 (0x18) restricts the account strictly to AES. Setting the value to 28 (0x1C) enables AES while retaining RC4 fallback during transitional migration phases:

# Enable AES128, AES256, and RC4 fallback on a critical service account
Set-ADUser -Identity "svc_sqlapp" -Replace @{'msDS-SupportedEncryptionTypes' = 28}

Next, perform an immediate password reset on the account. This forces Active Directory to hash the password through PBKDF2 and populate the AES-128 and AES-256 keys inside ntds.dit:

# Reset the service account password to generate AES cryptographic keys
Reset-ADAccountPassword -Identity "svc_sqlapp" -ResetPasswordOnNextLogon $false

2. Harmonize Domain Controller KDC Registry Fallback

To ensure domain controllers handle accounts with blank msDS-SupportedEncryptionTypes attributes predictably following KB5021131, explicitly define the DefaultDomainSupportedEncTypes registry key on all domain controllers.

Configure the value to 0x3C (decimal 60). This configuration permits AES-256, AES-128, AES Session Keys, and RC4-HMAC, while permanently blocking obsolete DES ciphers:

Configure the KDC registry value across all domain controllers:

# Set KDC default supported encryption types to 0x3C (AES128, AES256, RC4, AES Session Keys)
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\services\KDC" -Name "DefaultDomainSupportedEncTypes" -Value 60 -Type DWord

Verify that the registry value was written correctly:

# Confirm the KDC registry setting
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\services\KDC" -Name "DefaultDomainSupportedEncTypes" | Select-Object DefaultDomainSupportedEncTypes

DefaultDomainSupportedEncTypes
------------------------------
                            60

3. Rebuild Linux & Appliance Keytabs with AES256

Non-Windows systems (such as Linux servers using SSSD, MIT Kerberos, Apache, or appliance storage arrays) frequently hold keytab files generated years ago using -crypto RC4-HMAC-NT. When Windows clients attempt to connect using AES, authentication fails.

Regenerate the keytab on a Windows administrative management workstation using ktpass.exe, explicitly enforcing -crypto AES256-SHA1:

# Generate an enterprise AES256 keytab for a web service principal
ktpass.exe -princ HTTP/app01.corp.example.com@CORP.EXAMPLE.COM -mapuser app01_svc -pass "SecureP@ssw0rd2026" -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -out C:\Keytabs\app01.keytab

Targeting domain controller: dc01.corp.example.com
Using specified password.
Key created.
Output keytab to C:\Keytabs\app01.keytab:
Keytab version: 0x502
keysize 78 HTTP/app01.corp.example.com@CORP.EXAMPLE.COM ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-CTS-HMAC-SHA1-96) keylength 32
Account app01_svc has been set for HTTP/app01.corp.example.com

Securely copy the generated keytab to the Linux host (e.g., via SCP) and verify its cryptographic contents using klist on the Linux terminal:

# Verify encryption types present inside the Linux keytab
klist -k -e /etc/krb5.keytab

Keytab name: FILE:/etc/krb5.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   3 HTTP/app01.corp.example.com@CORP.EXAMPLE.COM (aes256-cts-hmac-sha1-96)

4. Upgrade Cross-Forest Trust Encryption Capabilities

If Kerberos failures occur when users in Forest A access resources in Forest B, the Trusted Domain Object (TDO) representing the inter-forest trust may be restricted to legacy RC4 encryption.

Inspect and update the trust encryption capabilities using the Active Directory module:

# Check current Kerberos encryption types configured on the domain trust
Get-ADDomainTrust -Identity "partner.example.com" | Select-Object Name, IntraForest, Target, UsesAESKeys

Enable AES-128 and AES-256 encryption across the inter-forest trust boundary:

# Enable AES encryption on the cross-forest trust object
Set-ADDomainTrust -Identity "partner.example.com" -KerberosEncryptionType AES128,AES256

How to Prevent It: Proactive Auditing & Pester Validation

Preventing KDC_ERR_ETYPE_NOTSUPP requires continuous discovery before policy enforcement. Never disable RC4 domain-wide without first auditing which accounts and services still actively negotiate legacy ciphers.

1. Discovery Mode Auditing via Event ID 4769

Before modifying the Group Policy setting “Network security: Configure encryption types allowed for Kerberos”, monitor Domain Controller Security Event ID 4769 over a 30-day baseline period. Filter specifically for successful service ticket requests where Ticket Encryption Type is 0x17 (decimal 23, RC4-HMAC):

Identify all active production services currently relying on RC4 tickets:

# Identify all accounts requesting RC4-encrypted service tickets
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id      = 4769
} -MaxEvents 5000 | Where-Object {
    $_.Properties[4].Value -eq '0x17'
} | Select-Object @{Name='Service';Expression={$_.Properties[0].Value}}, @{Name='Account';Expression={$_.Properties[1].Value}} -Unique

Any account appearing in this report will break immediately if RC4 is disabled. Work through this list to enable AES and reset passwords prior to GPO enforcement.

2. Automated Prevention Test: Pester CI Validation

Incorporate this production-ready Pester 5 synthetic test into your directory maintenance pipeline or daily health checks. It identifies any active account with an SPN that is either restricted to RC4 or has never cycled its password:

# Pester 5 test to validate Kerberos encryption readiness on accounts with SPNs
Describe "Active Directory Kerberos Encryption Readiness" {
    It "Should ensure all active accounts with SPNs support AES encryption" {
        $legacyAccounts = Get-ADObject -Filter 'servicePrincipalName -like "*"' -Properties "msDS-SupportedEncryptionTypes", PasswordLastSet, servicePrincipalName |
            Where-Object {
                $_.ObjectClass -in @('user', 'computer') -and
                ($_.('msDS-SupportedEncryptionTypes') -band 0x18) -ne 0x18
            }
        $legacyAccounts.Count | Should -Be 0 -Because "All SPN accounts must support AES128 and AES256"
    }
}

Executing this test as part of synthetic monitoring guarantees that newly provisioned service accounts cannot enter production without proper AES encryption capabilities, stopping KDC_ERR_ETYPE_NOTSUPP before it affects end users.

Final Thoughts

Modernising Active Directory cryptography is an indispensable requirement for enterprise security. Legacy ciphers such as RC4-HMAC are fundamentally insecure, leaving environments vulnerable to offline ticket cracking, Kerberoasting attacks, and credential manipulation. However, cryptographic transitions cannot be accomplished by flipping a single Group Policy switch.

When you encounter KDC_ERR_ETYPE_NOTSUPP, resist the temptation to blindly re-enable RC4 domain-wide. Treat the failure code as a precise roadmap: identify the affected principal from DC Security Event 4769, check the KDC System event log for algorithm disparity, update the account’s msDS-SupportedEncryptionTypes attribute, and reset the password to derive the requisite AES keys. By systematically executing these steps, you eliminate authentication outages while maintaining a secure, modern Kerberos infrastructure.