This may be an important clue for something that happened recently in our environment. We configured a bunch of database service SPNs and immediately all Kerberos auth failed. Rolled it back and talked to our support provider. They said that the expected behavior was to default to AES but that for some reason our environment wasn’t honoring that. We ended up having to manually enable AES support on each service account, which is a minor pain in the ass, and since no one in the IAM team was involved in the original domain setup, no one could explain why this happened or whether there was a manual RC4/DES config lurking out there in the shadows.
replyThe RC4 encryption type correlates to the DES hash (more commonly the "NT" hash), so PingCastle has the right warning.
replyI don't think I understand you. The RC4 encryption type is msDs-supportedEncryptionTypes 4 (i.e. 0b0100). DES_CBC_CRC is 1, DES_CBC_MD5 is 2. They do not "correlate".
replyAnd regarding the NT hash: the NT hash is named after NTLM, not Kerberos. NTLM is a completely different (and much less secure) authentication mechanism. And the NT hash is not DES at all, it's MD4. You may be confusing it with the LM hash, which is indeed DES, but does not support unicode and is not common anymore.
The LM hash is disabled on domains with an LmCompatibilityLevel of 4 or above. (It's accepted, but clients shouldn't send it, on the default LmCompatibilityLevel of 3, which, by the way, unless your domain has devices from the stone age, you can safely set to 5, disabling LM and NTLMv1.) Although, if you can, you should disable NTLM on the domain altogether, because it's a much more vulnerable protocol than Kerberos.