The Short Version

Microsoft announced that starting April 2026, the default encryption for Kerberos will change from RC4 to AES. If any of your accounts - service accounts, user accounts, computer accounts - don’t have AES encryption keys stored in AD, authentication will fail.

Here’s why this matters to you personally: you don’t need to have done anything wrong. An account that’s been working perfectly for 15 years can suddenly stop working overnight because the domain controller changes how it issues tickets.

And if you’re running Windows XP or Server 2003 anywhere? Those systems have zero AES support. They will completely lose domain connectivity. Not “degraded service” - complete authentication failure.

The Timeline You Need to Know

Right now, we’re in audit mode. You should be seeing Event IDs 201-209 in your Domain Controller System logs if you have RC4 dependencies. If you’re not checking those logs… start.

Why Microsoft Is Doing This (And Why You Should Care)

Here’s the thing nobody tells you about Kerberoasting: any authenticated user can do it. Your receptionist. The intern. The contractor who just joined for a two-week project.

The attack works like this:

1. Any domain user asks the DC for a service ticket to any SPN
2. The DC happily provides it (this is by design - it’s how Kerberos works)
3. That ticket is encrypted with the service account’s password hash
4. The attacker takes the ticket offline and cracks it

One command. Takes seconds. No firewall blocks it. No EDR detects it. No SIEM alerts on it. The request looks completely normal because it is completely normal.

The only defense is password strength and encryption type.

With RC4 encryption, a modern GPU can try 4 billion passwords per second. With AES-256, that drops to about 6 million per second. That’s roughly a million times slower.

Here’s what this means practically:

• RC4 + “Summer2026!” = cracked in under a second
• AES + “Summer2026!” = cracked in a few hours
• AES + 25-character random password = effectively uncrackable

Now imagine your SQL service account gets cracked. That account probably has admin rights to your SQL servers. Maybe it’s in a privileged group. Maybe it’s a path to Domain Admin. I see this in almost every engagement - service accounts with way too many privileges.

The Ascension Health breach in 2024? 140 hospitals. 5.6 million patient records. Started with Kerberoasting.

This is why Microsoft is forcing this change. They’re not doing it to annoy you - they’re doing it because RC4 has been a gaping security hole for over a decade.

Are You Affected?

Let’s find out. Here’s what needs AES keys to keep working:

The Easy Checks

Service accounts with SPNs - These are your highest risk. Any account with a Service Principal Name can be Kerberoasted, and if it still uses RC4, it’s both a security risk AND will break in April.

# Find accounts without msDS-SupportedEncryptionTypes set (RC4 by default)
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_.'msDS-SupportedEncryptionTypes' -eq $null -or $_.'msDS-SupportedEncryptionTypes' -eq 4 } |
    Select-Object Name, SamAccountName

User accounts with “password never expires” - If someone set this flag years ago and the user never changed their password, they might not have AES keys.

Computer accounts - Usually fine because they auto-rotate passwords. But if you’ve got machines that have been disconnected or have broken trust relationships…

The Real Test: Check the Events

On your Domain Controllers, look for Event IDs 202 and 207 in the System log. These are your problem children:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='KDCSVC'; Id=202,207} |
    Select-Object TimeCreated, Message

• Event 202 = Service account missing AES keys
• Event 207 = Account configured for AES but doesn’t actually have AES keys

If you see these events, those accounts will break in April.

The Fix: It’s Simpler Than You Think

Here’s what generates AES keys in AD: changing the password on a Domain Controller running Windows Server 2008 or later.

That’s it. You don’t need to run special scripts. You don’t need to modify attributes manually. Just reset the password.

For Service Accounts

# Prompts for password securely (masked input, won't appear in command history)
Set-ADAccountPassword -Identity "svc_sqlserver" -Reset -NewPassword (Read-Host -AsSecureString "Enter new password")

Then update the password wherever it’s used (services, scheduled tasks, config files, connection strings…).

Pro tip: I know what you’re thinking - “can I just reset it to the same password?” Actually, yes! Here’s the trick most people don’t know: when you reset a password on a modern DC (2008 R2+), it regenerates ALL key types the DC supports - including AES. The DC doesn’t check if the password is “new” or “the same”. It just processes whatever password you give it and generates fresh keys.

So for service accounts where changing the password everywhere would be a nightmare: just reset it to the same value. AES keys get generated, applications keep working.

One caveat: Your password history policy might block setting “the same” password. If that happens, you can temporarily exclude the account from the policy, or check if admin-initiated resets bypass history (depends on your configuration).

For Computer Accounts

Option 1: Just restart the computer (if it’s been a while since it rotated its password)

Option 2: Force a password reset:

Reset-ComputerMachinePassword -Credential (Get-Credential)

For User Accounts

Have them change their password. Or force a reset at next logon. Either works.

After the Fix: Verify

Get-ADUser -Identity "svc_sqlserver" -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

You want to see a value of 24 (AES only) or 28 (AES + RC4). If you see 4 (RC4 only) or null, the password wasn’t reset on a modern DC.

Edge Cases (The Annoying Stuff)

Windows XP and Server 2003

Look, if you’ve kept your XP/2003 systems until now, there’s a low chance you’ll decommission them just because of this article. I get it. Legacy applications. OT systems. Vendor lock-in. I’ve seen it all.

But here’s the reality: these systems cannot do AES. Period. The operating system doesn’t support it. Setting attributes in AD won’t help. There is no patch. There is no workaround that keeps them domain-joined and working.

Your options:

Option 1: Finally migrate (I have to say it)

Option 2: Isolate completely - This is what I recommend for most people:

• Remove from domain. Use local accounts only.
• Put in isolated VLAN with strict firewall rules
• Access only via a jump host (a modern, domain-joined machine)
• The legacy machine should talk to minimal systems
• This is exactly what we do for OT/industrial systems that can’t be upgraded

The isolation approach is actually how most organizations handle legacy OT systems anyway. You’re essentially treating it as an untrusted network segment that happens to be inside your building.

Linux/Unix with Keytabs

If your keytab only has RC4 keys, regenerate it with AES:

# Check what you have
klist -kte /etc/krb5.keytab

# Look for 'aes256-cts-hmac-sha1-96' - if you only see 'arcfour-hmac', you need new keys

# Regenerate (this resets the AD password)
msktutil --update --keytab /etc/krb5.keytab --enctypes 0x18

Third-Party Appliances (NAS, Printers, etc.)

Check if newer firmware supports AES. Many vendors added AES support years ago but customers never updated.

If the vendor truly doesn’t support AES:

• Document it as a security exception
• Put the device in an isolated VLAN
• Use a dedicated service account with explicit RC4 allowed
• Set a very strong password (25+ characters)
• Tell Microsoft: stillneedrc4@microsoft.com (they’re tracking vendors who haven’t upgraded)

Trust Relationships

If you have domain/forest trusts, they need AES enabled too:

1. Open Active Directory Domains and Trusts
2. Right-click domain > Properties > Trusts
3. Select the trust > Properties
4. Check “The other domain supports Kerberos AES Encryption”

Or via command line:

ksetup /setenctypeattr TRUSTED.DOMAIN.COM AES128-CTS-HMAC-SHA1-96 AES256-CTS-HMAC-SHA1-96

Timeline Summary

Your Action Plan (Do This NOW)

This week:

1. Install January 2026 updates on your DCs if you haven’t already
2. Check for Event IDs 201-209 on Domain Controllers (the commands are in this article, scroll up)
3. Run the at-risk service account script from the “Are You Affected?” section above - export that list, it’s your remediation backlog

February:

4. Reset service account passwords - Start with accounts that have SPNs
5. Update keytabs on Linux/Unix systems
6. Check trust relationships for AES support

March:

7. Test enforcement mode on one DC:

   reg add "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" /v RC4DefaultDisablementPhase /t REG_DWORD /d 2 /f
   

8. Fix anything that breaks
9. Have a plan for XP/2003 systems (isolate or migrate)

Final Thoughts

I know this is another thing on your already-too-long list. But here’s the thing: this change is happening whether you’re ready or not. July 2026 is the hard deadline - after that, there’s no rollback.

The good news? The fix is straightforward. Reset passwords. Check keytabs. Update trusts. The audit mode events tell you exactly what’s at risk.

The bad news? If you wait until April and things break, you’ll be doing emergency password resets during an outage instead of planned changes during a maintenance window.

Your call.

Questions? Reach out directly: samy@cybernoob.io

Want to talk through your specific situation?

Book a call: https://link.cybernoob.io/book-a-call

References

• Microsoft: Detect and Remediate RC4 Usage
• Microsoft: CVE-2026-20833 KB Article
• Microsoft Blog: Beyond RC4 for Windows Authentication
• GitHub: Microsoft Kerberos-Crypto Detection Scripts
• SpecterOps: Is Kerberoasting Still a Risk When AES-256 Is Enabled?