2
$\begingroup$

I know that in Active Directory environments passwords are stored in the form of hashes depending on encryption types used in the environment.

I understand also that when using AES as a symmetric encryption type, the user password goes through PKDF2 first which generates a key derived from the password, salt included.

Now my question is, when does AES come into play here? We get the key but what do we do with said key afterwards? What is it sent to the domain controller for verification? How does the domain controller before hand get the AES key to compare it with what the client sends?

If there is a different randomly generated AES key to use to encrpyt the hashed password, in what moment is it created?

$\endgroup$

1 Answer 1

0
$\begingroup$

I know that in Active Directory environments passwords are stored in the form of hashes depending on encryption types used in the environment.

Yes correct.


I understand also that when using AES as a symmetric encryption type, the user password goes through PKDF2 first which generates a key derived from the password, salt included.

Yes, this is true for authentication using a Kerberos AS. password is first converted using a password hash (a PBKDF) followed by a KDF. In the case of AES the password hash is PBKDF2 and the KDF (simply called the DK) is the same as for (3)DES. So the final key calculated using these two steps is what is stored by AD for the Kerberos AS.

The operations are specified in RFC 3962 section 4

tkey = random2key(PBKDF2(passphrase, salt, iter_count, keylength))
 key = DK(tkey, "kerberos")

These operations are executed on the client, but the salt and iter_count are specific to Windows. The salt is the concatenation of the domain and principal name. iter_count is simply left to the default, 4096 which should not let you feel secure.


Now my question is, when does AES come into play here? We get the key but what do we do with said key afterwards?

So the client asks for credentials to access a server (or, in the current world, a service):

The AS responds with these credentials, encrypted in the client's key. The credentials consist of a "ticket" for the server and a temporary encryption key (often called a "session key").

then the (AES) client key is used to decrypt (part of) the credentials.


What is it sent to the domain controller for verification?

You would think nothing initially but if pre-authentication is enabled then a timestamp is encrypted using the client key. This can be used to make sure that hackers cannot simply request or replay the ticket for each and every user and brute force it offline. Pre-authentication is enabled on Windows by default nowadays. Of course, if sniffed this will still allow offline brute force attacks against the user.

Generally the client will e.g. use the Domain Controller to get the group policy using the decrypted session key. Access to services and network files (SMB) can be used to check if a user is logged in.


How does the domain controller before hand get the AES key to compare it with what the client sends?

Generally it is set during account creation. It may be that the user has to replace the initial password in which case the new key is encrypted with the old key. This is part of the functionality of the Windows AD, not the Kerberos AS.

If the initial password is weak that you might want to do this in a more secure environment.

The Kerberos services used for authentication of the user to other various services, not so much account creation.


If there is a different randomly generated AES key to use to encrypt the hashed password, in what moment is it created?

I didn't see this mentioned anywhere, and the indication that sniffing attacks are possible makes me believe that no such key exists.

However, there are methods to make the encryption more secure, e.g. by wrapping the messages using CMS as described in the PKINIT protocol (RFC 4556) or - because we're talking Microsoft here - the MS-PKCA protocol, which is based on PKIX (i.e. domain specific X.509 certificates, don't forget to enable that CA service).

$\endgroup$
1
  • $\begingroup$ Warning: I was curious so this is research specific to this question, I have not implemented Kerberos or anything like that. $\endgroup$
    – Maarten Bodewes
    Dec 20, 2023 at 23:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.