Disable RC4 in Kerberos: audit, fix and enforce AES

RC4-HMAC is the Kerberos encryption type that makes Kerberoasting cheap: an RC4 ticket is encrypted with the account's unsalted NT hash, so cracking it costs about the same as cracking an NTLM hash, and an attacker who already holds the NT hash can forge RC4 tickets without knowing the password. AES tickets use a salted, iterated key derivation and are orders of magnitude slower to attack. Most domains still issue RC4 tickets for at least some accounts, not because anything needs them, but because nobody has proved nothing needs them.

This guide is the step-by-step version of the RC4 section in Kerberos hardening: how the KDC actually chooses an encryption type, how to measure RC4 use, how to fix accounts that cannot do AES, and how to enforce without an outage.

How the KDC picks an encryption type

Three inputs decide the ticket encryption type for a service ticket:

1. The target account's msDS-SupportedEncryptionTypes (bit flags: 0x4 RC4, 0x8 AES128, 0x10 AES256, 0x20 AES session keys). If set, the KDC uses the strongest type the account lists and for which it holds a key.
2. DefaultDomainSupportedEncTypes on the KDC, used when the attribute is empty. Accounts without the attribute set are the majority, so this registry value is the real domain-wide default.
3. The keys stored for the account. A type listed in the attribute is useless if the account has no key for it.

Computer accounts populate msDS-SupportedEncryptionTypes themselves from the client policy. User-based service accounts almost never have it set, so they follow DefaultDomainSupportedEncTypes, which historically meant RC4 tickets. Since the November 2022 Kerberos updates (CVE-2022-37966), the default assumed for accounts without the attribute is 0x27 (DES, RC4 and AES session keys), which gives AES session keys but still RC4 ticket encryption. Microsoft has announced further changes to move DCs to AES-only defaults during 2026, so confirm the behaviour of your current update level in the release notes before relying on defaults.

Measure: find where RC4 is used

Enable the right auditing

On DCs: Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon, enable Audit Kerberos Authentication Service and Audit Kerberos Service Ticket Operations for Success and Failure. This produces 4768 (TGT) and 4769 (service ticket) events, both with a TicketEncryptionType field: 0x17 is RC4, 0x11 AES128, 0x12 AES256. Recent Windows Server updates have added fields to these events describing the account's available keys and supported types, which makes the next steps easier if your DCs have them.

# RC4 service tickets over the last 24 hours, grouped by service and client
$since = (Get-Date).AddHours(-24)
Get-ADDomainController -Filter * | ForEach-Object {
    Get-WinEvent -ComputerName $_.HostName -FilterHashtable @{
        LogName = 'Security'; Id = 4769; StartTime = $since
    } -ErrorAction SilentlyContinue
} | ForEach-Object {
    $d = @{}; ([xml]$_.ToXml()).Event.EventData.Data | ForEach-Object { $d[$_.Name] = $_.'#text' }
    if ($d.TicketEncryptionType -eq '0x17') {
        [pscustomobject]@{ Service = $d.ServiceName; Client = $d.TargetUserName; Address = $d.IpAddress }
    }
} | Group-Object Service, Client, Address | Sort-Object Count -Descending |
    Select-Object Count, Name

Run the same query against 4768 to find clients requesting RC4 TGTs. Forward these events to your SIEM for a proper 30 to 90 day window; Get-WinEvent on busy DCs only sees what the local log retains. Microsoft also publishes helper scripts in its Kerberos-Crypto GitHub repository that summarize encryption usage from these events.

Find accounts without AES keys

AES keys are created when a password is set on a DC running Windows Server 2008 or later in a domain at 2008 functional level or higher. The creation date of the Read-only Domain Controllers group (RID 521) is a reliable marker for when the domain was prepared for that level. Any account whose password predates it has no AES keys.

$domainSid = (Get-ADDomain).DomainSID.Value
$aesDate = (Get-ADGroup -Identity "$domainSid-521" -Properties whenCreated).whenCreated

Get-ADUser -Filter 'Enabled -eq $true' -Properties PasswordLastSet, ServicePrincipalName |
    Where-Object { $_.PasswordLastSet -lt $aesDate } |
    Select-Object SamAccountName, PasswordLastSet, @{n='HasSPN';e={[bool]$_.ServicePrincipalName}}

Include krbtgt and trust accounts in the review. A krbtgt password older than that date is a finding on its own; rotate it using the krbtgt rotation procedure.

Check explicit RC4 settings

# Accounts with RC4 or DES explicitly allowed (any of bits 0x1, 0x2, 0x4)
Get-ADObject -LDAPFilter '(msDS-SupportedEncryptionTypes:1.2.840.113556.1.4.804:=7)' `
    -Properties msDS-SupportedEncryptionTypes, objectClass |
    Select-Object Name, objectClass, msDS-SupportedEncryptionTypes

# Trusts: TDOs without AES flags fall back to RC4 referral tickets
Get-ADObject -Filter 'objectClass -eq "trustedDomain"' -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

Audit: fix the blockers

Work through the list from the measurement phase:

• Accounts without AES keys: reset the password. For service accounts, coordinate with the application owner or, better, migrate to a gMSA (see gMSA migration).
• Service accounts used by non-Windows systems: regenerate keytabs with AES, for example ktpass /crypto AES256-SHA1 for the SPN mapping, and update krb5.conf permitted_enctypes on the client. Old keytabs containing only RC4 keys fail as soon as RC4 is removed.
• Appliances and legacy software that request RC4 explicitly: upgrade, reconfigure, or document a time-bound exception by setting msDS-SupportedEncryptionTypes to 0x1C (RC4 plus AES) on that one account only.
• Trusts: enable AES on both sides with The other domain supports Kerberos AES Encryption in the trust properties, or ksetup /setenctypeattr <trusted domain> AES256-CTS-HMAC-SHA1-96 AES128-CTS-HMAC-SHA1-96.

Mark service accounts explicitly as AES-capable so they no longer depend on the KDC default:

# AES128 + AES256 on user accounts that carry SPNs
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.SamAccountName -ne 'krbtgt' } |
    ForEach-Object { Set-ADUser $_ -Replace @{ 'msDS-SupportedEncryptionTypes' = 24 } }

Plan the rollout

RC4 removal is low risk when it is boring: small steps, each one reversible, each one measured. A plan that works in most mid-sized domains:

1. Weeks 1 to 4: measure only. Auditing on, events forwarded, the no-AES-keys report produced. Build a list of every client and service that appeared in an RC4 event, with an owner for each.
2. Weeks 3 to 8: fix accounts. Reset passwords of accounts without AES keys, set msDS-SupportedEncryptionTypes to 24 on service accounts, regenerate keytabs, enable AES on trusts. Each fix should make a line disappear from the RC4 report; if it does not, the root cause is somewhere else.
3. Weeks 6 to 10: client policy in rings. Pilot workstations, then all workstations, then member servers. Clients that stop requesting RC4 do not need the KDC to refuse it, so this ring rarely hurts.
4. After two quiet weeks: KDC. Set DefaultDomainSupportedEncTypes and the Kerberos policy on DCs, starting with a single site's DCs if your topology allows it.
5. Ongoing: exceptions. Every account that keeps RC4 gets a ticket with an owner and an expiry date, and is listed in a group such as Kerberos-RC4-Exceptions so the exception is visible in AD rather than in a spreadsheet.

Rollback at each step is a registry value or a GPO link. Plan a DC restart in each KDC ring so the registry change is picked up reliably, and the same for rollback. Existing tickets remain valid until they expire, so problems can take up to the ticket lifetime (10 hours by default) to appear. Keep the change window open long enough to see them, and do not stack the KDC change with other authentication changes such as LDAP signing enforcement in the same week, or you will not know which one broke a given application.

Enforce

Enforce in two layers, one ring at a time.

KDC default. On each DC, set the value that applies to every account without an explicit attribute:

# 0x18 = AES128 + AES256. Use 0x38 to also advertise AES session keys.
Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' `
    -Name 'DefaultDomainSupportedEncTypes' -Type DWord -Value 0x18

Deploy it through GPO Preferences (Computer Configuration > Preferences > Windows Settings > Registry) linked to the Domain Controllers OU so every new DC receives it.

Kerberos policy. Apply Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos with only AES128_HMAC_SHA1, AES256_HMAC_SHA1 and Future encryption types checked. It writes SupportedEncryptionTypes under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters. On member computers it limits what the client requests and updates the computer account's attribute; on DCs it limits what the KDC will issue. Roll it out to a pilot OU of workstations and servers first, then Tier 1, then DCs last.

Verify

After each ring, repeat the 4769 query. The target is zero 0x17 tickets outside documented exceptions.

# On a DC: confirm the effective settings
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\KDC' -Name DefaultDomainSupportedEncTypes
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
    -Name SupportedEncryptionTypes

# On a client: tickets in the cache should show AES-256-CTS-HMAC-SHA1-96
klist

Also watch 4768 and 4769 failures with result code 0xE (KDC_ERR_ETYPE_NOTSUPP): each one is a client or service that has lost the ability to authenticate and needs attention.

What it breaks

• Accounts without AES keys, including old service accounts nobody dared reset, fail to obtain tickets. The fix is a password reset, which may itself break the application if the password is hard-coded somewhere.
• Keytab-based integrations on Linux, Java and appliances (web SSO, SAP, storage) stop authenticating until keytabs are regenerated with AES keys.
• Older NAS and Samba versions that do not support AES for machine or service accounts, and some legacy line-of-business apps that pin RC4.
• Cross-forest and external trusts without AES enabled on the trust object break referral tickets once RC4 is gone.
• Windows XP / Server 2003 era systems: they do not support AES at all. They should not exist, but if they do, they stop authenticating.

Related reading: the Kerberos and authentication area, Kerberoasting defense for why AES matters on service accounts, and restricting NTLM to close the NT hash exposure that RC4 removal does not address.