The client sends NTLMv2, but the domain still accepts more
The Windows client baseline report already says “Send NTLMv2 response only”. The file server works, and so does authentication from the scanner. It is easy to conclude that NTLMv1 has been disabled. In reality, this initially describes only the outgoing behavior of the clients assessed. Nobody may have checked which responses a domain controller still validates.
A consistent NTLMv2-only baseline closes precisely this gap. It complements the broader effort to reduce NTLM with a specific minimum requirement: wherever NTLM is still needed, LM and NTLMv1 must no longer work as authentication methods. Kerberos remains the preferred path; this policy does not force a switch to Kerberos.
NTLMv1 has already been removed from Windows 11 version 24H2 onward and Windows Server 2025. The additional benefit therefore lies particularly in mixed estates, older supported systems and an auditable configuration. Inventory the operating system, update level and actual authentication behavior together.
Plan outgoing authentication and validation separately
The target state covers three roles. Windows clients send only NTLMv2 when NTLM is necessary. Member servers receive the same baseline for their own outgoing connections and the validation they perform locally. All domain controllers reject LM and NTLMv1 for the domain authentication requests they validate.
For a domain account, password validation typically happens at a DC; for a local account, it happens on the responsible computer. A hardened member server alone therefore does not prove domain-wide enforcement. Third-party devices also need an appropriate configuration or update of their own; a Windows GPO does not automatically reach their authentication library.
For every remaining NTLM path, record the source system, destination system, application, account type, business owner and planned replacement. A migration dependency is not sufficiently understood until the actual business process relying on it is clear.
Check the difference between policy values 3 and 5
Use a dedicated computer policy with documented links. In the Group Policy editor, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. The setting is Network security: LAN Manager authentication level.
The target is Send NTLMv2 response only. Refuse LM & NTLM. This selection corresponds to the registry value LmCompatibilityLevel = 5 under HKLM\SYSTEM\CurrentControlSet\Control\Lsa.
- Value
3,Send NTLMv2 response only: the client sends NTLMv2. Domain controllers still accept LM, NTLMv1 and NTLMv2 authentication. - Value
4,Send NTLMv2 response only. Refuse LM: LM is rejected, but NTLMv1 remains possible during DC validation. - Value
5,Send NTLMv2 response only. Refuse LM & NTLM: NTLMv1 is rejected as well. The standalone “NTLM” in this historical policy name means NTLMv1 here, not the entire NTLM family.
This policy is also distinct from Restrict NTLM. Those audit and blocking options control NTLM usage according to different criteria. A server exception configured there does not make an NTLMv1 client compatible with a validator set to level 5.
Resolve dependencies before changing domain controllers
Start with a representative test group of Windows clients and member servers. Explicitly check NAS systems, multifunction printers, backup agents, older applications and local emergency accounts. A successful desktop sign-in does not test these network paths.
Enable the required monitoring in advance. Depending on the system, this includes advanced audit policies for Logon and Credential Validation, as well as the intended NTLM audit options. On supported systems with the appropriate updates, enhanced NTLM auditing in Microsoft-Windows-NTLM/Operational provides additional version, process and reason information. Coverage and events depend on the operating system and update level.
Run the pilot through at least one complete business operating cycle, including scheduled jobs. Resolve outdated protocol use at its source. Then change the DCs under a controlled change window, with monitoring and a verified administrative access path. An isolated test AD is better suited to checking the DC impact in advance than a permanently divergent production DC.
A DC pilot does not limit the impact to users in a pilot OU: that DC may validate requests from across the domain. Different values on different DCs produce varying results depending on which validator is selected. The approved final state must therefore include all DCs.
Verify effective values and new connections
On the target systems, use gpresult /scope computer /r for an initial overview of applied computer policies. To verify the individual security setting, also obtain a protected HTML results report or use Group Policy Results in the GPMC. Check the resultant value and the winning GPO there; showing only the intended value in the editor is insufficient.
The following local PowerShell check reads only the explicit registry configuration. A missing value does not prove a particular effective default level:
Set-StrictMode -Version Latest
$lsaPath = 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa'
try {
$settings = Get-ItemProperty -LiteralPath $lsaPath -ErrorAction Stop
$entry = $settings.PSObject.Properties['LmCompatibilityLevel']
[pscustomobject]@{
ExplicitlyConfigured = ($null -ne $entry)
LmCompatibilityLevel = $(if ($null -ne $entry) { $entry.Value } else { $null })
}
}
catch {
throw 'The local LAN Manager policy value could not be read.'
}This policy change does not require a restart. Nevertheless, verify that Group Policy has processed successfully and establish new application sessions. An existing SMB connection or an already authenticated service does not prove that a new authentication would meet the same requirements. Disconnect production sessions only within the agreed test window.
Read events correctly and avoid false positives
Event 4624 on the actual destination system can identify the variant in Package Name (NTLM only) when the authentication package is NTLM. Assess the relevant audit data together with the application, account and a newly established connection. Anonymous logons showing NTLM V1 do not prove password authentication through NTLMv1. Older systems can also misclassify events.
Event 4776 records NTLM credential validation at the responsible validator. The package name MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 does not mean NTLMv1. The event also does not identify the destination server being accessed. Correlated destination-system and application data are needed to establish that connection.
Acceptance combines the effective policy, successful new NTLMv2 connections and demonstrable rejection of genuinely incompatible legacy systems in an isolated test environment. Production systems are not downgraded to old methods for this purpose. Test Kerberos connections separately; their success says nothing about NTLM fallback. Missing events under incomplete auditing do not count as success.
Benefits: a verifiable minimum standard for remaining NTLM
- Weaker LM and NTLMv1 methods are rejected at the responsible validators, rather than merely avoided by modern clients.
- A consistent target value simplifies compliance checks, drift detection and the assessment of new servers or devices.
- Incompatible dependencies are assigned to specific applications and owners, allowing targeted updates or replacement.
- Remaining NTLM usage becomes a documented transitional arrangement with a measurable scope.
Disadvantages and limitations: NTLMv2 remains transitional
The change can cut off older devices or applications. Automatic retries can generate further errors and account lockouts; the helpdesk and monitoring teams need the affected systems and escalation paths in advance. Changes to DCs have a wider impact than a single client GPO.
NTLMv2-only does not prevent relay or pass-the-hash attacks by itself, and it does not replace multifactor authentication. SMB signing, LDAP signing and channel binding, and Extended Protection for Authentication on supported services remain separate controls. An encrypted transport connection also does not automatically establish which NTLM version was used.
Network negotiation is separate from password storage. Network security: Do not store LAN Manager hash value on next password change should be enabled; existing LM hashes are removed only when the password is subsequently changed. Plan service account changes in particular around dependent applications. Level 5 alone does not clean up stored hashes.
Define exceptions and rollback before the change
Document the previous effective values, GPO links, filters and responsible change owner. If a pilot fails, it must be possible to restore the approved previous configuration in a targeted manner. “Not configured” is not a reliable substitute: other policies or remaining settings may continue to apply.
A legacy device does not justify permanently lowering the requirements on every DC. Prefer an update, replacement or suspension of the affected access. Any temporary rollback needs a risk decision, a tightly limited scope, additional monitoring and an end date. A permanently weaker DC is not a defensible exception mechanism.
Project checklist for NTLMv2-only
- Inventory operating systems, update levels and existing LAN Manager policies for clients, member servers and every DC.
- Test domain accounts, local accounts and third-party devices separately; assign an owner to each remaining NTLM path.
- Verify auditing on source, destination and validation systems before drawing conclusions from missing events.
- Pilot level 5 with selected clients and servers, including scheduled jobs and new connections.
- Plan the DC change around its domain-wide impact and eliminate inconsistent final states.
- Document the resultant GPO, explicit registry value and actual authentication results together.
- Do not accept NTLMv2 as relay protection; continue complementary service protections and the Kerberos migration.
- Record rollback, exceptions, owners and expiry dates; check regularly for drift after rollout.