On November 8th 2022, Microsoft released a number of updates in the monthly patches.
Several issues in Kerberos should be fixed, but the update also creates issues with Kerberos in some circumstances. The update including the issue mentioned below is KB5019964 (server 2016) and potentially KB5020023/KB5020010(2012 R2), KB5019966 (server 2019), KB5019081 (server 2022). I left out the earlier Windows versions you shouldn’t be using anyways.
One of my main customers, a large financial institute in the Netherlands, uses quite strict security requirements and a while back we configured all user accounts to use AES128/256 only for Kerberos authentication.
In the update released on November 8th, several new registry keys are introduced for domain controllers. One of these allows you to set a default value for domain wide authentication protocols, but the default value and the behavior if the setting is absent, allow anything BUT AES based encryption. The exact opposite of what the update is supposed to do…
I’m still working on the details, for now I can only conclude the following:
KB5021131, which relates to a part of the supposed Kerberos improvements, describes the creation of:
| Key | HKEY_LOCAL_MACHINE\System\currentcontrolset\services\kdc |
| Value | DefaultDomainSupportedEncTypes |
| Data type | REG_DWORD (32) |
| Default Value | 0x27 |
This default value AND the behavior if the registry is not set, seems to cause the issue. The value is based on a bitmask, allowing certain encryption types and deselecting others:
| Hex value (bit address) | Kerberos Encryption | Strength |
| 0x1 | DES_CBC_CRC | — |
| 0x2 | DES_CBC_MD5 | — |
| 0x4 | RC4_HMAC_MD5 | – |
| 0x8 | AES128_HMAC_SHA1 | + |
| 0x10 | AES256_HMAC_SHA1 | ++ |
| 0x20 | Future encryption types (The Microsoft article mentioned above includes a link that describes these future types in more detail) |
Additionally, this setting seems to not adhere group policy settings related to Kerberos encryption types (Network security: Configure encryption types allowed for Kerberos)
This hexadecimal value (0x27) explicitly excludes the usage of AES128 and AES256 (selects all others), leaving only the protocols you should not be using anymore.
When user objects have been configured to use AES128 and AES256, no supported encryption type remain, and logons will fail.
This might even lock you out of AD, when all administrative accounts are set to only allow AES and all domain controllers are patched before settings are corrected.
Create or change the above registry setting with a value of 0x1C (RC4, AES128, AES256) or 0x3C (same but with future encryption types) will at least block the very unsafe DES variants, or better use 0x18 (AES128, AES256) or 0x38 (same but including future types) for acceptable levels of security, depending on your companies’ policies. This last setting however requires AES settings to be enabled on your user accounts! Make sure you verify the ms-ds-SupportEncryptionTypes setting on user objects first.
Fortunately, we found out after some of the domain controllers got the update and things partially went south.
Workaround would be to allow RC4 for the user objects by change the user attribute ms-ds-SupportEncryptionTypes. When AES128 and AES256 are selected via the graphical interface, this attribute would contain a decimal value of 24 (0x18). Change it to 28 (0x1C) to also support RC4.
Remember that the workaround would decrease security, as AES is effectively no longer used because of the issue the update introduced.
Leo's blog 