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. In this article, we shall discuss “Active Directory Authentication methods: Kerberos and NTLM”. Please see 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.
The NTLM protocol is still used today and is supported in Windows Server. Kerberos was developed at the Massachusetts Institute of Technology and is currently the most widely used technology for Authentication and Authorization in computer networks
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.
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
Kerberos Authentication Steps explained
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.
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 and
- 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.
FAQs
In NTLM authentication, the hashed user password is stored on the client, DC, and application server, making it vulnerable to tools like Mimikatz. An application server must directly validate access with the DC.
With Kerberos, the hash is stored in fewer places, so stealing the KRBTGT password requires access to the KDC on the DC to create a Golden Ticket.
With Kerberos, attackers stealing a user’s password can only access what the user can. To gain more, they target the NTLM hash of the KRBTGT account.
This allows them to forge tickets. By executing a Golden Ticket attack, they can impersonate authentication and elevate access rights across the environment.
Actually, anyone can. To create a Golden Ticket that grants full domain access, an attacker must obtain the domain’s FQDN, SID, target account username, and the KRBTGT NTLM hash. With this information, they can forge a valid Kerberos ticket. Without these elements, a forged ticket is useless, like a fake credit card without a correct account number.
Furthermore, despite the Active Directory domain policy for Kerberos ticket lifetime. The KDC trusts the TGT, so the custom ticket can include a custom ticket lifetime (even one that exceeds the domain kerberos policy).
Furthermore, I hope you found this blog post on “Active Directory Authentication methods: Kerberos and NTLM” helpful. However, Please let me know in the comment session if you have any questions.
Nice post. Very informative.
Very nice article!!