Hey everyone,
I'm encountering some unusual behaviors with Kerberos and encryption types across various customer domains after we introduced Server 2025 Domain Controllers (DCs). We're a Managed Service Provider (MSP), and these issues appear in multiple domains.
We're on a single Domain Functional Level (DFL) 2016 with a Forest Functional Level (FFL) of 2016, and our setup includes two sites. The DCs are as follows:
- Site 1: DC01 (Server 2022), DC02 (Server 2025)
- Site 2: DC03 (Server 2022)
I've noticed Event ID 14 alerts from the Kerberos KDC in the System event log on DC01. These alerts indicate that no matching key was found for an account during an AS-REQ. This issue is affecting various accounts—mostly machine accounts but also some user accounts. Interestingly, the other two DCs aren't showing these alerts.
When I check event 4768 in the Security log, a couple of things catch my attention:
* The **Available Keys** show only RC4.
* The **Pre-Authentication Encryption Type** is registered as 0x17, which I believe corresponds to RC4.
According to the Microsoft Community resource I found, this could suggest the account hasn't had its password changed since the DFL was raised above 2008, or there might be a configuration issue with the Kerberos encryption type policy. However, this doesn't seem to apply to all the accounts I've investigated so far.
In this specific case, the affected machine account had its password updated shortly before the events occurred, and neither the policy nor the associated registry key is active on the device or on the DCs. The **msDS-SupportedEncryptionTypes** attribute for the machine account is set to 0x1C, indicating support for RC4, AES128-SHA96, and AES256-SHA96. This suggests that the encryption types should be available if the policy and registry settings were in place.
Furthermore, using DSInternals to check the account shows only AES keys (AES256_CTS_HMAC_SHA1_96, AES128_CTS_HMAC_SHA1_96) and DES keys (DES_CBC_MD5), but when I look on DC02 using the same 4768 event, everything appears normal with available keys listed as RC4, AES128-SHA96, and AES256-SHA96—with the Pre-Authentication Encryption Type set to 0x12.
I've spent considerable time researching Kerberos and its encryption types, but I'm still not sure why this particular behavior is occurring. Any insights or guidance you have would be greatly appreciated! If you need more details, just ask.
P.S. The krbtgt password has been changed multiple times since raising the DFL above 2008, with the last change occurring a few weeks ago.
1 Answer
If your customer has been around for a while, check when the krbtgt account's password was last updated. If it was created with older Windows versions and hasn't had its password changed since then, it might lack the AES128 and 256 keys. This issue also occurs with service accounts or users that have the 'password never expires' option without a change since 2008 R2 or later.
However, if this only started after bringing in a Server 2025 DC, you might want to consider demoting it and sticking with the 2022 servers for now while you open a ticket with Microsoft about the issues.
Thanks for your suggestion! I did overlook the krbtgt password; it was actually changed recently. The problems only began when we introduced the 2025 DC. Affected clients are still issuing a new AS-REQ to the 2025 DC, which seems to have access to AES keys, but no one has reported significant issues yet.