Kerberos RC4 Dies July 14: Audit Your Service Accounts Now

Microsoft’s July 14 Patch Tuesday drops the final enforcement phase for Kerberos RC4 deprecation — and this one has no rollback. The registry escape hatch that saved organizations during April’s softer cutoff is gone. If your service accounts still rely on RC4 encryption for Kerberos tickets, you have two days before authentication starts breaking in ways that surface as vague, misleading errors you’ve been misdiagnosing for years.

Why RC4 Had to Go

The culprit is CVE-2026-20833, an information disclosure flaw that let any authenticated domain user request an RC4-encrypted service ticket for any SPN in the domain. The ticket is returned, the attacker copies it offline, and then the cracking begins. Modern GPUs process billions of RC4 guesses per second — a weak service account password falls in minutes to hours. AES256 is roughly 700 times slower to crack, making Kerberoasting effectively a non-issue for accounts using strong encryption.

This is the Kerberoasting attack (MITRE ATT&CK T1558.003), and it has been a staple of Active Directory lateral movement since 2014. Microsoft has been warning about RC4’s weakness for years. July 14 is where the warnings end and enforcement begins.

The Three Phases You May Have Slept Through

Microsoft rolled this out gradually, but the final phase is the one that matters:

• January 2026: Audit mode only. New KDC system event IDs (201–209) log RC4 usage; nothing breaks yet.
• April 2026: Soft enforcement. Domain controllers default to AES-SHA1 for accounts with no explicit encryption type set. The RC4DefaultDisablementPhase registry key let you buy time by reverting to audit behavior.
• July 14, 2026: Hard enforcement. Audit mode is removed. The registry escape hatch is gone. RC4 is blocked unless an account’s msDS-SupportedEncryptionTypes attribute explicitly allows it.

If you’re still running the April workaround registry key, installing the July cumulative update removes it. There is no Phase 4.

What Breaks in Your Stack

The scope is wider than most developers expect. Any service account with a null msDS-SupportedEncryptionTypes attribute that was relying on legacy RC4 defaults is at risk. The failure mode depends on the workload:

• SQL Server: The error is “Cannot generate SSPI context” — arguably the most generic, least helpful error in the Windows ecosystem, and it has meant a hundred different things over 20 years. After July 14, if your SQL Server service account doesn’t have AES keys, this error is what you get.
• Azure Files and FSLogix: Shares created before 2023 or explicitly configured for RC4 will lose Kerberos-based SMB access. For AVD shops, this means FSLogix profile containers stop mounting. Microsoft issued explicit “action required” notices for both.
• IIS application pools: Any app pool using Windows authentication under a service account with null encryption type.
• Non-Windows Kerberos clients: Linux and Java apps using MIT KRB5 or JAAS that negotiate RC4 will break without client-side reconfiguration.
• CI/CD agents: Domain-joined build agents running under service accounts — this one often gets missed because it looks like a flaky build rather than an auth failure.

Audit in Five Minutes

Before you do anything else, run Microsoft’s detection steps on your domain controllers. The fastest path is filtering the Security event log for tickets issued with Ticket Encryption Type 0x17 (RC4):

# Find service tickets being issued with RC4 (Ticket Encryption Type 0x17)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769} -MaxEvents 5000 |
  Where-Object { $_.Message -match '0x17' } |
  Select-Object TimeCreated, Id, Message

Any account appearing in those results needs to be migrated before Tuesday. Also check the System event log on domain controllers for event IDs 201 and 202 — these are the audit-mode flags introduced in January specifically to surface RC4 dependencies.

The Fix

Two steps: set the encryption type, then reset the password to force AES key generation.

# Set AES-only encryption on a service account
Set-ADUser -Identity "svc-myapp" -KerberosEncryptionType AES128,AES256

# Verify the attribute is set correctly
Get-ADUser "svc-myapp" -Properties msDS-SupportedEncryptionTypes |
  Select Name, msDS-SupportedEncryptionTypes

Setting the attribute alone is not enough — the account needs a password reset so the KDC generates fresh AES key material. For Azure Files shares, you also need to reconfigure the storage account to use AES-256, which is separate from the service account fix.

The Ongoing Risk

Fix today’s accounts, then fix the process that created them. Developers provisioning service accounts programmatically often leave msDS-SupportedEncryptionTypes null — it’s the default in most AD provisioning scripts and was harmless when RC4 was the fallback. Post-July, null means AES going forward, but any account created with null before April and not yet given a new password is still carrying RC4 key material. Null doesn’t automatically refresh stale keys.

If you’re using ADMT for domain migrations, note that it only syncs NTLM hashes — not AES keys. Migrated accounts need password resets in the target domain before Kerberos works correctly.

Do This Before Tuesday

Run the Event ID 4769 query against your domain controllers. Find the RC4 accounts. Set msDS-SupportedEncryptionTypes, reset passwords, validate. Apply the July cumulative update on a schedule you control rather than letting it catch you mid-deployment. The blast radius for getting this wrong — broken SQL connections, dead profile containers, failing CI builds — is large enough that this is worth a few hours before the weekend is over.