Kerberos encryption: moving off RC4 to AES without breaking services

Why RC4 is a problem

With RC4-HMAC, an account's Kerberos key is derived directly from its NT hash, with no salt and no iterations. A service ticket encrypted with RC4 is therefore much faster to attack offline than an AES one: this is the main lever behind Kerberoasting. Moreover, knowing an account's NT hash is enough to produce valid RC4 tickets for it. Finally, RC4 has long been considered a weak algorithm. Microsoft has started deprecating RC4 in Kerberos and has announced changes to default behaviour on domain controllers; the exact timeline and details should be checked in current Microsoft documentation, as they have evolved across announcements.

How the encryption type is chosen

The domain controller picks the encryption for a service ticket based on what the target account declares it supports, through the msDS-SupportedEncryptionTypes attribute, what the client offers and what policy allows. The attribute is a bitmask:

Computers populate this attribute themselves. User accounts used as service accounts, however, often leave it empty, and default behaviour then depends on the controllers' update level and the DefaultDomainSupportedEncTypes setting. Explicitly setting the attribute to AES only (0x18) on these accounts is clearer and safer.

The old password trap

An account's AES keys are only generated when its password is changed while the domain is at Windows Server 2008 functional level or higher. A service account whose password has not changed since the days of an older domain therefore has no AES key at all: forcing AES on it would cause authentication failures. Identify these accounts by comparing pwdLastSet with the date the functional level was raised, and schedule a password change before any hardening. Ideally, replace them with group Managed Service Accounts (gMSA), whose passwords are long, random and rotated automatically.

A four-step migration

1. Measure: collect events 4768 and 4769 from controllers and filter on ticket encryption type (0x17 is RC4, 0x11 and 0x12 are AES). Recent updates add fields to these events that help identify the accounts involved.
2. Fix accounts: change old passwords, set msDS-SupportedEncryptionTypes, update keytab files on non-Windows systems.
3. Handle exceptions: identify applications and devices that can only do RC4 and document an end date for each.
4. Restrict: configure the "Network security: Configure encryption types allowed for Kerberos" policy to exclude RC4, starting with a pilot scope.

What an audit checks

• the share of tickets issued with RC4 and the accounts responsible;
• service accounts whose password predates AES key generation;
• the value of msDS-SupportedEncryptionTypes on accounts with an SPN;
• the Kerberos encryption types policy applied to controllers and servers.