Activer Directory Kerberos authentication process

Lindows
Lindows used Ask the Experts™
on
From what I understand, a  user's password hash is never sent between the client and DC when using kerberos in active directory.

This is my understading of the login process in kerberos.
When a user types in the password to login to the computer, it sends the username (not the password) in plaint text to the DC (KDC) and the DC (KDC) checks the username against its active directory DB and when it finds the matching username, it encrypts the session key with the user's password hash along with the TGT and sends them to the client.  And if the client is able to decrypt the session key using the user's password hash, the authentication is successful.

But how does the DC(KDC) have the users' password hashes in the first place if kerberos was used as the default authentication technology in the domain?
I thought that in kerberos, the password hashes are not sent.
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Top Expert 2013

Commented:
It doesn't need to know the hash initially, that is based on the time and the password and that is decrypted.  The password stored in active directory; not sure if you have seen this blog by the DS team

http://blogs.technet.com/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx
Kerberos for the Busy Admin

They go through the exact step by step process (6 steps)

There are two main parts of KDC (the authentication service (AS) which generates ticket granting tickets and the ticket granting service (TGS) that generates service tickets)

It can be hard to keep track off all the acronyms but they explain it in that article.

So you take the current time and date you encrypt it using your password as the hash. You then send it to the AS and it decrypts it because it knows your password and at then the AS gives you a Ticket Granting Ticket.
...by the way that is why time is so important

If you like presentations Mark Minasi gave a presentation at TechEd 2008 that is good

http://www.microsoft.com/emea/spotlight/sessionh.aspx?videoid=995
Windows Logins Revealed

Thanks

mike




Author

Commented:
Thanks for the link.  It was very informative.

I'm still confused about the dc/kdc's storage of the password hash...

What about when a user changes his password by ctrl+alt+del on his computer.  How does this newly changed password gets sent to the AD DB in a kerberos environment for storage?
 

Commented:
>>> I'm still confused about the dc/kdc's storage of the password hash...

The kerberos protocol never send the password over the network. To understand more about the Krb5 Auth Protocol which is the default. You could refer to for a basic overview:
http://support.microsoft.com/kb/217098

>>> I'm still confused about the dc/kdc's storage of the password hash...
So when the admin creates the user the kerberos keys are generated as well and stored in AD. This key gets validated when the KDC received a TGT/ ST.

>>>> How does this newly changed password gets sent to the AD DB in a kerberos environment for storage?
When the user changes the password the change password protocol which is part of the krb5 authentication is initiated. However this would talk to the password server instead of the KDC.


The authentication process is as follows:

   1.      The principal (in this example, the Client) first makes an authentication service request to the KDC for a Ticket-Granting Ticket (TGT).
   2.      The KDC responds to the Client with a TGT. This includes a key (ticket session key) and is encrypted with the Client's password.
   3.      The Client uses its new TGT to request a Ticket-Granting Service (TGS) ticket in order to access the other principal (in this example, the Server).
   4.      The KDC responds to the Client by issuing a TGS ticket to the Client to access a specific resource on the Server. Note that here again a session key is generated, and two copies are made. One copy is intended for the application server and is encrypted with the application server's key (the ticket), and the other copy is sent to the user, encrypted with the session key from the AS exchange.
   5.    The Client presents the TGS as a request to the Server.
   6.     The Server authenticates the Client by acknowledging the TGS. If mutual authentication is specified, the Client reciprocates by authenticating the Server as well. Thus, the knowledge of this shared session key between the user and the service provides mutual authentication. As long as both parties demonstrate that they know this shared key (for example, by generating a random number on the Client, sending it encrypted with the session key, and expecting that number + 1 back from the Server), then mutual authentication has occurred.

Let me know if you need more help on this.
Acronis in Gartner 2019 MQ for datacenter backup

It is an honor to be featured in Gartner 2019 Magic Quadrant for Datacenter Backup and Recovery Solutions. Gartner’s MQ sets a high standard and earning a place on their grid is a great affirmation that Acronis is delivering on our mission to protect all data, apps, and systems.

Commented:
Hi,

Let me try to help you understand it a little better:

1. Authentication Request (KRB_AS_REQ): Now, this contains client's current time encrypted with User's Password Hash (it is called authenticator). So, the very first step that the client initiates is to create an 'authenticator'.

(   ( Client's Tiime) X Users Password Hash) = Authenticator.

= Now the authenticator is sent along with the UPN of the user which is being authenticated.

2. Now, DC actually sees the UPN, searches it in AD, and gets the Password.
3. Now DC again applies the encryption alogorithm (I think either MD5 or RC4) to generate the passowrd hash.
4. It applies the HASH on the authenticator to get the time out of authenticator.
5. If it can decrypt, the User that sent the request, knows the password... hence is a valid user.
6. Now if the time is in 5 minutes range, the machine is also valid.
7. The user is authenticated.

Then the other processes start.

Hence it is not that the password hash is not sent. It is and the KDC knows it as the passwords are stored in AD and KDC know the RC4 and MD5 algorithms.

Regards,

Arun.

Author

Commented:
Thanks guys for the detailed explanations!  I'm almost getting it!  :)

So when a user does ctrl+alt+del to change his password or when you as a domain admin create a new user, is the new  password sent to the DC over the wire?





 


 

Commented:
>>> 3. Now DC again applies the encryption alogorithm (I think either MD5 or RC4) to generate the passowrd hash.

I remember looking up the key type of the krb5 packets - for w2k its only DES and for w2k3 / w2k8 it should be DES3 / RC4.

Commented:
>>> So when a user does ctrl+alt+del to change his password or when you as a domain admin create a new user, is the new  password sent to the DC over the wire?

The password (users key which is deriverd from the users password) is never sent across the wire, but the KDC sends session key after receiving and validating a AS_REQ from user (validated the encrypted time stamp and generate a new session key which is encrypted with the user's key before sending it the client/user). The user receives the AS_RES -> which consists of the session key (encrypted with the user password/key)+TGT. So this way your password/ the users key never travells over the wire. the only thing that travells on the wire are fleeting and short lived session keys.  

Commented:
Hi Askb,

Thanks for that information: I was confused between DES or RC4 but here is what I got in an article:

A user key is derived from a password. After it receives a data structure with the user's logon data, the LSA converts the plaintext password to a cryptographic key by passing the text of the password through a cryptographic function. (All implementations of the Kerberos version 5 authentication protocol must support DES-CBC-MD5. Other algorithms are permissible.) The result of the cryptographic function is the user key.

But you said that USer Key is not set over the wire, I would not agree with that... Whenever a TGT is requested, the user key is sent to the DC. See this:

The LSA saves the user key in the user credentials cache, where it can be retrieved when needed for TGT renewal or for NTLM authentication to servers that are not capable of Kerberos authentication.

Both of these statements are taken from this article:
http://technet.microsoft.com/en-us/library/cc772815(WS.10).aspx

Regards,

Arun.

Commented:
Hi Arun,

>>> A user key is derived from a password. After it receives a data structure with the user's logon >>>data, the LSA converts the plaintext password to a cryptographic key by passing the text of the >>>password through a cryptographic function. (All implementations of the Kerberos version 5 >>>authentication protocol must support DES-CBC-MD5. Other algorithms are permissible.) The result of >>>the cryptographic function is the user key.

The above means that the users key is deriverd from a password. Here a function basically converts a passphrase into a cryptographic key {DES-CBC-CRC}. What is received from the KDC ("data structure") would basically be as follows:   AS_RES = { {session key} Encrypted with User Key + {TGT}  Ecrytpted with TGS key }. Then the client verifies the AS_RES obtaining his key (deriverd from the password), to retrive the session key.  So here the TGT is essentially = users credentials, which contains Session key and other details which are required to obtain the service ticket later on and but never the user's key.
 
Therefore, the "data structure" never contains the key in plain or encrypted - this is essence of trusted third party authentication and how kerberos authentication protocol works.
The session key is later used to encrypt and authenticator which is sent to KDC as a part of TGS_REQ.

>>>The LSA saves the user key in the user credentials cache, where it can be retrieved when needed >>>for TGT renewal or for NTLM authentication to servers that are not capable of Kerberos >>>authentication.

The above means that LSA stores the AS_REQ = TGT+Sessoin_key in the credentail cache, so every time the user request for a new service sending a TGS_REQ, the user would not have to enter his password again, unless the TGT is valid (generally for 8 hours).

Its easy to understand the details if you could do a packet trace on AD login sequence using tools like kinit and using wireshark for the trace.

I would also suggest going to http://en.wikipedia.org/wiki/Needham-Schroeder_protocol which is primitive version of the krb5. This mainly aims at establishing a session key between 2 parties (client and server) without compromising the security of sending the password / users key over the wire.

Hope this helps. PS do let me know if you need more assistance.
 
Thanks

Commented:
Hello AskB,

Well, you have talked about AS_RES and what my point was that the Password Hash is sent over the wire to the DC/AS with the AS_REQ.

I know that the AS_RES contains the session key and that is further used to request TGS. But I just did not echo you on your point that Password Hash is NOT sent over wire. What I understand is 'Password Hash' is sent ONCE to the AS (Authentication Server) with the AS_REQ.

Regards,

Arun.

Commented:
Please see:

1. The client sends a KRB_AS_REQ to the KDC and more specifically the Authentication Server to request a Ticket Granting Ticket (TGT).

The AS_REQ is built on the client machine using the current computer time and encrypting it with the users Password hash. There is some other information within the AS_REQ packet that includes the UPN of the Principal. This information is called “Authentication Data”
2. Once the KDC verifies the users Authentication Data, it responds back to the client with a KRB_AS_REP to the client with a TGT and session key for the TGT.

The KDC can decrypt the AS_REQ because the principal’s password hash is stored within Active Directory; it then verifies that the timestamp in the AS_REQ to make sure that the systems are within 5 minutes of time skew. This process validates that the principal authenticating knows the users account and password.
The TGT session key is used in subsequent service ticket requests.


The above text is an exract from this article:
http://blogs.technet.com/askds/archive/2008/03/06/kerberos-for-the-busy-admin.aspx

I hope this makes thie pretty much clear that the password hash is sent over the wire 'ONLY ONCE" to the AS.

Regards,

Arun.

Commented:
Arun, both the cases I have explained are the lines which you have quoted from the link.

Actually in you AS_REQ here is what happens, whether you have ore-auth enabled on not, you never send the user key on the wire, but only use it for encrypting other session key. I hope this should make it clear to you now!!!

AS_REQ:    1. The client sends a cleartext message of the user ID to the AS requesting services on behalf of the user. (Note: Neither the secret key nor the password is sent to the AS.) The AS generates the secret key by hashing the password of the user found at the database (e.g. Active Directory in Windows Server).
AS_RES   2. The AS checks to see if the client is in its database. If it is, the AS sends back the following two messages to the client:
          * Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
          * Message B: Ticket-Granting Ticket (which includes the client ID, client network address, ticket validity period, and the client/TGS session key) encrypted using the secret key of the TGS.
   3. Once the client receives messages A and B, it decrypts message A to obtain the Client/TGS Session Key. This session key is used for further communications with the TGS. (Note: The client cannot decrypt Message B, as it is encrypted using TGS's secret key.) At this point, the client has enough information to authenticate itself to the TGS.

http://en.wikipedia.org/wiki/Kerberos_(protocol) -> refer to client authentication part from wiki.
You would do some reading of the above  links to understand the mathiticatal proof of the krb5 protocol.  

Commented:
>>> I hope this makes thie pretty much clear that the password hash is sent over the wire 'ONLY ONCE" to the AS.

PS dont confuse  - "Authentication data" consists of your pre-autentication info (which is a time stamp is encrypted with users key / "password hash" ).

However, I would not depend on blogs - for accuracy of the working on the protocols, instead it would be better to looking up into an RFC 1510 (the Kerberos Protocol 1510) -> http://www.faqs.org/rfcs/rfc1510.html 

From the RFC link read about  "pre-authentication data" or "padata".

Author

Commented:
The discussion has gotten a little complicated for me :)...
I hope I'm not starting to irritate you for asking the same question over and over again.

>> The AS generates the secret key by hashing the password of the user found at the database (e.g. Active Directory in Windows Server).

How does the AS/DC have the user's password on the database in the first place if the user's password was never sent across the wire?

For example, if the user jsmith's password was Bye123 and he did a ctrl+alt+del to change his password to Hello321 on his computer, how does AS/DC know that jsmith's password is Hello321 if it never gets sent across the wire?
Commented:
>>>How does the AS/DC have the user's password on the database in the first place if the user's >>>password was never sent across the wire?
dome from MMC (AD Admin Console) when you create a user by default the keys are generated for the user in AD.

>>>For example, if the user jsmith's password was Bye123 and he did a ctrl+alt+del to change his password to Hello321 on his computer, how does AS/DC know that jsmith's password is Hello321 if it never gets sent across the wire?

When the user does a ctl+alt+del to log in for the first time, then 'change password protocol' gets initiated which talks AD server. (Here is the draft for this -> http://www.ietf.org/rfc/rfc3244.txt ), if you are interested in the details.

I would suggest first to understand the working of kerberos before reading the change password draft,.

IMP read section 2 AIMS from here http://www.kerberos.org/software/tutorial.html

2  Aims

Before describing the elements that make up the Kerberos authentication system and looking at its operation, some of the aims the protocol wishes to achieve are listed below:

    * The user's password must never travel over the network;
    * The user's password must never be stored in any form on the client machine: it must be immediately discarded after being used;
    * The user's password should never be stored in an unencrypted form even in the authentication server database;
    * The user is asked to enter a password only once per work session. Therefore users can transparently access all the services they are authorized for without having to re-enter the password during this session. This characteristic is known as Single Sign-On;
    * Authentication information management is centralized and resides on the authentication server. The application servers must not contain the authentication information for their users. This is essential for obtaining the following results:
         1. The administrator can disable the account of any user by acting in a single location without having to act on the several application servers providing the various services;
         2. When a user changes its password, it is changed for all services at the same time;
         3. There is no redundancy of authentication information which would otherwise have to be safeguarded in various places;
    * Not only do the users have to demonstrate that they are who they say, but, when requested, the application servers must prove their authenticity to the client as well. This characteristic is known as Mutual authentication;
    * Following the completion of authentication and authorization, the client and server must be able to establish an encrypted connection, if required. For this purpose, Kerberos provides support for the generation and exchange of an encryption key to be used to encrypt data.

Commented:
Oops! I think I got where I was wrong... I apologoze for missing such a simple fact...
So here it is, (correct me again if I am wrong!)

[    (time encrypted with user key or password hash) + UPN + some other arguments ] = AS_REQ.  

So the result of Time's encryption with password hash will actually be far different from the actual password hash.

Thank you so much Askb for clearing this doubt... I will go through the RFC once again...

Regards,

Arun.

Commented:
>>> [    (time encrypted with user key or password hash) + UPN + some other arguments ] = AS_REQ.  

correct

>>> So the result of Time's encryption with password hash will actually be far different from the actual password hash.

One of the things about Kerberos is its diff to understand all the details for the initially! !

I am glad you know it know.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial