Active Directory Kerberos AES Encryption: How to Migrate from RC4 to AES256 and Harden Kerberos
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
RC4 Kerberos encryption is a legacy carried forward from Windows 2000 and NT. Modern Windows clients and DCs support AES256 by default, but service accounts and user accounts that have never had their password changed since AES was introduced may not have AES keys stored in AD. Every account without AES keys will have RC4 tickets issued by the KDC -- and every RC4 service ticket is a Kerberoastable hash waiting to be cracked. This guide walks through the audit, the account remediation, and the domain-level enforcement of AES-only Kerberos.
Audit Which Accounts Lack AES Keys
User accounts in AD store Kerberos encryption keys as supplementalCredentials. When a password is set or changed, the DC generates keys for all encryption types the account is configured to support. An account that has never had its password changed since before AES support was introduced (Windows Server 2008 / Windows Vista) may have no AES keys -- only the NTLM hash and RC4 keys. Audit accounts missing AES keys: Get-ADUser -Filter * -Properties 'msDS-SupportedEncryptionTypes', PasswordLastSet | Where-Object { ($_.'msDS-SupportedEncryptionTypes' -band 24) -eq 0 } | Select-Object SamAccountName, PasswordLastSet, 'msDS-SupportedEncryptionTypes'. The value 24 is the bitmask for AES128 (8) + AES256 (16). An account where this bitmask is 0 has no AES support configured. Also check for accounts explicitly configured to use RC4 only: Get-ADUser -Filter {msDS-SupportedEncryptionTypes -eq 4} -Properties 'msDS-SupportedEncryptionTypes', SamAccountName | Select-Object SamAccountName. Value 4 = RC4-HMAC only. Run the same queries for service accounts and computer accounts (Get-ADServiceAccount and Get-ADComputer).
Configure Accounts to Support AES256
For user accounts: the msDS-SupportedEncryptionTypes attribute should be set to 24 (AES128 + AES256) or 8 (AES256 only). Setting it does not generate AES keys until the password is reset -- the key generation happens at password change time. Set the attribute: Set-ADUser -Identity username -Replace @{'msDS-SupportedEncryptionTypes' = 24}. After setting, force a password reset to generate the AES keys: the user changes their own password, or an admin resets it. For service accounts (gMSA): gMSA passwords are automatically rotated and AES keys are generated automatically if the account is in a Windows Server 2012 or later domain. Verify: Get-ADServiceAccount -Identity gmsaName -Properties 'msDS-SupportedEncryptionTypes'. For legacy service accounts with manual passwords: set msDS-SupportedEncryptionTypes to 24 and reset the password. For the krbtgt account: the krbtgt account's encryption type determines the maximum encryption available for TGTs. Run the krbtgt double-reset (or use the Microsoft New-KrbtgtKeys.ps1 script) which generates new AES keys for krbtgt. This is a planned step -- the double-reset triggers kerberos ticket renewal across the domain.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Disable RC4 via GPO After All Accounts Have AES Keys
Only disable RC4 domain-wide after verifying that all accounts have AES keys and all Kerberos clients support AES. Premature RC4 disablement breaks authentication for legacy applications that only support RC4 and for accounts without AES keys. To disable RC4 via Group Policy: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > 'Network security: Configure encryption types allowed for Kerberos'. Uncheck RC4_HMAC_MD5. Leave AES128_HMAC_SHA1 and AES256_HMAC_SHA1 checked. Apply this GPO first in a pilot OU (a small set of test DCs and client machines). Monitor Event ID 4769 for errors -- a failure code of 0x25 (KDC_ERR_ETYPE_NOTSUPP) indicates a client or service requesting an unsupported encryption type. Move to broader deployment only after the pilot shows no failures. Note: as of Windows Server 2022 and Windows 11 22H2, Microsoft has introduced functionality to remove RC4 from the default support list -- check the current OS documentation for the specific behavior on your Windows versions.
Detect RC4 Kerberos Requests After Migration
After setting accounts to AES-only, any RC4 Kerberos request is anomalous and should be alerted on. Event ID 4769 on DCs with TicketEncryptionType = 0x17 (RC4) indicates either: a legacy application still requesting RC4 (expected during initial migration, should reduce to zero), an account that was not migrated (investigate and migrate the account), or a Kerberoasting attempt using RC4 request flags (the attack tool explicitly requests RC4 even if the account supports AES). KQL for Sentinel: SecurityEvent | where EventID == 4769 | where TicketEncryptionType == '0x17' | where AccountName !endswith '$' | summarize count() by AccountName, ServiceName, IpAddress, bin(TimeGenerated, 1h). Alert when this query returns results -- in a fully migrated domain, it should return zero. For the period before full migration, baseline the expected accounts and alert on anything outside the baseline.
Force AES on SPNs for Service Account Kerberoast Hardening
Even before completing the domain-wide RC4 removal, you can force AES-only ticket issuance for specific high-risk service accounts (those with SPNs that are Kerberoastable). Set msDS-SupportedEncryptionTypes to 24 (AES128 + AES256) and ensure the password has been reset to generate AES keys. Then test that the application using the SPN still works -- the application's Kerberos client must support AES128 or AES256. Any application that fails after forcing AES on the service account is using a legacy Kerberos stack -- that application needs to be remediated. For accounts where AES cannot be forced (true legacy RC4-only applications): accept the risk, document the exception, rotate the service account password frequently (90 days), and alert specifically on Kerberos TGS requests (Event ID 4769) for that service account's SPN from any source other than expected service consumers.
The bottom line
RC4 Kerberos encryption ties every service ticket to a password hash that can be cracked offline with commodity hardware. The migration path is: audit accounts without AES keys, set msDS-SupportedEncryptionTypes to 24, force password resets to generate AES keys, disable RC4 via GPO in a staged rollout, and alert on any remaining RC4 ticket requests. This is the single most effective control against Kerberoasting beyond just monitoring for it.
Frequently asked questions
Does forcing AES break older Windows clients like Windows 7 or Server 2003?
Windows XP, Windows Server 2003, and Windows 2000 do not support AES Kerberos and will break if RC4 is disabled. These operating systems are end-of-life and should not exist in a supported production environment. Windows 7, Windows Server 2008, and later all support AES128 and AES256 Kerberos. The more likely breakage is from third-party applications (Java-based Kerberos implementations, network devices authenticating to AD via Kerberos, UNIX/Linux systems using MIT Kerberos) -- audit these before disabling RC4 domain-wide.
What is the difference between msDS-SupportedEncryptionTypes = 0 and = 28?
A value of 0 means 'not set' -- the account uses the domain default encryption types, which typically includes RC4, AES128, and AES256. A value of 28 means AES128 (8) + AES256 (16) + RC4 (4) = all three types. A value of 24 means AES128 + AES256 only (no RC4). Leaving the attribute at 0 means the account's encryption type support is determined by the domain default, which may still include RC4. Explicitly setting to 24 removes RC4 from that account's supported types regardless of domain defaults.
Can an attacker still Kerberoast AES256-encrypted tickets?
Yes, but it is dramatically slower. AES256 cracking requires approximately 10,000 to 100,000 times more GPU compute than RC4 for the same password. A weak password (8 characters, dictionary-based) is still crackable given sufficient compute time -- but a 25+ character randomized service account password with AES256 encryption is computationally infeasible to crack offline. The combined control is AES256 encryption AND strong randomized passwords for service accounts -- gMSA (group Managed Service Accounts) with 240-character auto-rotating passwords provide both.
What is the krbtgt double-reset and why does it matter for AES migration?
The krbtgt account's Kerberos keys are used to encrypt TGTs. The double-reset procedure changes the krbtgt password twice (with a replication wait between resets) to ensure all DCs have the new keys and all cached tickets from the old keys are invalidated. For AES migration: resetting krbtgt generates new AES256 keys for TGT encryption. After the double-reset and domain-wide AES key generation on all accounts, new TGTs will be AES256-encrypted. Existing RC4-encrypted TGTs (with up to 10-hour lifetime) will still be accepted until they expire. The double-reset process also invalidates any Golden Tickets an attacker may have created from a previous krbtgt compromise.
What is the risk period between setting msDS-SupportedEncryptionTypes and completing the password reset?
Setting msDS-SupportedEncryptionTypes to 24 (AES only) on an account before completing the password reset creates a gap: the attribute declares AES-only support, but no AES keys exist yet (keys are generated on password change). During this gap, if the KDC strictly enforces the attribute and the account has no AES keys, authentication for that account may fail. On modern DCs (Server 2012 and later), the KDC falls back to RC4 if AES keys are absent even when the attribute requests AES -- preventing authentication failure, but also meaning the RC4 protection is not fully in effect until the password is reset. Set the attribute and reset the password in the same maintenance window to minimize the gap.
What is the difference between RC4 and AES encryption in Kerberos and why does RC4 weaken your Active Directory security posture?
RC4-HMAC is the legacy Kerberos encryption type derived from the account's NT hash (NTLM hash). Because the NT hash is a deterministic function of the password, an attacker who extracts the NT hash via DCSync, Mimikatz, or a domain controller compromise can directly compute the RC4 key and forge Kerberos tickets (the Golden Ticket attack) or crack the password offline using rainbow tables. AES-128 and AES-256 Kerberos keys are derived from both the password and the account's salt (typically the UPN or sAMAccountName plus domain), making them unique per account and resistant to pre-computation attacks. Even if an attacker extracts the AES key directly, it cannot be used outside the specific domain without also compromising the KDC's krbtgt keys. The practical impact: RC4 enabled on any account in your domain means that account's Kerberos authentication remains as weak as its NT hash -- password cracking that yields the NT hash immediately yields the RC4 key. RC4 elimination (disabling DES and RC4 in 'Configure encryption types allowed for Kerberos' GPO) forces AES for all Kerberos operations, raising the cryptographic bar significantly.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.