In Active Directory (AD), two authentication protocols can be used, which are Kerberos and NTLM. At present, Kerberos is the default authentication protocol in Windows. NTLM is an authentication protocol and was the default protocol used in older versions of windows. The NTLM protocol is still used today and is supported in Windows Server. Here are some articles I have written relating to Active Directory; How to set up a Domain Controller, what is Active Directory Forest, Trees, Domain and Sites, how to install and configure Active Directory Certificate Services, how to set up Azure AD Tenant and methods for integrating Azure Active Directory with on-premise Active Directory.
Kerberos was developed at the Massachusetts Institute of Technology and is currently the most widely used technology for Authentication and Authorization in computer networks.
Active Directory Authentication methods
- NT LAN Manager (NTLM): This challenge-response authentication protocol was used before Kerberos became available. However, an organization may still have servers that use NTLM.
- Kerberos: Kerberos is an authentication protocol. It’s the default authentication protocol on Windows versions since Windows 2000 replacing the NTLM authentication protocol. This protocol works on the basis of tickets and requires the presence of a trusted party. See this link for more information.
Before digging deep into the authentication process of both NTLM and Kerberos, the table below gives a comparison of both protocols.
The below diagram is how the Kerberos authentication flow works. The three heads of Kerberos are represented in the protocol by a client seeking authentication, a server the client wants to access, and the key distribution center (KDC).
The KDC is the trusted third party that authenticates users and is the domain controller that AD is running on. Here are the step involved in Kerberos authentication: Both diagram 1 and diagram 2 should be able to drive down the points 🙂
Note: Diagram 2 also shows the Kerberos Authentication steps as diagram 1
1: A user logs in to the client machine.
The client does a plaintext request (TGT). The message contains: (ID of the user; the 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’s 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 it is genuine, it provides service access.
Here’s a step-by-step description of how NTLM authentication work: Due to the recent vulnerability discovered in ZOOM, please take a look at how to mitigate the issue. Here are the steps used in preventing windows from automatically sending your credentials to a remote server (when accessing a share). For more information, kindly see how to prevent NTLM credentials from being sent to a remote server.
1: A user accesses a client computer and provides a domain name, user name, and 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: Moreover, 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 appropriate response back to the client.
Furthermore, I hope you found this blog post helpful. However, Please let me know in the comment session if you have any questions.
