Kerberos RC4 is done. The July 2026 Windows updates removed the last rollback switch, so domain controllers now assume AES unless an account explicitly says otherwise. If a service account was quietly depending on RC4, it stopped working somewhere in this rollout and the symptom looked like a random authentication failure.

This is the tail end of a change Microsoft ran in three phases through 2026 to address CVE-2026-20833, an information disclosure issue where an attacker could request service tickets with weak encryption and crack the service account password offline.

The Three Phases

January 13, 2026, initial deployment. Updates added audit events warning about accounts that would break later, plus the RC4DefaultDisablementPhase registry value so admins could opt into the new behavior early.

April 14, 2026, enforcement with manual rollback. The KDC default for DefaultDomainSupportedEncTypes changed to AES-SHA1 only, value 0x18, for any account without an explicit msDS-SupportedEncryptionTypes attribute. The rollback registry value still worked.

July 2026, enforcement. Updates released in or after July 2026 remove support for the RC4DefaultDisablementPhase subkey entirely. There is no supported way back.

The important detail in the middle phase is what "no explicit configuration" means. Domain controllers with a DefaultDomainSupportedEncTypes value already set were not functionally affected. Everyone else inherited the new AES-only default, and any client or service that could only speak RC4 lost the ability to get a usable ticket.

Microsoft: managing the Kerberos KDC RC4 changes for CVE-2026-20833

How To Check What Broke

Microsoft added nine audit events, IDs 201 through 209, logged by source Kdcsvc in the System event log on Windows Server 2012 and later domain controllers. Pull them from every DC:

Get-WinEvent -FilterHashtable @{
  LogName      = "System"
  ProviderName = "Kdcsvc"
  Id           = 201,202,203,204,205,206,207,208,209
} -MaxEvents 200 | Select-Object TimeCreated, Id, Message

Event 201 is the one that names a specific victim. It fires when a client advertises only RC4, the target service has no msDS-SupportedEncryptionTypes defined, and the domain controller is left guessing. The message carries the account name, the service name, the client IP address, and the encryption types the client advertised, which is everything you need to identify the offender.

Event 205 is different and worth checking separately. It means the domain controller itself has an explicit DefaultDomainSupportedEncTypes value that still permits RC4. That machine will keep working and keep being insecure, so it will not show up in a list of broken things.

To inspect a single account, read the attribute directly:

$accountName = "SVC-LegacyApp"
$parameters = @{
  Filter     = "Name -eq '$($accountName)' -and (ObjectClass -eq 'Computer' -or ObjectClass -eq 'User')"
  Properties = "msDS-SupportedEncryptionTypes"
}
Get-ADObject @parameters | Format-List DistinguishedName,msDS-SupportedEncryptionTypes,Name,ObjectClass

The value comes back in decimal. A blank result means the attribute is not set at all, which is the case that now falls through to the AES-only default.

Microsoft: detect and remediate RC4 usage in Kerberos

Fixing the Accounts That Failed

The correct fix is to make the service support AES, not to re-enable RC4. Most of the time that means updating the application, the appliance firmware, or the NAS that is holding the environment back. Vendors have had years of notice on this one.

Where a service genuinely cannot do AES yet, Microsoft’s guidance is to set RC4 explicitly in the msDS-SupportedEncryptionTypes bitmask on that specific service account rather than loosening the domain default. It keeps the exception scoped to the one account instead of handing RC4 back to everything.

Treat any account you have to do that to as an open item with a date on it, because the direction of travel here is clear and the next hardening wave will not be gentler.

Fix Domain Controller Reboot Loop After KB5082063

Find the Account Lockout Source in Active Directory

Server 2016 DC 15 Character Hostname Failures

Authentication failures after the Kerberos hardening? Contact Rain City Techworks.