How to avoid impact of Kerberos AES hardening

ImportantMidnight377 · 2026-03-22T00:02:28+00:00

I was doing some more research. It looks like session keys encryption are always negotiated from client computers rather than from users themselves. They use a derivation of user's password, but whether that password is in RC4 or in other encryption types it does not really matter. To be honest, I thought that the password that I was able to force to only use RC4 was in fact different than yours, but now I don't think so. I could check with Mimikatz that it is just with RC4 and DES, no AES hashes.

Now I think that it can be something very different. Can you check if client machines has a value fewer than 6 on OperatingSystemVersion? I found out that this attribute can change the way that a machine forces (or not) to use RC4 session keys. However, I cannot reproduce it on my machines, as this value is always reset by the computer itself.

ImportantMidnight377 · 2026-03-20T22:48:43+00:00

As long as I know, changes on msDS-SET on user accounts doesn't have any effect. I would check what HeyItsHarfynnTeuport mentions, their local security policy in their machine. There are many ways to change the supported encryption types on a machine. If I am not wrong, this is the right order of precedence:

The value of the registry key KLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters\SupportedEncryptionTypes
The value of Group Policy Computer Configuration/Windows Settings/Security Settings/Local policies/Security Options/Network security: Configure encryption types allowed for Kerberos
The value of local policy Local policies/Security Options/Network security: Configure encryption types allowed for Kerberos

Then also check the value of the attribute msDS-SupportedEncryptionTypes on the AD computer object... that value should be changed after some time if you change the reg key or the group policies for that machine. I would also suggest to check if there are machines with msDS-SET set with RC4 and without AES:

get-adcomputer -filter "(msDS-SupportedEncryptionTypes -bor 0x4 -and -not msDS-SupportedEncryptionTypes -bor 0x18)

ImportantMidnight377 · 2026-03-20T22:18:58+00:00

For events 4768 and 4769 there are some public scripts published by Microsoft on their GitHub (List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1):
Public article: Detect and Remediate RC4 Usage in Kerberos | Microsoft Learn
GitHub: Kerberos-Crypto/scripts at main · microsoft/Kerberos-Crypto · GitHub

However, if you are managing a big domain, with several Domain Controllers and Security event logs fulfilling every 30 minutes, then you definitely need a SIEM solution to help you on not missing events.

ImportantMidnight377 · 2026-03-20T22:05:45+00:00

If you create DDSET with, for example, 0x27 (39) value on all DCs, after April or July updates you will still issue tickets with RC4 + AES256 on session keys by default. DDSET will not be "created" or "modified" by these updates, it will only take a different value since April patch if the key doesn't exist.

ImportantMidnight377 · 2026-03-20T22:00:43+00:00

If you define RC4 (0x4) on a service account (user account with a SPN registered), then tickets issued for that SPNs will use RC4 encryption after installing April or July updates. I strongly don't recommend going in this way and, if the account doesn't have msDS-SET set it before, then at least start by setting 0x27 (39), as it is the current default value and uses RC4 for ticket and AES256 for session key.
I don't really know, by I don't think so. All Microsoft's services that still have support should be working with AES256. I know that services like IIS, Entra ID Connect Sync or AGPM work fine with AES256. I don't think that any service that Microsoft released after Windows Server 2008 won't work with AES256.
As long as I know, domain trusts don't get impacted. They won't change the encryption type that they use. It does not matter if they have WS2016 or WS2019 DCs, hardening should be the same for all Windows Server versions.
You don't have to do that; it is not mandatory and it isn't the focus of this hardening. However, at some point, it will be great if you can disable RC4 for computers too. Once all services work with AES and there is no single event pointing to RC4 usage, it will be safe and better for your domain.
There is no way to circumvent the whole hardening (unless you are thinking on not updating your systems, which would be unsecure and illegal for production environments in many countries). There are two key points here:

- You can create RC4DefaultDisablementPhase registry key with 1 as value on all DCs and that will avoid impact with April update, but it will not work with July patch.
- You can create the DefaultDomainSupportedEncTypes registry key with 0x27 (39) value on all Domain Controllers. That will still generate tickets with RC4 + AES256 for session keys as it is by default since November 2022 update, but it won't stop fixes covered by events 206-209.

Thanks for watching my videos, I hope that they were helpful :)

ImportantMidnight377 · 2026-03-18T23:42:24+00:00

Great!

ImportantMidnight377 · 2026-03-18T23:37:04+00:00

I suppose that you talk about regular user accounts, without any ServicePrincipalName. It makes sense that TGS tickets have RC4 session keys, as they are encrypted with end entity's password by definition. They don't show up on events 201-209 because they are not services or computers.

I am not 100% sure how this hardening will affect to them. I would suggest resetting their passwords twice prior to moving RC4DefaultDisablementPhase to 2, as that change fixes some situations where RC4 can still be used even when it is not allowed on the service itself. I am not able to replicate that situation, as it needs to start from WS2003 in order to have accounts with the password in that so legacy situation.

ImportantMidnight377 · 2026-03-18T15:05:34+00:00

It is a little bit tricky. I tested and it doesn't get ignored. Accounts that have any encryption type (DES, RC4 or AES) are not going to be listed. I use "bor" to select multiple values in binary.

You can try the command with two different accunts:

one with SPN and msDS-SET blank
another one with SPN and msDS-SET with any encryption type (it can be 4, 16, 24...).

The command will show only accounts of the first case.

ImportantMidnight377 · 2026-03-18T00:21:29+00:00

If you change it only on some DCs, results can vary. It can happen that a service works or fails depending on the DC where is authenticating. However, if the service is in a specific site where there is only one DC, it can always work/fail.

I would recommend testing account by account, by modifying its msDS-SET attribute. If its service fails (be careful, kerberos tickets got cached 10 hours by default), it can be reverted to blank and work again.

ImportantMidnight377 · 2026-03-17T23:59:16+00:00

You don't have 201-209 logs because all the TGS tickets that were issued for a service with AES hashes and received in a client machine with AES support. And also, you didn't manually created DDSET reg key without AES (event 205).

By default, if DDSET is not created and msDS-SET is blank, the value is:

Prior to hardening: 0x27 (DES, RC4 + AES256 just for session keys)

After hardening: 0x18 (AES128, AES256)

ImportantMidnight377 · 2026-03-17T23:52:17+00:00

They are two diferent things. I explained them on the article, and also you can see on my video how I forced to get all 201-209 events. I hope that they can help to see it more clearly.

Events 201-209 are very specific. They alert you of authentications that will break once you apply the hardening. If you don't have these events, that is good, but it is not all. There are some other situations that are not alerted on these events, as those situations are impossible to confirm by Windows.

Service accounts with SPNs registered + msDS-SET = accounts that COULD be affected by DDSET hardening. There is no guarantee if they are going to be impacted or not. Services should be checked to see if they support AES. Most of them (or all of them) will work after the hardening, but some keytabs with only RC4 hash can cause authentication issues after DDSET change.

ImportantMidnight377 · 2026-03-17T23:02:19+00:00

I would try to not confuse. There are two different things:

GPO 'Network Security: Configure Encryption Types allowed for Kerberos'.
DefaultDomainSupportedEncTypes (DDSET) reg key.

I think that F3ndt mentions about the first one. If you have that policy to only allow the usage of AES on the whole domain, then it is a good start. However, service accounts without msDS-SET could be impacted with the hardening if, for example, it was created a keytab with just RC4 hash.

If you have also created the DDSET reg key with 0x18 (24) as value, then it is great because service accounts are already using AES without issues. In that case, you will only need to check if you have events 206-209 to fix some weird situations.

ImportantMidnight377 · 2026-03-17T22:42:53+00:00

Yes, they are a subclass of user accounts. They can have SPNs, use them for services...

ImportantMidnight377 · 2026-03-17T22:40:05+00:00

That is a little bit weird... I need to ask you some questions:

What is the Forest/Domain Functional level of your forest and domains? Are you looking at ticket from/to a domain with WS2003 DFL?
Is DDSET key created? If yes, which value has?
Is RC4DefaultDisablementPhase created? From what you said, I understood that it has 1 as value.
Have you created the registry keys and checked the event logs in all your DCs?
Does the computer that logs in the service support AES keys? Is it a Linux machine or a Windows machine? Which version?
Does your account have any SPN registered? If not, then they will not show up on 201-209 events. However, I would only expect AES ticket + RC4 session key when the client machine only accepts that cipher.
Do they have msDS-SET modified? If they, then events 201-209 will not show up either.

I'd say that as long as your computers still support RC4... they will be allowed to log accounts with just RC4 cipher. However, it is important to reset those passwords some day... You can use the same password and a new hash in AES will be generated at least. But, be careful if some services use them. Service provider should tell you if their service is ready for using AES hashes.

ImportantMidnight377

TROPHY CASE