Kerberos – How to Enable Kerberos Authentication with Specific User When Disabling RC4_HMAC_MD5

active-directorykerberosntlmSecurity

I have a problem and I hope some of you stumbled on the same problem and solved it.

I have two accounts on a specific domain (let's say account A and account B).
When I have RC4_HMAC_MD5 encryption type enabled, both accounts can communicate with kerberos to a specific website (on the same domain, same endpoint, windows server 2012 R2). They communicate with the server from the same computer (windows 10).
When I disable RC4_HMAC_MD5, only account A can communicate with kerberos, account B fallback on NTLM every time.

I've quickly looked into the account options on the AD server, but both accounts have the checkbox "This account supports Kerberos AES 128 bit encryption" UNCHECKED.

They are members of different groups, but I don't think it could prevent account B from using Kerberos, as account B is using Kerberos when RC4_HMAC_MD5 is active.

Does anybody have an idea on the way to look for the solution?
Where can I start?

Best Answer

Change account B's password. This will derive new Kerberos keys for that account, and if the change was done on a non-ancient DC, it will result in AES keys being stored (alongside the rest).

Then log off and log on again, try to visit the webapp, and use klist to check whether you got tickets for that service that are using AES for both the service key and the session key.

It sounds like account B had its last password change done very long ago, at a time when your KDCs only supported RC4 but not anything newer. Kerberos keys for an account are derived directly from its password – e.g. the RC4 key is literally the NT MD4 hash, whereas AES keys are PBKDF2 hashes – meaning, it is not possible to for Windows to "upgrade" them as it doesn't know the original password.

Getting rid of RC4 therefore requires changing the 'krbtgt' password, changing all user accounts' passwords, and even changing all service accounts' passwords (and re-issuing new keytabs for those services that use a keytab) so that all of them would have AES keys available.

I've quickly looked into the account options on the AD server, but both accounts have the checkbox "This account supports Kerberos AES 128 bit encryption" UNCHECKED.

This option is only relevant when the account is being used as a service (i.e. another account is requesting tickets for SPNs belonging to this account), as the KDC needs to know what tickets the actual service application is capable of receiving. (The KDC doesn't communicate with the service, so it has no other way to know whether the service can understand AES tickets or not.)

When the account is being used as a client, the option is irrelevant because the client system directly tells the KDC what encryption types it's capable of using (as part of the AS-REQ). And of course the KDC already knows what keys it has stored for that user.

So it should be checked for the service account corresponding to the web app, if there is one, but generally not required for normal user accounts.

Related Topic