Kerberos and RC4 in 2026: audit Active Directory and migrate to AES without outages

Why RC4 became an operational risk in 2026

RC4 is no longer merely an aging algorithm to remove eventually. Windows updates released since January 13, 2026 introduced protections for CVE-2026-20833, a vulnerability that can allow weakly encrypted service tickets to be requested for offline attempts to recover a service-account password.

Since April 14, 2026, updated domain controllers default to AES-SHA1—AES128_HMAC_SHA1 and AES256_HMAC_SHA1—when no explicit configuration exists. The July 2026 updates then enabled the enforcement phase and removed the temporary RC4DefaultDisablementPhase rollback mechanism. An environment that still relies implicitly on RC4 can therefore experience authentication failures after its domain controllers are updated.

Understand what the KDC actually selects

A ticket's encryption type depends on the keys available for the target account, the types advertised by the client, the Active Directory msDS-SupportedEncryptionTypes attribute and KDC defaults. An empty attribute does not always mean an account is AES-ready: the KDC must also possess AES keys derived from the account password.

RC4 uses bit 0x4, AES128 uses 0x8 and AES256 uses 0x10. An AES128 and AES256 configuration therefore uses 0x18, or decimal 24. The value 0x1C, or decimal 28, retains RC4 with both AES variants and should only be a temporary transition.

Step 1 — Update domain controllers and centralize logs

All domain controllers should receive the applicable Windows updates. On Windows Server 2019 and later, Security events 4768 and 4769 expose the encryption types used for TGT and TGS tickets. Supported Windows Server 2016 systems receive the additional fields through cumulative updates available since January 2025.

Centralize these events in Microsoft Sentinel, Wazuh, another SIEM or Windows Event Forwarding. A few days of data may miss monthly jobs, payroll processing, backups or rarely used applications; retain several weeks that represent a complete business cycle whenever possible.

• 4768: authentication ticket (TGT) request.
• 4769: service ticket (TGS) request.
• Ticket Encryption Type 0x17: RC4-HMAC.
• Ticket Encryption Type 0x11: AES128-CTS-HMAC-SHA1-96.
• Ticket Encryption Type 0x12: AES256-CTS-HMAC-SHA1-96.

Step 2 — Monitor the new Kdcsvc events

The 2026 updates add nine Kdcsvc events, 201 through 209, to the System log on domain controllers. They identify conditions such as a client advertising only RC4, a service account without AES keys or a DefaultDomainSupportedEncTypes value that explicitly permits insecure encryption.

Events 201 and 202 were warnings during the audit phase. Under enforcement, the corresponding conditions generate events such as 203 and 204 when the KDC blocks the cipher. Event 205 identifies an explicitly insecure domain-default encryption configuration.

$start = (Get-Date).AddDays(-30)
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'
    ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'
    Id           = 201,202,203,204,205,206,207,208,209
    StartTime    = $start
} | Select-Object TimeCreated, Id, LevelDisplayName, Message

Step 3 — Use Microsoft's audit scripts

Microsoft publishes List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1 in the Kerberos-Crypto repository. The first inventories the keys available to accounts observed in events; the second summarizes the encryption types actually used.

Run them from a protected administrative workstation with the ActiveDirectory module. Review ticket and session-key encryption separately because an application can receive an AES ticket while another part of the exchange still exposes an RC4 dependency.

.\Get-KerbEncryptionUsage.ps1 -Encryption RC4

Step 4 — Inventory accounts with SPNs

User accounts with SPNs deserve particular attention because they often represent legacy services with old or manually managed passwords. An account created before AES support whose password was never changed afterward might not have the AES keys it needs.

The following report is a starting point. Correlate an empty value with events and available keys; do not replace it across the directory without validation.

Get-ADUser -LDAPFilter '(&(objectCategory=person)(servicePrincipalName=*))' `
  -Properties ServicePrincipalName,msDS-SupportedEncryptionTypes,PasswordLastSet |
  Select-Object SamAccountName,PasswordLastSet,`
    @{Name='EncryptionTypes';Expression={$_.'msDS-SupportedEncryptionTypes'}},`
    ServicePrincipalName |
  Sort-Object PasswordLastSet

Get-ADComputer -Filter * -Properties msDS-SupportedEncryptionTypes,OperatingSystem |
  Where-Object { $null -eq $_.'msDS-SupportedEncryptionTypes' } |
  Select-Object Name,OperatingSystem,DistinguishedName

Step 5 — Generate AES keys before changing the bits

Declaring that an account supports AES does not create its keys. For an old user-based service account, first coordinate a password rotation with the application owner. Then restart the service or refresh its stored credentials. Group managed service accounts simplify this step through automatic secret rotation when the application supports them.

Once AES keys exist and the application has been validated, set the attribute to 24 for AES128 and AES256. Keep this change targeted and documented; do not run a directory-wide rewrite.

$account = Get-ADUser 'svc-application' -Properties msDS-SupportedEncryptionTypes,PasswordLastSet
$account | Select-Object SamAccountName,PasswordLastSet,msDS-SupportedEncryptionTypes

# After password rotation and application validation
Set-ADUser 'svc-application' -Replace @{'msDS-SupportedEncryptionTypes' = 24}

Step 6 — Deploy AES through a pilot GPO

In Group Policy Management, create a pilot GPO and open Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, Security Options. Configure Network security: Configure encryption types allowed for Kerberos with AES128_HMAC_SHA1 and AES256_HMAC_SHA1.

Apply the GPO first to representative workstations, servers and services. Restart targeted devices because Windows updates msDS-SupportedEncryptionTypes at startup. Monitor Kerberos events and application incidents before expanding the ring.

• Ring 0: IT workstations and lab systems.
• Ring 1: noncritical application servers and pilot clients.
• Ring 2: business applications, file services, backups and scheduled jobs.
• Ring 3: critical services after owner validation.

Test the services most likely to fail

An absence of Kdcsvc events does not guarantee compatibility for every non-Windows device. Explicitly test NAS appliances, Java applications, network devices, scheduled tasks, backup software, trusts, clusters and services using SPN-bearing accounts.

FSLogix profiles on SMB storage and Azure Files using AD DS authentication deserve particular attention. Microsoft notes that objects or accounts configured for RC4 only—or left undefined in affected scenarios—can lose access after hardening. Older Azure Files shares should be validated and reconfigured for AES-256 where required.

• Complete FSLogix sign-in and sign-out.
• SMB access through the production DNS name.
• WinRM, WMI and PowerShell Remoting.
• Service and scheduled-task startup with dedicated accounts.
• Backup restoration and repository access.
• Authentication from Linux appliances, NAS devices and medical or industrial systems.

Diagnose a failure after RC4 removal

Error 0x80090342 or KDC_ERR_ETYPE_NOTSUPP means that no compatible encryption type could be negotiated. Request a ticket directly for the affected SPN with klist, then correlate the timestamp, client and service with event 4769 on the domain controller.

klist purge
klist get HOST/server.contoso.com
klist tickets

$name = 'SERVER'
Get-ADObject -Filter "Name -eq '$name' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')" `
  -Properties msDS-SupportedEncryptionTypes |
  Format-List DistinguishedName,Name,ObjectClass,msDS-SupportedEncryptionTypes

Manage an RC4 exception without undoing the hardening

With the July 2026 updates, RC4DefaultDisablementPhase is no longer a durable rollback mechanism. If an essential service cannot yet use AES, Microsoft recommends explicitly enabling RC4 in the msDS-SupportedEncryptionTypes bitmask only for the affected service account.

Give the exception an owner, justification, expiry date and replacement plan. A global value allowing RC4 for every account recreates Kerberoasting exposure and hides remaining dependencies.

Recommended change plan

• Inventory domain controllers and confirm their update level.
• Centralize events 4768, 4769 and Kdcsvc 201 through 209.
• Measure RC4 over a representative business cycle.
• Map each dependency to an application and owner.
• Rotate passwords for accounts without AES keys.
• Validate AES in a pilot ring, then by application group.
• Keep RC4 exceptions targeted, temporary and reviewed.
• Monitor KDC_ERR_ETYPE_NOTSUPP, SMB incidents and WinRM failures after every wave.

Conclusion and references

Moving from RC4 to AES is both a security and business-continuity project. The right sequence is not to select AES everywhere in one day: observe the tickets actually issued, generate missing keys, remediate applications and progressively restrict permitted algorithms.

By August 2026, this is no longer preparation for a distant change. Updated domain controllers are in Microsoft's planned enforcement phase. Remaining dependencies should be identified and addressed before the next maintenance window turns a silent weakness into a visible outage.

• Microsoft Support — RC4 changes related to CVE-2026-20833 ↗
• Microsoft Learn — Detect and remediate RC4 usage ↗
• Microsoft — Kerberos-Crypto scripts ↗
• Related article — Active Directory security assessment →
• Related article — Microsoft Defender ASR rules →