Kerberos RC4 Changes Confusion

Posted by ryaninseattle1@reddit | sysadmin | View on Reddit | 18 comments

So we have DCs that are fully patched with all Windows Updates until this months.

Kerberos success and failure auditing is enabled in audit policy.

We are not seeing a SINGLE event ID 201-209 in the System event logs.

I thought from this article that meant we are good.

https://support.microsoft.com/en-us/topic/how-to-manage-kerberos-kdc-usage-of-rc4-for-service-account-ticket-issuance-changes-related-to-cve-2026-20833-1ebcda33-720a-4da8-93c1-b0496e1910dc

However it looks from running the ".\Get-KerbEncryptionUsage.ps1 -Encryption RC4" script we are still using RC4 on a handful of computer or service accounts.

Ticket : RC4

SessionKey : AES256-SHA96

I believe I can use the "RC4DefaultDisablementPhase" reg key to buy us a few months whilst I understand this - but there seems to be a bunch of contradicting articles.

Which do I trust please?

[-]

Ok_Squash7@reddit

Saw a similar thing where tickets were encrypted with RC4 and both the service account with the SPN and the calling accounts had AES keys available. No 20x events in the System Logs.

In all cases I manually set the SPN accounts to only support AES (Set-ADUser with -KerberosEncryptionType) and things started using AES ticket encryption with no issues (your mileage may of course vary)

My takeaways were 1) everything would probably have been fine 2) I don't understand the negotiation process that was resulting in RC4 before the changes

[-]

Ok_Figure7074@reddit

Did you reset the passwords too?

[-]

ryaninseattle1@reddit (OP)

Yeah that's sort of where I am now. So I think we definitely have some NAS devices that need something updating but hopefully once we get past those there doesn't look like there is too much.

[-]

willwilson82@reddit

I have the opposite results from the script, my QNAP NAS is reported as

Ticket :AES256-SHA96
SessionKey : RC4

Both the DC and the QNAP shouldn't request or offer RC4 but I'm still seeing this...

[-]

h33b@reddit

Bit the bullet on my DC's.

After patch and reboot, my QNAP Session keys flipped from 17 (RC4) to 12 (AES).

It seems to me that the Ticket is the more important bit and that SessionKey just works itself out.

[-]

willwilson82@reddit

That's good to hear, I'm planning on doing my DCs on Monday and feeling more confident about it now.

[-]

whoelse_@reddit

i have seen this same thing with many devices where the ticket will be AES256 but the session keys are rc4. i cant find a good reason for this behavior.

[-]

h33b@reddit

I'm seeing a lot of this as well and I don't understand how important, if at all, the SessionKey part is.

[-]

ImAChickenFarmer@reddit

I have been working on this all week. What I have found that looks like it may work for us is to look at each DC logs and look for events 201-209. Then do a find for 0x17. If found the. You need to fix that account. Check account t attribute that msDS encryption is either 0x18 or not set. Then reset password which will generate the SHA keys. Then search again with a refreshed log and see if that recent login is now showing SHA1, RC4 as available keys. And that the 0x17 are now showing as 0x11 or 0x12.

Then go to the security logs on each DC and search for events 4678, 4679 and search via find 0x17. Check those accounts and reset those passwords and check again. When you do not see any events using 0x17 and start seeing them change to 0x11 or 0x12 you should be good.

Your mileage may vary. This is just what I have found which looks like it will work.

[-]

arbiteralmighty@reddit

The only account we found still using RC4 was the AzureADSSOACC computer object. Once we set its supportedencryptiontypes to 24, it stopped using RC4. Thankfully nothing broke after doing so.

[-]

andwork@reddit

reset account password and check log again.

if the password was set since a lot of time and "password never expire" flag is active, that can be the cause.

[-]

ryaninseattle1@reddit (OP)

So yeah I think with some of the accounts that sounds likely as there's a couple of service accounts in there.

[-]

Thundahead@reddit

yeah set RC4DefaultDisablementPhase to 1

what version are your DC's, do you see any 4768 or 4769 events?

it maybe that your service accounts just need the password regenerated

[-]

ryaninseattle1@reddit (OP)

Yeah so that sounds like the plan right now.

RC4DefaultDisablementPhase

Patch the DCs.

Sort out the RC4 usage.

I'm just annoyed that the KB that seems to say "look for 201-209 events" doesn't actually tell you very very clearly that not having 201-209 events doesn't mean you're OK.

[-]

trail-g62Bim@reddit

Saw something similar. My understanding is this:

Check how old the password is for the service accounts in question. We had two that hadn't been updated in ages (which is a different problem we are working on). My understanding is the keys get generated when the password is set, so even if the account is "allowed" to use SHA, if the password is too old, it may not have generated the SHA keys when the password was set.

I reset the password on the two accounts and now they show SHA, so I think we are good. If you are unsure where those accounts are being used, you can reset the password using the password it already has to generate the new keys. I am unsure if it needs to be done twice, so I did it twice to be sure.

All of our accounts still advertise RC4, since it hasn't been disabled. But they also all have SHA now listed, so I assume that means we are good when RC4 is taken away. Normally I would force it, but since the update just got released, I'll probably let Windows handle it on one DC and then monitor for failed auths.

[-]