Microsoft is changing how domain controllers handle Kerberos encryption this month. The April 2026 cumulative update switches the default from RC4 to AES-SHA1 for any account that doesn't have an explicit encryption type set. In July, the change becomes permanent with no rollback option.

If you have service accounts, NAS devices, or legacy applications that silently rely on RC4 for Kerberos tickets, authentication will stop working. You won't get an error message. Logins will just fail.

From experience: RC4-encrypted Kerberos tickets with weak passwords take minutes to crack offline. Not hours. Minutes. That's why Microsoft is killing the fallback.

This is a Kerberoasting problem. Any authenticated domain user, no admin rights needed, can request a service ticket for any SPN in the domain. If that ticket is encrypted with RC4, the password can be cracked offline with Hashcat in minutes.

Here's what that looks like in practice: attacker requests a service ticket, pulls the RC4-encrypted hash out of it, cracks it offline, and now they have the service account password. These accounts tend to have broad privileges and passwords that haven't changed in years. That's how one weak ticket turns into a full domain compromise.

The vulnerability is tracked as CVE-2026-20833 (CVSS 5.5, information disclosure). The relevant CIS benchmark control is 2.3.11.4: "Network security: Configure encryption types allowed for Kerberos."

Step 1: Check your event logs

Microsoft added 9 new Kerberos audit events to the System event log with the January 2026 update. An effective way to search for relevant logs is as follows:

If there is an account that shows up with MSDS-SupportedEncryptionTypes set to ‘0×4 (RC4)’ you should check the account. I am going to show you how to disable RC4 on the accounts later.

Step 2: Audit your accounts

Microsoft published detection scripts on GitHub (github.com/microsoft/Kerberos-Crypto). Two matter here:

List-AccountKeys.ps1 shows what encryption keys each account actually has. If the output includes AES128-SHA96 or AES256-SHA96 in the Keys column, that account is fine. It doesn't matter if RC4 also appears, we're disabling that in the next step. The danger is accounts where RC4 is the only key type.

If an account only has RC4 keys, that server is running outdated software or the account password hasn't been reset on a modern domain controller. Flag it.

Get-KerbEncryptionUsage.ps1 -Encryption RC4 finds active tickets still using RC4. If this returns results, those are your at-risk connections. Fix: Check the msDS-SupportedEncryptionTypes attribute on the target account. You can only find this attribute with the Advanced Features enabled in Active Directory.

Select msDS-SupportedEncryptionTypes, then set it to AES128 and AES256 values only by giving it the value ‘24’.

After that, run this command on the target to get a new Kerberos ticket:

Then verify the new ticket uses AES, not RC4.

One important thing to understand here: Microsoft is not removing RC4 from Windows. They're changing what happens when an account has no encryption type configured at all. Up until now, those accounts quietly fell back to RC4. After April, they'll default to AES-SHA1. After July, that's permanent.

If an account has msDS-SupportedEncryptionTypes explicitly set to something, even if it includes RC4, the domain controller will honor that setting. The accounts that are going to break are the ones where nobody ever set this attribute. The ones nobody has looked at in years.

Step 3: Disable RC4 via GPO

GPO path:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos

Check only these three:

Leave RC4_HMAC_MD5 and DES unchecked. Link this GPO to your Tier-0 and Tier-1 Oranization Unit. If you don’t use Tiering yet, link it with your Domain Root.

Exceptions: If an account genuinely cannot use AES (old NAS, legacy line of business app), create a separate OU with a separate GPO that includes RC4_HMAC_SHA1 alongside the AES options. Move only those accounts into that OU. This is temporary. Plan to replace those systems.

Rollback: If something breaks, set the GPO to Not Configured. Run gpupdate /force. Authentication returns to pre-change behavior immediately.

System event log on domain controllers: Event IDs 201, 202, 206, 207 (new with January 2026 update)
Security event log: Event IDs 4768, 4769 with Ticket Encryption Type 0x17 (RC4)

If you see Event ID 201 or 202 after installing the January update, you have accounts that will fail when April enforcement kicks in.

What: RC4 Kerberos default fallback disabled by Microsoft
Who's at risk: Any AD environment with service accounts where msDS-SupportedEncryptionTypes is null
Fix time: 30 min audit + 5 min GPO change
Cost: Free
Requires reboot: No (GPO applies on next refresh)
CVE: CVE-2026-20833 (CVSS 5.5)
CIS: Windows Server Benchmark 2.3.11.4

Tell your manager: "We audited all service accounts for RC4 Kerberos dependencies ahead of Microsoft's April enforcement deadline for CVE-2026-20833. X accounts were remediated. We're compliant with CIS Benchmark 2.3.11.4."

Next week: how to replace service accounts with gMSA to eliminate Kerberoasting exposure entirely.