NTLM: Authentication is the well-known and loved challenge-response authentication mechanism, using NTLM means that you really have no special configuration issues. As Microsoft likes to say, “It just works.”

Older than Kerberos, and is for authentication as well. Can still be used as a backup to Kerberos authentication being down.

Kerberos: It’s complex ticket-based authentication mechanism that authenticates the client to the server and authenticates the server to the client. While Kerberos is more secure, it can be a bit challenging to set up properly. Win 2003 with the latest SP can be configured to use either NTLM or Kerberos. Well, besides being more secure, Kerberos has two key advantages that make it worth consideration.

Authentication for ticket based domain authentication i.e. logging into the domain. Replaced NTLM.

Kerberos is the authentication protocol that is used in Windows 2000 and above where as NTLM was used in Windows Server NT 4 ad below. As for LDAP, it is the protocol that is used with Active Directory, Novell Directory Service, and newer Unix systems.. If you have older workstations you may still need to use NTLM, but if you only have Windows Me clients or below you can disable it using Group Policy. Windows 2000 professional and above used Kerberos

LDAP: It is primarily a directory access protocol. They do different things. LDAP has a primitive authentication mechanism called “simple bind” that applications can use to verify credentials if they can’t handle other authentication protocols. It gets tricky because LDAP also includes an extensible authentication framework called SASL that allows alternate authentication protocols to be added.
Protocol to allow other programs to access the Active Directory Framework, used in VBScript extensively. Think of it as a “hole to allow you to peek inside your Active Directory Domain”.

Advantages of Kerberos: Better Security, Faster authentication, Mutual authentication, Kerberos is an open standard, Support for authentication delegation, Support for the smart card logon feature.

1. Performance – Kerberos caches information about the client after authentication. This means that it can perform better than NTLM particularly in large farm environments.
2. Delegation – Kerberos can delegate the client credentials from the front-end web server to other back-end servers like SQL Server.
   Work Flows

In Active Directory (AD), two authentication protocols can be used:

• NT LAN Manager (NTLM): This is a challenge-response authentication protocol that was used before Kerberos became available. However, an organization may still have computers that use NTLM, so it’s still supported in Windows Server.
• Kerberos: This protocol works on the basis of tickets, and requires the presence of a trusted third party.

The basics of how NTLM works

Here’s a step-by-step description of how NTLM authentication works:

• The user provides their username, password, and domain name at the interactive logon screen of a client.
• The client develops a hash of the user’s password and discards the actual password.
• The client sends the username in plain text to the server it wants to access.
• The server sends a challenge to the client. This challenge is a 16-byte random number.
• The client then sends a response to the server. This response is the challenge encrypted by the hash of the user’s password.
• The server sends the challenge, response, and username to the domain controller (DC).
• The DC retrieves the hash of the user’s password from its database, and then encrypts the challenge using it.
• The DC compares the encrypted challenge it has computed (in the above step) to the response of the client. If these two match, the user is authenticated.

NTLMv2 – A big improvement over NTLMv1

NTLMv2 is a more secure version of NTLM (discussed above). It differs from its predecessor in the following ways:

• It provides a variable length challenge instead of the 16-byte random number challenge used by NTLMv1.
• In NTLMv2, the client adds additional parameters to the server’s challenge such as the client nonce, server nonce, timestamp and username. It then encrypts this with the hash of the user’s password with the HMAC-MD5 algorithm. In contrast, in NTLMv1, the client only adds the client nonce and the server nonce to the server’s challenge. It then encrypts this with the hash of the user’s password with the relatively weak DES algorithm.

NTLMv2 gives a better defense against replay attacks and brute-force attacks. However, Kerberos is an even more secure authentication protocol because of its use of encrypted tickets.

How Kerberos works

NTLMv2 – A big improvement over NTLMv1 NTLMv2 is a more secure version of NTLM (discussed above). It differs from its predecessor in the following ways:

Here is the step-by-step process of how Kerberos works:

• The user attempts to join the network through the client’s interactive logon screen.
• The client constructs a package called an authenticator which has information about the client (username, date, and time). Except for the username, all the other information contained in the authenticator is encrypted with the user’s password.
• The client then sends the encrypted authenticator to the KDC.
• The KDC immediately knows the identity of the client that has sent the authenticator by looking at the username. The KDC will then look into its AD database for the user’s password, which is a shared secret. It then decrypts the authenticator with the password. If the KDC is able to decrypt the authenticator, it means that the identity of the client is verified.
• Once the identity of the client is verified, the KDC creates a ticket granting ticket (TGT), which is encrypted by a key that only the KDC knows.
• The KDC sends the TGT to the client. The client stores the TGT in its Kerberos tray. It can use this ticket whenever it needs to access a resource on a server on the network (within a typical time limit of eight hours).
• When the client needs to access another server, it sends the TGT to the KDC along with a request to access the resource.
• The KDC decrypts the TGT with its key. This step verifies that the client has previously authenticated itself to the KDC.
• The KDC generates a ticket for the client to access the shared resource. This ticket is encrypted by the server’s key. The KDC then sends this ticket to the client.
• The client saves this ticket in its Kerberos tray, and sends a copy of it to the server.
• The server uses its own password to decrypt the ticket.

If the server successfully decrypts the ticket, it knows that the ticket is legitimate. The server will then open the ticket and decide whether the client has the necessary permission to access the resource by looking through the access control list (ACL).