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?
1 Reply
The 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.
