Introduction to NTLM and Kerberos
Connecting all your company resources in a network for sharing is valuable, but you need a way to verify that only authorized users and devices can access these resources. Authentication serves this purpose by providing methods for users and devices to prove their identity.
In Windows environments, two main authentication protocols are used: NTLM (New Technology LAN Manager) and Kerberos.
- NTLM is an older, challenge-response-based authentication protocol that is still present in legacy systems and fallback scenarios.
- Kerberos is a more secure and efficient authentication protocol that leverages tickets and encryption for verifying identities in Active Directory (AD) environments.
In this article we will discuss NTLM vs Kerberos and show why it is important to implement Kerberos if possible.
What is NTLM?
NTLM is a suite of security protocols developed by Microsoft for user authentication and protection of data integrity and confidentiality. It was the default authentication protocol in older Windows versions but is restricted to limited scenarios today such as workgroup environments, local accounts and legacy applications.
NTLM authentication works through a challenge response mechanism as follows:
- The client sends a logon request using a username and password.
- The server responds with a challenge (a 16-byte random number).
- The client encrypts the challenge using the user’s hashed password as the encryption key and sends it back to the server.
- The server verifies the response against stored credentials in the Security Account Manager (SAM) database. If the response is correct, authentication is granted.
Variants: NTLMv1 vs NTLMv2
NTLM comes in two versions. NTLM v1 incorporates a weaker hashing algorithm, making it more vulnerable to security breaches. Its simpler challenge-response system leaves it open to both pass-the-hash attacks and rainbow table attacks. Another weakness of this 1993 protocol is that the client cannot verify the identity of the server, which makes man-in-the-middle attacks possible.
NTLMv2 was developed later as an upgrade to NTLMv1. It features stronger encryption (128-bit instead of 56-bit) and adds several security enhancements including variable-length challenges, and client-side timestamps. Despite these improvements, Microsoft is moving away from NTLM entirely and announced in October 2023 plans to soon deprecate all NTLM versions, including NTLMv2.
What is Kerberos?
Kerberos is a network authentication protocol designed to provide strong security for client-server applications through secret-key cryptography. Instead of sending a user’s passwords across the network it uses encrypted tickets with limited lifespans. It runs on domain controllers and has been the default authentication protocol for Windows domains since Windows 2000. On a side note, the protocol is named after Cerberus, the three-headed guard dog of Hades in Greek mythology, reflecting its role in providing robust security.
Kerberos operates on the principle of “Single Sign-On” (SSO), using a ticket-granting system to authenticate users and allow them access to resources without repeatedly sending passwords over the network. Once authenticated, a user must present their appointed ticket each time they want to access a resource. Here is the authentication process.
- A user logs in, the client sends an Authentication Service Request (AS-REQ) to the Key Distribution Center (KDC), which is hosted on a domain controller (DC).
- The KDC verifies the user’s identity and responds with an Authentication Service Response (AS-REP) that contains an encrypted Ticket Granting Ticket (TGT).
- The TGT is encrypted using the KDC’s secret key and is valid for a limited time (typically 10 hours).
- When the client needs to access a service, it requests a service ticket from the Ticket Granting Service (TGS) using the TGT.
- The TGS issues a ticket for the specific service, encrypted with the service’s secret key.
- The client presents this ticket to the service to authenticate and gain access
As you can see, the Key Distribution Center (KDC) is a vital part of how Kerberos authentication works. Think of the KDC as a security checkpoint that first confirms your identity, then gives you the specific passes you need to access different resources.
Key Differences Between NTLM and Kerberos
Although NTLM and Kerberos are both authentication protocols, they have very different mechanisms and security features that affect their security and performance. Let’s look at some of the ways they differ from one another.
Authentication mechanisms
NTLM uses a challenge-response system to check user identity each time they access a network resource. Kerberos on the other hand works with tickets instead. After logging in once, users get a Ticket Granting Ticket (TGT). When they need to access something, they show this TGT to get a service ticket. Then they use the service ticket to access network resources without ever sending their password.
Security features
NTLM Uses MD4 or MD5 hashing algorithms to store the password hash and does not support mutual authentication as only the client authenticates to the serve. NTLM’s lack of security features such as these makes it vulnerable to multiple types of attacks. Kerberos provides much stronger security through:
- AES encryption for better protection
- Mutual authentication where both client and server verify each other
- Password salting to resist cracking attempts
- Time-limited authentication tokens that prevent replay attacks
- Protection against pass-the-hash attacks since passwords never travel across the network
Performance and efficiency
While it has a lot of security weaknesses, NTLM requires less resources than Kerberos. It is generally faster for initial authentication and is usually more efficient in small, simple network environments. While it requires more resources, Kerberos is much better suited for large complex environments as it saves considerable time with subsequent authentications by using cached tickets.
Support for delegation and impersonation
NTLM only supports impersonation which allows a server process to temporarily assume the security context of a client on the local system. Kerberos Supports both impersonation and delegation of authentication. Delegation allows services to access other services on behalf of domain users.
Compatibility and implementation in Windows environments
Know that Kerberos is the default authentication protocol in modern Windows Active Directory domains. Microsoft has the intent to have it fully replace NTLM, which today is restricted to when Kerberos is not available.
Security Implications
Vulnerabilities of NTLM
Let’s dive a little more into the vulnerabilities of NTLM and why its use should be highly limited.
- NTLM is vulnerable to pass-the-hash attacks where attackers can use captured password hashes to authenticate without knowing the actual password.
- NTLM, particularly NTLMv1, uses the MD4 hashing algorithm, which is considered weak and vulnerable to rainbow table attacks. This weakness makes it easier for attackers to crack password hashes and gain unauthorized access.
- NTLM’s challenge-response process is predictable, which makes it susceptible to replay attacks if additional security measures like signing or encryption are not implemented.
Why Kerberos is more secure
Kerberos is a more modern authentication protocol with enhanced security features that address the shortcomings of its predecessor. Some of its features include the following:
- Ticket-Based Authentication, which eliminates the need to transmit passwords across the network, thus reducing the risk of password interception.
- Advanced Encryption such as AES encryption that enhances overall resilience to unauthorized access attempts such as brute force attacks
- Multi-Factor Authentication (MFA) Support that allows Kerberos the use of additional authentication factors like smart cards or biometrics, adding an extra layer of security beyond just passwords
Below is a chart that sums up the differences between NTLM and Kerberos.
| Features | NTLM | Kerberos |
| Authentication Mechanism | Challenge-Response mechanism | Ticket-based mechanism |
| Mutual Authentication | Not supported | Supported (both client and server authenticate each other) |
| Delegation Support | Not supported | Supports delegation |
| Single Sign-on (SSO) | Not supported | Fully supported |
| Encryption Algorithms | MD4 (NTLMv1), HMAC-MD5 (NTLMv2) | AES (Advanced Encryption Standard) |
| Primary Use Case | Local authentication, legacy systems, workgroup environments | Domain authentication in Active Directory environments |
When to Use NTLM vs Kerberos
While Kerberos is the preferred authentication method, some scenarios still require NTLM. For example, if a server loses connection to domain controllers, local logon authentication becomes necessary. Small office or home office environments without centralized domain controllers also rely on NTLM for basic account security on standalone machines. Many legacy applications still depend on NTLM authentication. Think of NTLM as the fallback option for exceptional circumstances. If you’re working in a Windows Active Directory environment, you should avoid using NTLM where possible and enforce Kerberos authentication to improve security, support delegation, and enable seamless authentication across services.
Identifying Which Protocol is in Use
Windows Event Viewer is a go-to tool for investigating authentication activities on individual servers or domain environments. To determine the authentication type, check the Security event log. Each event has a unique event ID. For example Event ID 4776 indicates an NTLM authentication. This event log entry provides details about the authentication attempt, such as the account used and the authentication source. The screenshot below shows the 4776 Event ID of an NTLM authentication for the local Administrator account of a standalone machine.
On a domain controller, you can look for Event ID 4768 which indicates Kerberos as shown on the screenshot below for a domain controller.
You can also open a command prompt and type “klist” which will show if any Kerberos tickets are present. If so, then you know that Kerberos is being used as is shown below.
You can also use packet analyzer tools like Wireshark to capture and analyze network traffic. Kerberos traffic will use port 88, while NTLM typically uses NetBIOS ports.
Transitioning from NTLM to Kerberos
While disabling NTLM on your Windows machines will ensure better security, you should only take that step if you are totally confident that it won’t disrupt your operations. Use Event Viewer as outlined in the previous section to confirm how NTLM is being used. If you are sure that you don’t need it on at least some machines, you can begin the disabling process.
Open the Group Policy Management Console and navigate to: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Then modify the following policies:
- Network security: Restrict NTLM: Incoming NTLM traffic > Set to Deny all accounts as shown in the screenshot below.
Because this is a big step, Windows will prompt you to confirm your intention as shown in the popup window below:
You also need to configure two more policies as well.
- Network security: Restrict NTLM: NTLM authentication in this domain > Set to Deny all accounts.
- Network security: LAN Manager authentication level > Set to Send NTLMv2 response only. Refuse LM & NTLM as shown in the screenshot below:
Be sure to deploy the policies in a test or non-production environment initially and test rigorously. Do not deploy the policy to all computers at once. Stagger the deployment gradually to ensure that there are no interruptions to your operations. Be sure to monitor your event logs.
Addressing common challenges in migration
You may have some legacy applications that may not support Kerberos. Do research to see if there are any updates that allow Kerberos compatibility. If an application must use NTLM, limit its NTLM access to specific accounts or hosts.
Note that Kerberos authentication requires accurate DNS resolution and synchronized time across the network. Make sure that all domain controllers, clients, and services are configured with the proper DNS settings and NTP time synchronization. You may also have to educate users about the changes in authentication processes, particularly regarding Single Sign-On (SSO) features.
Best practices for securing authentication protocols
- Restrict NTLM usage to absolute necessities
- Continue to monitor logs for unusual authentication patterns or failed login attempts and use tools like Windows Event Viewer to track Event IDs related to authentication
- Regularly apply security patches and updates to all systems involved in the authentication process to mitigate vulnerabilities.
- Run security assessments to verify Kerberos enforcement policies and detect unapproved NTLM usage.
- Strengthen account security by implementing complex password policies and complementing them with multi-factor authentication.
- Regularly audit service principal names (SPNs)
Real-World Use Cases and Examples
As enterprises continue to expand and grow in complexity and Kerberos is built to scale alongside them. Users benefit from Single Sign-On (SSO), allowing access to multiple services after a single authentication. The protocol provides mutual authentication where both client and server verify each other’s identity, and it uses a ticket-based system that prevents direct transmission of credentials. This approach not only enhances security but also supports service delegation, enabling complex multi-tier applications to securely access resources on behalf of users.
Kerberos and Hybrid Environments
Microsoft has acknowledged the growing trend of hybrid network architecture and is adapting Kerberos to support more flexible, complex network environments that span on-premises and cloud infrastructure. For organizations implementing cloud-based SSO solutions, Kerberos can be used in conjunction with modern authentication protocols to provide seamless access to both on-premises and cloud resources. Another example is that Windows Hello for Business allows users to access on-premises resources using Kerberos authentication from cloud-joined workstations, without needing a hybrid device configuration.
Legacy Applications
There still exist legacy applications that were developed before Kerberos was widely adopted and thus need NTLM. One consideration for these is to run them on Windows 2003 or 2008 servers that do not fully support modern Kerberos authentication themselves. Some examples of legacy apps include:
- Some enterprise resource planning (ERP) and human resource applications, especially if they were developed before the 2000s
- Legacy Windows-based file servers and intranet portals that run on older versions of IIS or SMB that default to NTLM.
- Older remote desktop and VPN solutions that do not support Kerberos delegation
Conclusion
Security should be the primary consideration when selecting IT solutions, and when it comes to Kerberos vs NTLM, Kerberos is clearly the superior choice. However, understanding the specific scenarios where NTLM might still be necessary is crucial for comprehensive network management.
FAQs
What is the difference between NTLM and Kerberos?
NTLM and Kerberos are both Windows authentication protocols, but with significant differences. NTLM uses a simple challenge-response mechanism where the client proves identity to the server using password hashes. It lacks mutual authentication, and is vulnerable to various attack types. In contrast, Kerberos is a more sophisticated ticket-based system that enables mutual authentication, uses strong AES encryption, provides single sign-on capabilities, and prevents password transmission across the network. While NTLM remains supported for legacy systems, Kerberos has become the standard authentication protocol in modern Windows Active Directory domains due to its superior security features and performance.
Why did Microsoft change from NTLM to Kerberos?
Microsoft transitioned from NTLM to Kerberos due to the need for stronger security, better scalability, and improved efficiency in modern enterprise environments. NTLM’s challenge-response mechanism made it vulnerable to attacks like pass-the-hash and relay attacks, whereas Kerberos introduced stronger encryption, mutual authentication, and ticket-based authentication, reducing security risks and improving performance. Kerberos also supports advanced features like delegation, Single Sign-On (SSO), and integration with multi-factor authentication (MFA), which NTLM lacks. This makes Kerberos far better suited for the modernized hybrid networks of today.
Is NTLM used anymore?
While the use of NTLM is highly discouraged today, it is required for a limited number of scenarios such as:
- Older Windows workgroup environments
- Legacy applications that don’t support Kerberos
- Local machine authentication
- Fallback authentication for when Kerberos authentication fails
- Standalone machines
Is NTLM used for local authentication?
NTLM remains the primary authentication protocol for local Windows machine logons for the following scenarios:
- Local Machine Logons: For standalone Windows systems or those in workgroup environments without domain controllers, NTLM remains the primary authentication protocol.
- Workgroup Environments: In small networks or home offices where a domain structure is not implemented, NTLM facilitates peer-to-peer authentication between machines.
- Least Privilege Scenarios: Organizations often use local accounts, authenticated via NTLM, to implement the principle of least privilege. This approach limits the potential impact of a compromised account by restricting its access rights to only the local machine.
Fallback Authentication: In domain environments, NTLM serves as a fallback mechanism when Kerberos authentication fails, ensuring continued access to resources.
