NTLM vs KERBEROS

NTLM vs KERBEROS

(WWW)

We can interpret this post has the three W`s, one for each chapter.

We will go through the basics of NTLM and Kerberos. What’s the main differences between them, how does the flow work, and how can we identify which protocol is being used.

So, without further ado. Here is the story…

Chapter 1


The What:

What is NTLM?

NTLM is an authentication protocol. It was the default protocol used in old windows versions, but it’s still used today. If for any reason Kerberos fails, NTLM will be used instead.

NTLM has a challenge/response mechanism.

Here is how the NTLM flow works:

1 - A user accesses a client computer and provides a domain name, user name, and a password.
The client computes a cryptographic hash of the password and discards the actual password. The client sends the user name to the server (in plaintext).

2 - The server generates a 16-byte random number, called a challenge, and sends it back to the client.

3 - The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.

4 - The server sends the following three items to the domain controller:
- User Name
- Challenge sent to the client
- Response received from the client

5 - The domain controller uses the user name to retrieve the hash of the user's password. It compares the encrypted challenge with the response by the client (in step 4). If they are identical, authentication is successful, and the domain controller notifies the server.

6 - The server then sends the appropriated response back to the client.

What is Kerberos?

Kerberos is an authentication protocol. It’s the default authentication protocol on Windows versions above W2k, replacing the NTLM authentication protocol.

Here is how the Kerberos flow works:

1 - A user login to the client machine. The client does a plaintext request (TGT). The message contains: (ID of the user; ID of the requested service (TGT); The Client Net address (IP); validation lifetime)

2 - The Authentication Server will check if the user exists in the KDC database.
If the user is found, it will randomly generate a key (session key) for use between the user and the Ticket Granting Server (TGS).
The Authentication Server will then send two messages back to the client:
- One is encrypted with the TGS secret key.
- One is encrypted with the Client secret key.

NOTE:
The TGS Session Key is the shared key between the client and the TGS.
The Client secret key is the hash of the user credentials (username+password).

3 - The client decrypts the key and can logon, caching it locally. It also stores the encrypted TGT in his cache.
When accessing a network resource, the client sends a request to the TGS with the resource name he wants to access, the user ID/timestamp and the cached TGT.

4 - The TGS decrypts the user information and provides a service ticket and a service session key for accessing the service and sends it back to the Client once encrypted.

5 - The client sends the request to the server (encrypted with the service ticket and the session-key)

6 - The server decrypts the request and if its genuine, it provides service access.

Chapter 2

The When:

How can we identify when we are using NTLM or Kerberos?

We can confirm the authentication being used by simple collecting a fiddler.

In the fiddler, we can see the requests being made in the Inspectors/Headers:

Kerberos:

NTLM:

If the request starts with Kerberos and fails, NTLM will be used instead. We can see the reply in the Headers as well:

What are the Kerberos dependencies?

Both the client and the server need to be running W2k or latter versions and be on the same, or trusted domain.

A SPN needs to exist in the AD for the domain account in use to run the service in which the client is authenticating.

Chapter 3


The Why:


NTLMv1 hashes could be cracked in seconds with today’s computing since
they are always the same length and are not salted.

NTLMv2 is a little better, since it variable length and salted hash, but not that much better. Even though hash it`s salted before it`s sent, it`s saved unsalted in a machine’s memory.
And off course, when we talk about NTLM, we talk about a challenge/response
mechanism, which exposes its password to offline cracking when responding to the challenge.

Kerberos provides several advantages over NTLM:
- More secure: No password stored locally or sent over the net.
- Best performance:
improved performance over NTLM authentication.
- Delegation support:
Servers can impersonate clients and use the client's security context to access a resource.
- Simpler trust management: Avoids the need to have p2p trust relationships on multiple domains environment.

- Supports MFA (Multi Factor Authentication)

The End

Very helpful
Very helpful.  It would be useful to understand the role of AD in the Kerberos example, because it doesn't appear to play a part.  Being a directory service, I am assuming it is storing *something* relevant to the Kerberos interactions, but am I wrong?  I'm aware that Kerberos itself (as an OS agnostic protocol) has no need of AD specifically, but does it need some form of directory service?

Hello ChaoticMike_1963,
Take a look at this post:
https://blogs.technet.microsoft.com/askds/2008/03/06/kerberos-for-the-busy-admin/
Its very well written and it answers your questions.
Thanks.

//Nuno

Very helpful

Thanks

 
 

Forum Article Info


Last updated November 24, 2020 Views 36,215 Applies to: