Disabling NTLMv2 Across Your Domain — Part 1: Why, When & How to Plan

#disabling #ntlmv2 #migration #windows

Disabling NTLMv2 Across Your Domain — Part 1: Why, When & How to Plan

If you\'re reading this, you\'ve probably already realized NTLMv2 is a liability. Let me be direct: it\'s 2026, and you shouldn\'t be relying on a protocol from the Windows 2000 era for authentication. But the migration isn\'t trivial, and I\'ll walk you through exactly what you need to know before you start breaking things.

Introduction

NTLM stands for New Technology LAN Manager. Microsoft built it in the 1990s as a step up from the older LM protocol, but that doesn\'t mean much when attackers have spent three decades poking holes in it. NTLMv2 came along with Windows 2000 and patched some of the worst vulnerabilities, but here\'s the reality: it\'s still not secure. Not compared to Kerberos. Not compared to modern authentication at all.

In this article, we\'re covering:

What NTLM/NTLMv2 actually is and why you should care
The business case for pulling the plug on it
Pre-migration checklist and what you actually need
Migration timeline and honest risk assessment
Key takeaways and how to start planning

What is NTLM/NTLMv2?

NTLM is a challenge-response authentication protocol. Here\'s how it works: user logs in, client sends a request to the server, server responds with a challenge, client hashes the password and sends it back, server verifies. It\'s straightforward. Predictable. And that\'s exactly why it\'s exploitable.

NTLMv2 improved on the original by using a more secure hash function and adding support for 128-bit encryption. It also handles password storage more carefully than its predecessor. But—and this is important—it\'s still fundamentally weaker than Kerberos, which uses a ticket-based system with symmetric key encryption. That\'s the difference between \"less terrible\" and \"actually secure.\"

NTLMv2 vs Kerberos: Security Differences

Here\'s how they stack up:

Feature	NTLMv2	Kerberos
Encryption	128-bit	128-bit (configurable)
Password Storage	Hashed password	Encrypted password
Authentication	Challenge-response	Ticket-based
Security posture	Vulnerable to Pass-the-Hash and Relay attacks	Resistant to credential-based attacks

Kerberos isn\'t perfect, but it\'s the clear winner here.

Why Microsoft Deprecates NTLM

Microsoft didn\'t deprecate NTLM because they were bored. They did it because the protocol is vulnerable to attack patterns that have become standard in the attacker playbook. Pass-the-Hash and Relay attacks work because of how NTLM fundamentally operates.

Real-World Attack Scenarios

Let me give you scenarios I\'ve actually encountered in the field.

Pass-the-Hash (PtH) attack: An attacker compromises a workstation or gets their hands on a SAM database dump. They extract the NTLM hash and use it to authenticate to network resources without ever needing the plaintext password. Multi-factor authentication? Doesn\'t matter—they\'ve already got the hash. I\'ve seen this blow past well-intentioned \"secure password policy\" implementations in organizations that thought they were protected.

Relay attack: An attacker positions themselves on the network (via a compromised system, rogue access point, or ARP spoofing) and intercepts NTLM authentication traffic. They relay it to a target system before the legitimate user even knows what happened. Sometimes they don\'t even need to crack anything—the hash itself is the weapon. In practice, what I see most often is relay attacks chaining together with SMB signing disabled. That\'s the real nightmare scenario.

The Business Case

Before you start planning this migration, you need ammunition for the business case. Here\'s what actually matters:

Security risks: NTLMv2 is exploitable in ways that directly lead to unauthorized access and credential compromise. Not theoretical risk—active risk.

Compliance requirements: If you\'re dealing with SOC 2, PCI-DSS, HIPAA, or NIST 800-171, regulators want you off NTLM. Some of them require it in writing.

Attack statistics: NTLMv2 is one of the most commonly exploited protocols in modern networks. It shows up in practically every penetration test report I review.

Cost of breaches: A breach stemming from NTLMv2 exploitation can cost anywhere from $100,000 to millions, depending on your organization\'s size and what the attacker gets access to. That\'s not theoretical either.

Bottom line: This isn\'t a security theater project. This is risk reduction.

Pre-Migration Checklist

Before you even think about touching your domain, you need visibility into what you\'re dealing with.

Audit current NTLM usage: PowerShell is your friend here. You\'ll want to enable NTLM logging on your domain controllers and monitor for NTLM authentication traffic across your infrastructure. Check Event Viewer for event ID 4688 on your DCs with process tracking enabled—you\'ll see which applications are actually calling NTLM.

Identify legacy applications: Here\'s the part most guides skip: you\'ll find applications you forgot existed. Old print servers. Database clients. Custom LOB applications written in 2005 that nobody has touched since. Document every single one.

Test environment requirements: Build a test domain or at least a test OU that mirrors your production setup. This is non-negotiable. What trips people up here is testing in an environment too different from production—a single DC in a lab doesn\'t tell you how a multi-DC forest will behave.

Backup strategy: Before you change anything domain-wide, you need a solid backup of your Active Directory. I mean full backups, recovery testing, the whole nine yards. If this goes sideways, you\'ll need to restore quickly.

Prerequisites

You\'ll need specific infrastructure to make this work.

Windows Server 2016+ Domain Controllers: You need at least Windows Server 2016 DCs to reliably support Kerberos enforcement without weird compatibility issues. Server 2012 R2 technically supports Kerberos, but you\'ll run into edge cases. This depends on your forest functional level—if you\'re still running Server 2008 R2 DCs, you\'ve got a bigger problem than just NTLM.

Kerberos functional levels: Your domain functional level should be at least 2012 R2, though 2016 is safer. Server 2016 functional level gives you better Kerberos armor and protection against some attack vectors that older levels don\'t have.

Network connectivity requirements: Kerberos relies on your DCs being reachable and your domain controllers being able to communicate with each other. If you\'ve got network segmentation (and you should), make sure your firewall rules allow Kerberos traffic on ports 88 (TCP/UDP) before you start.

Tools needed: You\'ll be living in PowerShell, Group Policy, and Event Viewer. Know your way around all three. Your mileage may vary on older schema versions, but if you\'re on a current build, these tools will give you what you need.

Migration Timeline & Risk Assessment

Timelines vary wildly depending on your organization\'s size and complexity, but here\'s a realistic breakdown:

Phase 1: Audit (1-2 weeks): Enable NTLM logging, monitor traffic, identify all the applications and services that depend on NTLM. Document everything. Don\'t rush this—a bad audit means a bad migration.

Phase 2: Testing (1-2 weeks): Set up your test environment with Kerberos-only authentication (or at least NTLM restricted) and run your legacy applications against it. If you\'ve got 50 applications, you\'re testing 50 applications. This phase is where you\'ll discover the surprises.

Phase 3: Deployment (1-2 weeks): Roll this out by OU or business unit, not domain-wide in one shot. Start with non-critical systems. Monitor as you go.

Phase 4: Monitoring (ongoing): After you\'ve disabled NTLM, you\'ll need to watch for authentication failures, application errors, and unexpected NTLM fallback attempts. This isn\'t fire-and-forget.

One more thing — factor in time for remediation. You\'ll find systems that need updates, applications that need new service accounts, network changes that need to happen. Build buffer time into your timeline.