PSA: check msDS-SupportedEncryptionTypes on your service accounts before April patch Tuesday

Posted by hardeningbrief@reddit | sysadmin | View on Reddit | 25 comments

We found 11 service accounts still using RC4 Kerberos in our environment. Microsoft's April update is going to break them.

Sharing this because I almost missed it.

With the April 2026 cumulative update, Microsoft is changing the default encryption for any account where msDS-SupportedEncryptionTypes is null. Those accounts have always quietly fallen back to RC4. After April they default to AES-SHA1. July makes it permanent.

The failure mode is bad. Authentication just stops. If you have NAS devices, old line of business apps, or service accounts nobody has looked at in years, you'll find out when something stops working.

To check yours, run this against the Security log on your domain controllers:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4768,4769} -MaxEvents 20 |

Where-Object { $_.Message -match '0x17' } |

Format-List TimeCreated, Id, Message

0x17 in the ticket encryption type field means RC4. Anything that comes back needs attention before April.

Microsoft also put two scripts on GitHub under microsoft/Kerberos-Crypto. List-AccountKeys.ps1 shows what encryption keys each account actually has. Get-KerbEncryptionUsage.ps1 -Encryption RC4 finds active RC4 tickets. Between those two you get a clear picture fast.

To fix an account: set msDS-SupportedEncryptionTypes to 24 (AES128 + AES256 bitmask), then run klist purge on the affected machine to drop the old ticket and force a new one.

GPO side is quick.

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Configure encryption types allowed for Kerberos. Check AES128, AES256, Future encryption types.

Leave RC4 and DES alone. If you have something genuinely ancient that can't do AES, isolate those accounts in a separate OU with their own GPO. Don't leave RC4 on domain-wide.

The actual security issue underneath all this is Kerberoasting. Any authenticated domain user, no special rights, can request a service ticket for any SPN. RC4 ticket means it can go offline to Hashcat and crack in minutes. Service accounts tend to have wide permissions and passwords that haven't rotated since the account was created. That combination is how one stale ticket becomes a full domain compromise.

Watch Event IDs 201 and 202 in the System log on your DCs. Those showed up with the January 2026 update specifically to flag accounts that will break in April. If you're seeing them, you have work to do.

Audit takes maybe 30 minutes if your environment isn't huge. GPO change is 5 minutes. Worth doing before Microsoft makes the decision for you.

A Kerberos authentication ticket (TGT) was requested. Account Information: Account Name:REDACTED Supplied Realm Name:REDACTED User ID:DOMAIN\REDACTED MSDS-SupportedEncryptionTypes:0x18 (AES128-SHA96, AES256-SHA96) Available Keys:AES-SHA1, RC4 Service Information: Service Name:krbtgt Service ID:DOMAIN\krbtgt MSDS-SupportedEncryptionTypes:0x1F (DES, RC4, AES128-SHA96, AES256-SHA96) Available Keys:RC4 Domain Controller Information: MSDS-SupportedEncryptionTypes:0x1F (DES, RC4, AES128-SHA96, AES256-SHA96) Available Keys:RC4

1. Run gpedit.msc 2. Under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options 3. Scroll down to Network Security: Configure encryption types allowed by Kerberos. 4. Uncheck boxe for: RC4_HMAC_MD5

1. In Active Directory Users and Computers, right click the domain policy then click Edit 2. Under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options 3. Scroll down to Network Security: Configure encryption types allowed by Kerberos. 4. Uncheck boxe for: RC4_HMAC_MD5

[-]

chum-guzzling-shark@reddit

I ran listaccountkeys script and have a handful of ancient accounts that show only RC4 keys. Once I reset the password on these, it should create AES-SHA1 keys right. Am I done after that?

g1nko@reddit

You have to do it twice because you have to flush the cache, as well. It's worth stating you don't have to change it to a new password; it can be the existing password, twice.

Spiritual-Yam-1410@reddit

The Kerberoasting risk is real and nobody talks about it enough. We had a pentest last year and they cracked 3 service account tickets in under 2 hours. Passwords hadn't been changed since 2019. RC4 removal is painful but necessary. FWIW also check for accounts with SPNs set that shouldn't have them. That's another whole mess.

Thanks for the reminder. I forgot about this!

I ran the List-AccountKeys script and it just spammed my screen. Get-KerbEncryptionUsage.ps1 -Encryption RC4 returns a handful of results, mostly ancient accounts that havent had password resets in a long time. How do I verify if an account has AES-SHA1 keys? I checked the msDS-SupportedEncryptionTypes in AD but they all say 0 even for known good accounts. I'd like to verify they are RC4 only, then reset the password like MS says, then check again and see if its fixed

Good point on msDS-SupportedEncryptionTypes, however, one thing worth adding: service accounts that have not had a password change since before the domain functional level was raised to 2008R2 are a special case. Setting msDS-SupportedEncryptionTypes on those accounts won't be sufficient because they have no AES key material at all - they predate AES support entirely.

The fix is two sequential password resets. Windows stores both the current password's Kerberos keys (n) and the previous password's keys (n-1) so the KDC can service in-flight tickets. The first reset generates AES keys for the new password, but the n-1 slot still holds the original RC4-only keys and the KDC can fall back to them. The second reset pushes the first reset's AES keys into n-1 and generates fresh AES keys for the current password. At that point both slots have AES material and RC4 fallback is no longer possible.

Probably not a concern for small companies, but for a large enterprise, with long-established process run by service accounts, this can be a big issue.

loweakkk@reddit

Tell me about it.... I will look at those failing during April after telling account owner for months that they should rotate their password because we will enforce AES by July. Sure we could set the supported encryption type but it's one chance to modernize the environment that we need to take.

thefinalep@reddit

I'm not sure I fully understand.

I do see a service account returning 0x17.

msDS-SupportedEncryptionTypes is set to 16.

powershell output shows :
MSDS-SupportedEncryptionTypes: 0x10 (AES256-SHA96)
Available Keys: AES-SHA1, RC4

for the Account information.

I dont have any events on the DC's for 201,202,205,206,207 .

Does that mean i'm still vulnerable to this issue? The fix is to set the msDS-SupportedEncryptionTypes to 24?

hardeningbrief@reddit (OP)

In this specific case, I would advice you to change it.

The 0x10 value enables RC4 and AES.

So after Microsoft rolls out the update, your service account might still use RC4.

Looking deeper, here is a ticket exchange:

This environment is a very old domain thats been upgraded over time. I'm starting to think the krbtgt account password has never been rotated. So krbtgt cannot take advantages of new encryption standards.

NuAngelDOTnet@reddit

Can we disable that in advance in group policy, before, before it becomes an issue?

Status-Effect-2387@reddit

Thank you

You're more then welcome!

StrongWind1@reddit

I’ve been building a site to help people understand Kerberos better, especially around these RC4 changes. It has information and guidance on the changes, plus some validation testing for different Kerberos configs. Kerberos in AD is complicated and there are a lot of different knobs to turn.

Here's a quick guide for these April 2026 RC4 changes here: https://strongwind1.github.io/Kerberos/security/quick-start/

There is a lot more information on site including valid registry keys, how the full encryption negotiation works, and a list of attacks, why they work, and how to defend against them as well.

The site also has two tools:

A tool to help decode / calculate valid msDS-SupportedEncryptionTypes and DefaultDomainSupportedEncTypes
A tool to help decode 4768 and 4769 Event IDs and add more context around the different hex values, including the full encryption type negotiation chain

Nice!

Thank you for sharing man. I've also been building a portfolio on how to harden your On-Prem AD and cloud enviroment.

This is really helpful.

Sai_Wolf@reddit

What about setting the KRBTGT account? I assume you have to do the password reset dance if you change its msDSSupportedEncryptionTypes attribute right?

raip@reddit

Technically no - because that isn't a traditional service account. That account serves as the KDC and isn't used to authenticate to anything.

You should be resetting that account (just once) every 180D regardless though - as a minimum security practice. If it's been a while and/or you've detected golden tickets, reset it twice.

This. Be sure to reset it at least every 180 days.

This account is absolutely critical. Takes a long time to crack the passwords since its 120 chars long, but with the infrastructure nowadays and if you are an interesting target 180 days is enough.

TheCopernicus@reddit

I believe you do, yes. We just did this a couple months ago and I know I did the password dance with that account.

Can we disable that in advance for all of our workstations using group policy, before, before it becomes an issue?

Yes. But be sure to audit your enviroment first.

Use the scripts Microsoft released to check if something is dependent on RC4, then you should be fine!

No_Actuator_4762@reddit

Great advice with good context. Thank you. I’ve run into at least one domain in the past that was experiencing rc4 downgrades I couldn’t ever resolve. I would have had a better chance after seeing your post. Cheers!

Man, truly means a lot! Glad to hear.

I do one of these every week if you are interested! Don't want to self promote here but you can check out my profile if you want to :)

Thanks again!!

JukeboxJohnny@reddit

Here's the page with the scripts mentioned in the OP.

I'm assuming they only need to be ran on one DC?

Thank you!

There is a parameter in the Get-KerbEncryption on too get all events across all DCs as far as I know.

It takes very long though and more often then nit crashes when started with the parameter. Better to run it seperately.