Kerberos encryption types and keys

An encryption type and an attribute mask use different numbers

The wire protocol identifies an individual algorithm with an etype number. The AD attribute msDS-SupportedEncryptionTypes holds a bitmask of capabilities. The same number means different things in those two fields.

AD mask 0x18 means AES128 plus AES256; event etype 0x18 identifies a different, obsolete algorithm. Decimal attribute value 18 is mask 0x12, not “AES256 only.” Check which field you’re reading. IANA’s etype registry assigns the protocol numbers. The KILE capability flags also include features beyond the five legacy algorithm bits, including a flag for AES session keys with legacy ticket encryption. Keep those flags intact when changing the attribute.

AES-SHA2 introduces wire etypes 19 and 20, defined by RFC 8009. Microsoft’s product behavior notes identify support in Windows 11 24H2 and Windows Server 2025 and later, disabled by default. An AES-SHA1 ticket is not proof that the newer suite was attempted and rejected.

Identify which key is being selected

There are several decisions in one authentication:

The client does not decrypt the enclosed TGT or service ticket. It uses the reply’s other encrypted part to obtain the corresponding session key. A client can therefore carry a ticket encrypted with an algorithm different from the session key it uses. Microsoft’s encryption-selection explanation describes this distinction. Restricting an ordinary user’s account attribute is not a substitute for configuring the requesting device and service correctly.

For a TGS failure, first identify the account owning the exact SPN. Changing the user’s password cannot install a missing key in a separate web service’s keytab. A referral ticket also involves the trust relationship’s keys and capabilities; it is not simply another ticket encrypted with the destination server’s password.

Read declaration, policy, and key material separately

This reads a known user service account from a specified DC:

$svc = Get-ADUser -Identity svc-web -Server dc1.contoso.com `
    -Properties ServicePrincipalNames, msDS-SupportedEncryptionTypes,
        PasswordLastSet, msDS-KeyVersionNumber
$svc | Select-Object SamAccountName, ServicePrincipalNames,
    msDS-SupportedEncryptionTypes, PasswordLastSet, msDS-KeyVersionNumber
if ($null -eq $svc.'msDS-SupportedEncryptionTypes') {
    'Attribute is absent; investigate the KDC fallback'
} else {
    'Explicit attribute value: 0x{0:X}' -f [uint32]$svc.'msDS-SupportedEncryptionTypes'
}

For computer or managed service accounts, use the corresponding AD cmdlet. Repeat against the failing KDC when replication state is relevant. Do not convert a missing value to zero in an inventory and thereby lose the distinction between an absent attribute and a stored value.

The attribute declares capabilities; it doesn’t expose or create the account’s secret keys. The device’s Network security: Configure encryption types allowed for Kerberos policy constrains a different part of the exchange. The KDC’s DefaultDomainSupportedEncTypes supplies fallback behavior for relevant accounts without explicit configuration. Check all three. One registry number won’t describe “the domain’s encryption type.”

Read the following locally on the KDC being investigated; this is a configuration query:

reg query HKLM\SYSTEM\CurrentControlSet\Services\Kdc /v DefaultDomainSupportedEncTypes

A missing registry value means the built-in default applies. The KDC registry reference documents the location and the April 2026 change. An explicitly configured fallback must be evaluated separately.

The 2026 RC4 changes alter the fallback

For DCs receiving the applicable updates, January 2026 introduced audit events; April 14, 2026 changed the fallback to AES-SHA1 mask 0x18; July 2026 updates removed support for the temporary RC4DefaultDisablementPhase rollback control.

The change concerns service-ticket issuance when the service has no explicit encryption configuration. Explicit DefaultDomainSupportedEncTypes settings retain their documented effect, and explicit account RC4 configuration still matters. RC4 hasn’t disappeared from every path. Use KB5073381’s deployment and event guidance for the installed patch level; the old temporary rollback value is no longer a repair option.

The System log’s Kdcsvc events 201–209 describe different client, service-key, and policy dependencies. Collect the complete event, not just its ID. Absence of these events does not establish that a non-Windows service can accept the AES ticket its directory account permits. A stale or incomplete keytab can fail after successful issuance.

Use the updated event fields

On updated Windows Server 2016 and later DCs, 4769 version 2 supplies ticket and session encryption, advertised types, and key-availability fields. Read named XML fields rather than positional indexes:

Get-WinEvent -ComputerName dc1.contoso.com -FilterHashtable @{
    LogName = 'Security'; Id = 4769; StartTime = (Get-Date).AddMinutes(-15)
} | ForEach-Object {
    $event = $_
    $data = @{}
    ([xml]$event.ToXml()).Event.EventData.Data | ForEach-Object {
        $data[$_.Name] = $_.'#text'
    }
    [pscustomobject]@{
        TimeUtc = $event.TimeCreated.ToUniversalTime()
        DC = $event.MachineName
        RecordId = $event.RecordId
        User = $data.TargetUserName
        Service = $data.ServiceName
        Status = $data.Status
        TicketEtype = $data.TicketEncryptionType
        SessionEtype = $data.SessionKeyEncryptionType
        ClientTypes = $data.ClientAdvertizedEncryptionTypes
        ServiceTypes = $data.ServiceSupportedEncryptionTypes
        ServiceKeys = $data.ServiceAvailableKeys
    }
}

Missing fields can mean an older event version or unavailable lookup information. “Available keys includes RC4” does not mean RC4 was selected. The supported-types event fields are processed values and can differ from the raw AD attribute, particularly across DC versions. Compare raw directory data and the selected etypes; Microsoft’s RC4 detection guidance explains these field distinctions.

Choose a fix that addresses the failed stage

For a keytab-backed service, compare the ticket’s KVNO and principal with the installed keytab using that Kerberos implementation’s inspection tool. Do not display key bytes. Password rotation or keytab generation is an operational change: coordinate every service instance using the account, the generated principal and salt, accepted algorithms, replication, and service credential reload. A successful password reset in AD can leave every acceptor holding the previous key.

Keep the original results, then retry the application from the correct logon session. See SPN and acceptor identity checks and the exchange-based troubleshooting sequence.