To continually increase the information security of on-premises Domain Controllers, Microsoft provides new functionality to Windows Server and Active Directory. Sometimes, the new security measures affect the efforts of admins to get their Active Directory environments to a safer state, ahead of the curve. In this knowledgebase article, I’ll discuss such a measure.
The situation
You run Active Directory with Domain Controllers on one or more of the below Windows Server Operating Systems:
- Windows Server 2008
- Windows Server 2008 R2
- Windows Server 2012
- Windows Server 2012 R2
- Windows Server 2016
- Windows Server 2019
- Windows Server 2022
You have configured domain-joined systems and objects in Active Directory to no longer allow RC4_HMAC_MD5 for Kerberos session key encryption.
The issue
Suddenly, you start experiencing errors in the System log of your Domain Controllers. These errors have Event ID 14 and source Kerberos-Key-Distribution-Center:
While processing an AS request for target service krbtgt, the account … did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested etypes were: …. The accounts available etypes were 23 18 17. Changing or resetting the password of … will generate a proper key.
End users in the environment and/or group Managed Service Accounts (gMSAs) experience issues signing in. They are requested to lock the device and sign in with the latest password or smart card. Any services that run with the credentials of domain user objects and/or gMSAs experience issues.
The cause
These errors occur because the November 2022 or newer cumulative updates for Windows Server are installed on Domain Controllers. These updates address the vulnerability known as CVE-2022-37966 and introduce changes to the Kerberos protocol. These changes are described in KB5021131.
Since the November 2022 updates, the Advanced Encryption Standard (AES) is configured as the default encryption type for session keys on user objects that are not marked with a default encryption type. However, for objects that are configured with an encryption type, the RC4 bit being used as a signal of whether it should use a preferred cipher list or a legacy interoperability list in a specific section of code in Windows.
Only organizations that have configured domain-joined systems and objects in Active Directory to no longer use RC4 for Kerberos encryption, run into the above issues.
The absence of RC4 in the list of supported Kerberos key encryption types in specifically configured situations causes the issues, as the domain-joined device mistakenly thinks it does not have a valid Kerberos ticket encryption type available.
The solution
To solve these issues, perform the following steps:
Step 1
Uninstall the most recent Windows update from the Domain Controllers.
While this is not a recommended practice, it allows communications again. As the solution lies in communications with Active Directory and through Group Policy, these communications need to be restored first.
Step 2
Locate any Group Policy objects (GPOs) that configure the Network Security: Configure encryption types allowed for Kerberos Group Policy setting. Remove this setting from the scope of the devices that are affected by the issues, or change the setting to Not Configured as advised by Microsoft.
Push the new configuration from Group Policy Management (gpmc.msc) to affected domain-joined devices, restart these devices or allow up to 120 minutes to have the new Group Policy settings be applied through background Group Policy refreshes.
Step 3
Locate any object in Active Directory that is configured with values for the msDS-supportedEncryptionTypes attribute:
Get-ADObject -Filter "msDS-supportedEncryptionTypes -bor 0x18 -and -not msDS-supportedEncryptionTypes -bor 0x7"
Depending on the security requirements within your organization, configure the supported Kerberos key encryption types to either the ones that were mentioned in the event, or remove any specifically configured attributes that:
- Filter out RC4_HMAC_MD5 encryption type (bit 3, represented by the decimal value 4 or the hexadecimal value 0x4)
and - Do not filter in the AES256_HMAC_SHA1_SK encryption type that is introduced with the November 2022 updates ((bit 6, represented by the decimal value 32 or the hexadecimal value 0x20).
The msDS-supportedEncryptionTypes attribute is provided in HEX format, instead of decimal format. Common values represent the following selections:
Step 4
Reinstall the most recent Windows update from the Domain Controllers.
Hi @all!
We've been hit with exactly the same problem – RC4 disabled, NTLM disabled. We've rotated krbtgt passwords and the only solution I've managed to find to get things working again (we don't want to uninstall the update, or enable RC4) is to unjoin the device from AD, then re-join it. It's not a great way for large infrastructures, but if someone bumps into this, maybe this will help someone.
Where is the documentation for AES256_HMAC_SHA1_SK?
What is the ApplyDefaultDomainPolicy=0 registry key that seems to be the easiest workaround to get logins working after KB5021131?
While this acrticle was very helpful, as it explains the background of the problem (thanks a lot), it might not give the easiest solution for some cases.
Some weeks ago, I experimented with several SSO/Keytab scenarios. For this purpose, I had activated the "supports Kerberos-AES-256-Bit-encryption" option in my AD account. Disabling this, solved the above error for me.
These options in the Active Directory management tools result in values for the msDS-SupportedEncryptionTypes attributes for user objects.
Hi Sander,
Are you saying that we should not be using the 'Network Security: Configure encryption types allowed for Kerberos Group Policy setting.' anywhere in our environment?
With the November 2022 updates, Microsoft disables RC4-HMAC_MD5 as a possible encryption algorithm for Kerberos session keys. The platform settings now conform with what organizations have been configuring that setting with when they harden their environments. From that perspective it no longer makes sense to configure the setting.
Hello Sander,
Great article that helped us sorting this mess out without uninstalling the update.
After mitigation, only our ADFS service account was issuing RC4 Kerberos Tickets, we had to set attribute msDS-SupportedEncryptionTypes to 0x1c (AES256, AES128 and RC4) to have ADFS service account issuing AES256 tickets again.
The solution remains unclear, because if accounts have attribute 24, we always have error 14
While processing an AS request for target service krbtgt, the account XXXX did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 1). The requested types: 18 23 -133 -128 24 -135. The accounts available etypes: 23 18 17. Changing or resetting the password of XXXXX will generate a proper key.
I disabled Kerberos AES128 and 256 support, then reset the password of the users concerned
Actually, the cause remains unclear.
After you've cleared the msDS-SupportedEncryptionTypes attribute (in your case by clearing the two options) for the account, a suitable encryption type should be negotiated for the Kerberos session key for the person.
There is no need to reset the password for the user, as AES-encrypted session keys are still supported. The encryption negotiation is merely mismatched, as indicated by the error.
Our computers have the value 28 for the msDS-SupportedEncryptionTypes attribute.
What's the solution, pending any Microsoft new patch?
Hi Chris,
Computer objects can have values for the msDS-SupportedEncryptionTypes attribute due to two reasons:
You can remedy the first cause by moving the computer object(s) out of scope of the Group Policy object(s) configuring the setting, by disabling the Group Policy object(s) configuring the setting, or by configuring the specific setting as 'Not defined' in Group Policy object(s) targeting the computer object(s).
When no Group Policy applies that configures the setting, you can clear the sDS-SupportedEncryptionTypes attribute on the computer object(s). You may need to confer with any management, security, monitoring and/or auditing solution vendors for your environment to see if they need the particular setting specified.
Is there any patch underway which is going to resolve this issue ?
Yes, apparently.
An Out-of-band update is now available to address the issue.
Here's how to install these updates, per Windows Server version on your Domain Controllers.
Why is it neccessary to uninstall the updates – reconfigure the msDS-supportedEncryptionTypes and install the updates again?
What types of encryption are allowed if this value is not set?
Note:
This blogpost was written before the out-of-band updates were released. Since then, I advice to manually download these and install them instead of or after the November 2022 updates. The mismatch in supported encryption algorithms that caused the events is solved with these updates.
Just hit this problem. Thanks for the very helpful article. It saved our neck! I used the powershell command you provided to give a list of computers, and it listed all of them! Fortunately all that was required to fix the problem was to to edit the attribute on each one and add +4. Then everything works as expected. I didnt need to uninstall the update.
Really good article – Thanks!
Also hit with this problem, we're using a CIS compliant GPO Policy, and combined with this update caused major headaches. Solution was to remove the policy and apply the out-of-band patch update.
Yes, really good article. We are using CIS compliant GPO policy too and Kerberos didn't like it. Our solution was to uninstall update from domain controllers, fix things and then re-install. Thanks
I noticed that certain AD User accounts were being flagged in event id 14. I had a look at their AD user accounts and sure enough; there's a tick box that enables 128 & 256 bit Kerberos encryption. I unticked these boxes for the affected user accounts and the event was no longer logged in event viewer.
I have one user with the Error 14, no PCs. All domain PCs have values for the encryption setting to allow only AES 128/256. Resetting this user's password did not fix it.