Forum Discussion
Beyond RC4 for Windows authentication - Question regarding KB5073381
In KB5021131 MS recommends setting the value for DefaultDomainSupportedEncTypes to 0x38, in the new KB 5073381 it's 0x18. This removes the setting that forces "AES Session Keys" which should be fine if Kerberos Tickets can only use AES Encryption.
But what about accounts that have RC4 enabled in their msds-supportedEncryptionTypes attribute? They could still use RC4 for Kerberos ticket encryption and would then also fallback to RC4 session ticket encryption. As far as I believe the DefaultDomainSupportedEncTypes was explicitly introduced to avoid this scenario.
Or is there now some hard-coded mechanism that always ensures that Session Keys are AES encrypted?
2 Replies
I have been testing this behavior in a lab while analyzing Kerberos events related to the RC4 deprecation effort.
One important observation is that even when an account still allows RC4 (for example when msDS-SupportedEncryptionTypes includes RC4 or is not explicitly defined), modern domain controllers will still prefer AES when both the client and the service support it.
From the event log perspective, you can see this clearly in Event ID 4769. When AES is available, the ticket encryption type will be AES (0x12 or 0x11) even if RC4 is technically still permitted by the account configuration.
In practice, this means that the new recommendation of DefaultDomainSupportedEncTypes = 0x18 aligns with what we are observing operationally: the KDC automatically prefers AES, and RC4 tends to appear mainly when there is a capability mismatch — for example with legacy clients or accounts that do not yet have AES keys because the password has not been reset since AES support was introduced.
For organizations preparing for the RC4 enforcement phase, analyzing Event IDs 4768 and 4769 across domain controllers is extremely helpful to identify the real sources of RC4 usage before enforcing stronger policies.
For additional technical context and practical analysis approaches, we documented our findings here:
https://github.com/v-jfanca/cve-2026-20833-rc4-kerberos/blob/main/docs/kerberos-rc4-cve-2026-20833-EN-US.mdThe system has become smarter. The safety is now "Built-In."
It is now Automatic In the past, you had to tell the server exactly what to do. But with the latest Windows updates, the server's "brain" has been upgraded. Now, if the server sees that a computer is capable of using the strong AES handshake, it will automatically use it. It doesn't need you to flip a special switch (the 0x20 bit) to tell it to do so.
The Weak Way is being Retired Microsoft is slowly "retiring" the old, weak RC4 handshake. The new setting (0x18) basically says: "We are moving to a world where only strong handshakes exist." Even if an old account has RC4 enabled, the server will still try to use the strong AES handshake first as long as it’s available.
Cleaning up the mess By changing the recommendation to 0x18, Microsoft is cleaning up the settings. It’s like a car manufacturer removing a manual "Choke" button because the car’s computer now handles the engine temperature automatically. Removing the button doesn't make the car less safe; it just means the car is now smart enough to handle it without your help.
