NTLM vs Kerberos: Why It’s Time to Upgrade Your Authentication Strategy

Authentication is the backbone of enterprise security. Yet, many organizations still rely on NTLM (NT LAN Manager), a protocol introduced decades ago with Windows NT. While Microsoft replaced NTLM with Kerberos as the default authentication protocol in Windows 2000, NTLM—primarily NTLMv2—remains widely used. This persistence creates unnecessary risk. Let’s explore why NTLM is outdated, why Kerberos is superior, and how to make the transition.

---

Understanding NTLM and Its Limitations

NTLM uses a challenge/response mechanism for authentication. While this was innovative in the 1990s, today it’s a liability:

• Weak encryption: NTLMv1 hashes can be cracked in seconds with modern computing power.
• Password exposure: Hashes are stored in memory and can be extracted using tools like Mimikatz.
• No mutual authentication: Clients cannot verify servers, making NTLM vulnerable to man-in-the-middle attacks.
• Offline cracking risk: The challenge/response model allows attackers to capture and brute-force hashes.

Even NTLMv2, introduced to improve security, still suffers from fundamental flaws. Although it uses salted hashes, these are stored unsalted in memory, and the protocol remains susceptible to pass-the-hash attacks.

---

Why Kerberos Is the Gold Standard

Kerberos addresses NTLM’s weaknesses and introduces significant benefits:

• No passwords transmitted or stored locally: Authentication relies on tickets and symmetric encryption.
• Mutual authentication: Both client and server verify each other.
• Performance improvements: Kerberos reduces authentication overhead compared to NTLM.
• Delegation support: Enables secure service-to-service authentication.
• Simplified trust management: Ideal for multi-domain and cross-forest environments.
• Supports MFA: Enhances security for modern compliance requirements.

In short, Kerberos is faster, more secure, and designed for today’s enterprise needs.

---

How to Transition from NTLM to Kerberos

Migrating from NTLM to Kerberos requires careful planning. Here’s a step-by-step approach:

1. Assess Your Environment

• Inventory all applications and services.
• Identify legacy systems or third-party apps that depend on NTLM.
• Pay special attention to SQL Server, older SMB shares, and non-Windows systems.

2. Update Group Policy

Navigate to:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Key policies:

• Network Security: LAN Manager Authentication Level
  • Recommended setting: Send NTLMv2 response only. Refuse LM & NTLM (Registry value: 5).
• Restrict NTLM: NTLM authentication in this domain
  • Options include:
    • Deny for domain accounts
    • Deny for domain servers
    • Deny all (most restrictive)

3. Modify Registry Settings

On domain controllers:

HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Set to:

5 (Send NTLMv2 response only. Refuse LM & NTLM)

4. Test Before Full Deployment

• Use auditing policies to monitor NTLM usage.
• Gradually enforce restrictions in stages:
  • Start with “Audit only”
  • Move to “Deny for domain accounts”
  • Finally, “Deny all”

5. Educate Your Team

Ensure administrators and developers understand Kerberos requirements, such as proper SPN (Service Principal Name) configuration.

Preparation

Implementation Checklist

• Inventory all systems and applications.
• Confirm Kerberos support for critical apps (SQL, SMB, third-party).
• Document current NTLM usage via audit logs.

Configuration

• Set LmCompatibilityLevel to 5 on domain controllers.
• Configure Group Policy:
  • LAN Manager Authentication Level → NTLMv2 only, refuse LM & NTLM.
  • Restrict NTLM policies → Audit first, then enforce.
• Verify SPN configuration for Kerberos.

Testing

• Enable NTLM auditing in Group Policy.
• Review logs for NTLM traffic.
• Test Kerberos authentication for all critical services.

Deployment

• Apply NTLM restrictions in stages.
• Monitor for authentication failures.
• Communicate changes to IT teams and end-users.

Post-Migration

• Remove legacy NTLM dependencies.
• Regularly audit authentication protocols.
• Update documentation and security policies.

---

PowerShell Commands for Auditing NTLM Usage

Before enforcing NTLM restrictions, audit your environment to identify where NTLM is still being used:

Enable NTLM Auditing via Group Policy

Set these policies under:

Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

• Network security: Restrict NTLM: Audit NTLM authentication in this domain
• Network security: Restrict NTLM: Audit Incoming NTLM Traffic
• Network security: Restrict NTLM: Audit Outgoing NTLM Traffic

Collect NTLM Events with PowerShell

Run this command to query NTLM-related events from the Security log:

Get-WinEvent -FilterHashtable @{LogName=’Security’; ID=8001,8002,8003,8004} |
Select-Object TimeCreated, Id, Message | Format-Table -AutoSize

Event IDs:

• 8001 – NTLM authentication succeeded
• 8002 – NTLM authentication failed
• 8003 – NTLM blocked
• 8004 – NTLM audit event

Export NTLM Audit Data to CSV

Get-WinEvent -FilterHashtable @{LogName=’Security’; ID=8001,8002,8003,8004} |
Select-Object TimeCreated, Id, Message | Export-Csv “C:\NTLM_Audit.csv” -NoTypeInformation

---

Conclusion

NTLM served its purpose in the past, but today it’s a liability. Kerberos offers stronger security, better performance, and compliance with modern standards. By auditing NTLM usage, updating policies, and educating your team, you can make a smooth transition to Kerberos—and significantly reduce your attack surface.