Kerberos, NTLMv1, and NTLMv2 are three authentication protocols. These protocols aim to enhance security, especially in the Active Directory environment. Authentication protocols are popular attack vectors. They can help attackers gain access and elevate privileges. Thus, it is important to choose the most secure protocol possible and know their weaknesses.
The most veteran protocol among the three is the NTLMv1. NTLMv2 offers small additions to increase security. The kerberos authentication process is much more complex and more secure.
This blog post will cover:
- NTLMv1 authentication
- NTLMv2 authentication
- Kerberos authentication
- NTLM vs Kerberos comparison
- Why NTLM is still in use
NTLM was developed by Microsoft. It supports both new and old Windows versions (Windows 95, Windows 98, Windows ME, N.T 4.0).
NTLM authentication is structured as a challenge and response mechanism:
- A user signs in to a client computer with a domain name, user name, and password.
- The client computer creates a cryptographic hash (either NT or KM hash) of the password.
- The client computer sends the targeted server the user name in plain text.
- The targeted server generates a 16-byte random number and sends it to the client computer – the challenge.
- The client computer responds and sends the challenge with the hash of the user’s password – the response.
- The server sends to the Domain Controller (DC) the user name, the challenge, and the response.
- The DC gets the user password’s hash from the Security Account Manager by using the user name.
- The DC encrypts the challenge.
- The DC compares the challenge it encrypted and the client’s encrypted response. If they are identical, then the authentication is approved.
NTLMv1 authentication mechanism is relatively easy to crack. Since the NTLMv1 hash is always at the same length, it is only a matter of seconds if an attacker wants to crack it. In addition, the challenge-response mechanism exposes the password to offline cracking. It is recommended not to use it if possible.
NTLM v2 also uses the same flow as NTLMv1 but has 2changes:1. The client includes a timestamp when it sends the user name to the client (stage 3). 2. The targeted server generates a variable-length challenge (instead of a 16-byte challenge). These changes help mitigating relay attacks. And yet, NTLMv2 is still exposed to other NTLMv1 vulnerabilities since it is still using the same authentication mechanism.
NTLM’s challenge-response mechanism only allows one-way authentication – the client in front of the server. This decreases NTLM security since the client can unintendingly authenticate in front of a bogus server.
Kerberos protocol is open-source software. It supports newer Windows versions (Windows 2000, Windows XP, and later).
The authentication process in Kerberos is more complex than in NTLM. Kerberos supports two-factor authentication and uses mutual authentication. It uses tickets and a token to verify the client. In addition, it uses three different keys to make it harder for attackers to breach this protocol.
This is how Kerberos authentication process works:
1.The client verifies himself in front of the Key Distribution Center (KDC).
2. The client connects with the Authentication Server:
a. The client connects with an Authentication Server (AS). He uses its User ID to request a ticket. The client uses it’s password’s secret key to encrypt the request.
b. The AS uses the client’s password to decrypt the request and verify the client.
c. The AS sends the client a Ticket Granting Ticket (TGT). The AS uses a different secret key to encrypt the TGT.
3. The client requests a token from the TGS:
a. The client sends the TGT and a request to connect the targeted server to a Ticket Granting Server (TGS).
b. The TGS shares the TGT with the AS to verify it.
c. The TGS issues an encrypted token for the client. The TGS shares with the targeted server the token’s key.
4. The client connects with the targeted server:
a. The client sends the token to the targeted server.
b. The server decrypts the token using the key he got from the TGS.
c. The client can use the server for the time set in the token.
The Kerberos authentication process uses three different secret keys. 1. The first key between the client and the AS is based on the client’s password. 2. The AS and the TGS share another secret key. 3. The TGS and the targeted server.
Kerberos supports mutual authentication. This means that not only the client authenticates to the server, the server also authenticates to the client. The client can choose to use this feature.
In addition, Kerberos allows authentication delegation, which means that a server can access remote resources on behalf of the client. This means that a user can authenticate to a server by using an intermediary machine. The targeted server will decide to approve or not the request based on the user’s identity and not the intermediary machine’s identity. You can use this feature in multi-tier applications. For example, when you need to use a Web server to authorize user access to a database.
Kerberos PKINIT extension:
Kerberos PKINIT extension supports smart card logon security feature. Smart card logon allows two-factor authentication. That dramatically elevates Kerberos’s security and can block attacks such as Trojan Horse Attacks.
NTLM vs Kerberos:
|Bad||Better||Best- no password is stored or sent over the network|
|Slower authentication||Slower authentication||Faster authentication|
|Support just impersonation
|Support just impersonation
|Supports impersonation and delegation of authentication|
Multi-Factor Authentication – Smart Cards
|Does not support||Does not support||Support|
|Symmetric cryptography||Symmetric cryptography||Supports both symmetric and asymmetric cryptography
Trusted third party
|DC||DC||DC, KDC (and Windows Enterprise Certification Authority in Kerberos PKINIT).|
|Does not support||Does not support||Support|
Why NTLM is still in use:
The obvious question is why NTLMv1 and NTLMv2 are still in use if there’s a safer alternative? The answer is that neglecting NTLM is more complex than it sounds. This process holds challenges such as:
* Using applications that do not support Kerberos
* Mapping where NTLM is being used
* Checking the impact of disabling NTLM.
Here are a few examples of when you’ll use NTLM:
- Kerberos does not work when you use a load balancer for web traffic (requires special configuration).
- Kerberos won’t work if the SPN presented by the client does not exist in the AD. For example, when trying to access a resource using an IP instead of a name.
- When you need to work both with external (non-domain) and internal clients.
- When you need to work both with domain accounts and local user accounts on the IIS box.
- When you have no SPN registered.
- When the client doesn’t have DNS or DC connectivity.
- When the client’s proxy setting or Local Internet Zone is not used for the targeted site.
Detecting these scenarios can be a pain. For this reason, we highly recommend using automation for this process. Tools such as CalCom Hardening Solution (CHS) automates server hardening. CHS will report to you where NTLM is being used and where you can disable NTLM and use only Kerberos without causing any damage. It will also enforce your policy to the production environment, to make sure everything is configured correctly. Finally, it will monitor and fix any configuration drifts to make sure you remain compliant and secure.