I was about to suggest employing PingCastle to audit domains for weak default configurations such as these, but apparently, PingCastle still doesn't complain about RC4 enabled Kerberos accounts - only about DES. So now is a good opportunity to check any domains you are responsible for by hand.
Note that since the 2022 update KB5019964, AES is the default for all AD accounts that did not have the administrator explicitly set a different encryption scheme. However, administrators may have done that on your domain in the past, because back in the day, the default encryption scheme was not even RC4, but DES, which is even worse. Some people therefore set everything to RC4 by hand, before AES was introduced as an option.
The allowed encryption types are set via the msDs-supportedEncryptionTypes attribute on each individual AD account. This property is a 32 bit bitmask, where 8 is AES128, 16 is AES256, and any other bits set are garbage encryption schemes. However, if the attribute is set to 0, the account reverts to the default, which ever since the aforementioned patch has been 24 (AES128|AES256).
Anyway, the following Powershell (run with elevated permissions on the domain!) lists you all insecure user accounts:
Get-ADUser -Filter 'msDs-supportedEncryptionTypes -ne 0 -and msDs-supportedEncryptionTypes -ne 8 -and msDs-supportedEncryptionTypes -ne 16 -and msDs-supportedEncryptionTypes -ne 24'
Get-ADComputer -Filter 'msDs-supportedEncryptionTypes -ne 0 -and msDs-supportedEncryptionTypes -ne 8 -and msDs-supportedEncryptionTypes -ne 16 -and msDs-supportedEncryptionTypes -ne 24'
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.
The RC4 encryption type correlates to the DES hash (more commonly the "NT" hash), so PingCastle has the right warning.
I 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".
And 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.