Microsoft
Microsoft
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.
