Microsoft
MicrosoftHi Jerry and thanks for the great article. This has helped us alot in reducing the number of authentications made with RC4.
Now we dont have any Event 4768's with "Ticket encryption Type = 0x17", we only have ones with 0x12.
But although we have no events with with encryption type 0x17, we have some accounts generating 4768 with Available keys = RC4 (and Pre Authentication EncryptionTypes = 0x17). I think this means the accounts has not reset passwords (twice) since implementation of AES in the domain.
Will updating the value HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\KDC\DefaultDomainSupportedEncTypes on our domain controllers cause issues for the accounts with available keys = RC4?
Even though it says available keys = RC4 on these accounts, the ticket encryption type is 0x12.
Best regards / Joakim
MicrosoftHi Jocke - You should continue to see RC4 as an available key on accounts. Keep in mind RC4 key = NTLM hash. If the account did not have an RC4 key it could not fall back to NTLM if necessary. For now the password resets simply ensure that AES keys are generated. When you see Pre-Authentication using RC4 that is likely either a legacy device that does not support AES, a current device that has AES disabled by policy (Network security: Configure encryption types allowed for Kerberos) or a keytab file that only has an RC4 key. When you see pre-auth using RC the "Advertized Etypes" field should only show RC4. If you see the client advertise AES support but uses RC4 for pre-auth I would verify the account has AES keys.
Hi Jerry, thanks for the answer, did not get a notification so i just saw it.
So in below example, as available keys are only "RC4", this account's authentication will fail if i set DefaultDomainSupportedEncTypes to 0x38 on the domain controllers?
This account is not configured with keytab and is not used on a legacy device, its used on a windows 2019 server which allows AES256.
Its an old account and the password has been reset once after AES256 came into domain, but i think it might have to do something with passwordhistory? That the old RC4 password hash is still stored in the password history attribute. Can that be possible?
MicrosoftJocke - Reseting the password a second time is the first thing I would try. It is not well documented but having at least one AES key in the password history can make a difference. Give that a try and let me know if that allowed the account to begin showing AES keys in the Available Key field.
Hi,
I can confirm after resetting the password twice for these accounts, the acounts are getting AES256 as available keys.
Thanks!
BR//Jocke
