msDS-SupportedEncryptionTypes Left Unset Lets Kerberos Silently Issue RC4 Tickets

Symptom

A domain administrator confirms that the “Network security: Configure encryption types allowed for Kerberos” policy enforces AES-only Kerberos tickets, yet a captured service ticket for a specific service account still shows RC4-HMAC(NT) as the negotiated encryption type.

The GPO reports as applied, domain controllers run a supported build, and DES/RC4 have been disabled in the domain-wide setting. Despite this, klist output for one or more service accounts continues to show RC4 tickets being issued on demand, and the behaviour persists across multiple ticket renewals.

False Assumption

The working assumption is that a domain-level Kerberos encryption-types Group Policy setting is authoritative for every account in the domain, because it is applied at the domain or OU level and Windows computers show it as successfully processed.

In practice, that GPO setting writes the msDS-SupportedEncryptionTypes attribute only on the computer and user objects that actually process the relevant security client-side extension during their own policy refresh. Service accounts used by non-Windows systems, some legacy application accounts, and accounts provisioned before the policy existed can go through many refresh cycles on other machines without their own attribute ever being touched.

Root Cause

The root cause is an unset or stale msDS-SupportedEncryptionTypes attribute on the affected account, which the Key Distribution Centre evaluates independently of any domain-level GPO.

msDS-SupportedEncryptionTypes is a per-principal attribute that tells the KDC which encryption types that specific account supports for Kerberos ticket issuance. The domain-wide GPO changes what a Windows computer or interactively logged-on user will accept, but it does not retroactively populate this attribute on every account in the directory. Where the attribute is absent or zero, the KDC falls back to legacy default behaviour that continues to include RC4 for that account, independent of what the domain-level policy display suggests.

Visible assumption: this trap assumes a domain functional level that supports msDS-SupportedEncryptionTypes and a lifecycle where the AES-enforcement GPO was introduced after many accounts already existed, which is common in mature estates. Environments should confirm this per account rather than assume it, since security filtering, cross-forest trust usage or exclusion from GPO scope can produce the same gap even in newer deployments.

Impact

The practical impact is that specific accounts keep receiving RC4-encrypted Kerberos tickets even though the organisation believes RC4 has been eliminated domain-wide.

RC4-HMAC(NT) tickets are encrypted using a key derived from the account’s NTLM password hash, making a captured ticket a target for offline password-cracking attempts. Accounts most likely to be affected are older service accounts, accounts used by non-Windows middleware, and any account excluded from GPO application by security filtering or loopback processing. Until the attribute is confirmed per account, any inventory claiming “AES-enforced” status domain-wide is unverified.

Diagnosis

Diagnosis relies on reading the msDS-SupportedEncryptionTypes attribute directly and correlating it with observed ticket encryption types, rather than trusting GPO application reports.

Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
  Where-Object { -not $_.'msDS-SupportedEncryptionTypes' } |
  Select-Object SamAccountName

This enumerates every user account where the attribute is unset. Run the equivalent query against service and computer accounts used by non-Windows systems, since those are most likely to be missed by GPO-based enforcement.

klist tickets

Capture a fresh ticket for the affected account, for example by restarting the dependent service, and inspect the KerbTicket Encryption Type field. RC4-HMAC(NT) alongside an unset attribute confirms the trap; AES256-CTS-HMAC-SHA1-96 with the attribute correctly populated indicates the account is not affected.

Correction

The correction is to set an explicit, account-specific msDS-SupportedEncryptionTypes value only after confirming every system authenticating as that account can negotiate AES.

Do not apply this change domain-wide in a single operation. Change one account, validate authentication across a full operational cycle, then proceed to the next. A decimal value of 24 represents AES128_CTS_HMAC_SHA1_96 and AES256_CTS_HMAC_SHA1_96 combined, with RC4 and DES excluded.

Set-ADUser -Identity <sam_account_name> -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 }

Record the account’s current value before running this command so the change can be reversed if any consuming system fails to authenticate.

Validation

Validation confirms that the target account now negotiates AES tickets exclusively and continues to authenticate successfully across a full operational cycle.

• Force a fresh authentication for the account and capture the ticket with klist tickets; confirm the encryption type shows AES128 or AES256 and no RC4-HMAC(NT) entries remain.
• Re-run the enumeration query to confirm msDS-SupportedEncryptionTypes now returns 24 for the account.
• Review Domain Controller Security event log entries 4768 and 4769 for the account for at least 24 hours; confirm no KDC_ERR_ETYPE_NOTSUPP failures are logged.

Rollback

Rollback restores the account’s prior encryption-types value immediately if any authentication failure appears after the change.

Stop the rollout the moment a single authentication failure is observed for the changed account; do not proceed to additional accounts until the cause is understood.

Set-ADUser -Identity <sam_account_name> -Replace @{ 'msDS-SupportedEncryptionTypes' = <recorded_previous_value> }

If the attribute was previously unset rather than holding an explicit integer, clear it instead of writing zero:

Set-ADUser -Identity <sam_account_name> -Clear msDS-SupportedEncryptionTypes

Confirm rollback by repeating the ticket capture and verifying the account resumes authenticating with its prior encryption type before investigating the incompatible system separately.

Prevention

Prevent recurrence by treating msDS-SupportedEncryptionTypes as an attribute that must be verified per account, not assumed from GPO reporting.

Convert the enumeration query in the Diagnosis section into a recurring, read-only audit rather than a one-time check, since new service accounts created after the domain-wide GPO was set will not automatically inherit an explicit value. Extend the audit to computer accounts belonging to non-Windows or appliance systems, which frequently sit outside standard GPO processing. Document the confirmed AES-only account list as evidence and re-run the audit whenever a new service account is provisioned or migrated between systems.