How NTLM Authentication Works

Client

Domain Controller

Client

Domain Controller

User Password Hash + User Password Hash

Security

Accounts

Database

User Password Hash + User Password Hash a

User Password Hash

Security

Accounts

Database

User Password Hash

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ

illegal for non-trainer use

Introduction

Authentication process

As mentioned earlier, NTLM includes three methods of challenge-response authentication: LM, NTLMvl, and NTLMv2. The authentication process for all the methods is the same, but they differ in the level of encryption.

The following steps demonstrate the flow of events that occur when a client authenticates to a domain controller using any of the NTLM protocols. The client and server negotiate an authentication protocol. This is accomplished through the Microsoft negotiate Security Support Provider (SSP).

1. The client sends the user name and domain name to the domain controller.

2. The domain controller generates a 16-byte random character string called a nonce.

3. The client encrypts the nonce with a hash of the user password and sends it back to the domain controller.

4. The domain controller retrieves the hash of the user password from the security account database.

5. The domain controller uses the hash value retrieved from the security account database to encrypt the nonce. The value is compared to the value received from the client. If the values match, the client is authenticated.

How Kerberos Authentication Works

User Name

User Name

Target Server

Target Server

The KDC creates a pair of tickets, one for the client and one for the server the client wants to access resources on. Each ticket contains the name of the user requesting the service, the recipient of the request, a timestamp that declares when the ticket was created, and a time duration that says how long the tickets are valid. Both tickets also contain a new key (KAB).

*****************************illegal for non-trainer use ****************************** Introduction The three components of Kerberos are:

■ The client requesting services or authentication.

■ The server hosting the services requested by the client.

■ A computer that is trusted by the client and server. (In this case a Windows Server 2003 domain controller running the KDC service.)

Key Distribution Center The Key Distribution Center (KDC) maintains a database with account information for all security principals in the domain. The KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long term key. The long term key is derived from a user's logon password.

Note To reduce the number of times a user must authenticate to a KDC, Kerberos clients implement ticket caching. For more information about the ticket caching mechanism, see Kerberos.doc under Additional Reading on the Web page on the Student Materials compact disc.

Kerberos authentication In a Kerberos environment, the authentication process begins at logon. The pr°cess following steps describe the Kerberos authentication process.

1. When a user enters a user name and password, the computer sends the user name to the KDC. The KDC contains a master database of unique long-term keys for every principal in its realm.

2. The KDC looks up the user's master key (KA), which is based on the user's password. The KDC then creates two items: a session key (SA) to share with the user and a Ticket-Granting Ticket (TGT). The TGT includes a second copy of the SA, the user name, and an expiration time. The KDC encrypts this ticket using its own master key (KKDC), which only the KDC knows.

Note Kerberos implements secret key cryptography, which is different from public key cryptography in that it does not use a public and private key pair.

3. The client computer receives the information from KDC and runs the user's password through a one-way hashing function, which converts the password into the user's KA. The client computer now has a session key and a TGT so that it can securely communicate with the KDC. The client is now authenticated to the domain and is ready to access other resources in the domain by using the Kerberos protocol.

Note When a client receives the session key and TGT from the server, it stores that information securely in volatile memory and not on the hard disk. Storing the information in the volatile memory and not on the hard disk makes the information more secure.

4. When a Kerberos client needs to access resources on a server that is a member of the same domain, it contacts the KDC. The client will present its TGT and a timestamp encrypted with the session key that is already shared with the KDC. The KDC decrypts the TGT using its KKDC. The TGT contains the user name and a copy of the SA. The KDC uses the SA to decrypt the timestamp. The KDC can confirm that this request actually comes from the user because only the user can use the SA.

5. Next, the KDC creates a pair of tickets, one for the client and one for the server on which the client needs to access resources. Each ticket contains the name of the user requesting the service, the recipient of the request, a timestamp that declares when the ticket was created, and a time duration that says how long the tickets are valid. Both tickets also contain a new key (KAB) that will be shared between the client and the server so they can securely communicate.

6. The KDC takes the server's ticket and encrypts it using the server master key (KB). Then the KDC nests the server's ticket inside the client's ticket, which also contains the KAB. The KDC encrypts the whole thing using the session key that it shares with the user from the logon process. The KDC then sends all the information to the user.

7. When the user receives the ticket, the user decrypts it using the SA. This exposes the KAB to the client and also exposes the ticket for server. The user cannot read the server's ticket. The user will encrypt the timestamp by using the KAB and send the timestamp and the server's ticket to the server on which the client wants to access resources. When it receives these two items, the server first decrypts its own ticket by using its KB. This permits access to the KAB, which can then decrypt the timestamp from the client.

Now both the client and the server have the KAB. The server can be sure that the client has truthfully identified itself because the client used the KAB to encrypt the timestamp. If it is necessary for the server to respond to the user, the server will use the KAB. The client will know that the server has truthfully identified itself because the server had to use its KB to get the KAB.

Was this article helpful?

+3 0
Outsource Explosion

Outsource Explosion

There will come a day in your business (if it hasn't already arrived) when you realise that you only have two hands and 24 hours in a day. What I mean is you can't do everything that your business needs yourself. If you try to do everything yourself your business will at best grind to a halt, and at worst, GO UNDER. Take a look RIGHT NOW at the successful marketers around you - the millionaires, the gurus and the market leaders.

Get My Free Ebook


Responses

  • stephanie
    How to implement kerberos in windows server?
    2 years ago
  • jari
    How ntlm authentication works?
    1 year ago
  • Lindsay
    How a domain controller generates a hash?
    1 year ago
  • asmait
    Does ntlm authentication works on different networks?
    9 months ago
  • tom
    How does ntlm authentication work?
    4 months ago
  • walter yanez
    Does ntlm needs to under to a domain?
    3 months ago
  • YOLANDA
    How ntlm work between domain member server?
    3 months ago
  • elisabeth antila
    How to implement ntlm authentication?
    23 days ago

Post a comment