Introduction to NTLM Security

NTLM (NT LAN Manager) is a challenge-response authentication protocol used by Windows when Kerberos is not available—for example when accessing resources by IP address instead of hostname, in workgroup environments, or when connecting to legacy systems. While Kerberos is the preferred protocol, NTLM is still present in virtually all Windows environments and represents a significant attack surface. NTLM authentication is vulnerable to pass-the-hash attacks, relay attacks, and brute force offline cracking. Windows Server 2019 provides several controls to harden NTLM: restricting NTLM usage, requiring NTLMv2 only, auditing NTLM traffic, and blocking NTLM entirely for privileged accounts. This tutorial covers all these hardening measures.

Understanding NTLM Versions

NTLM has three versions: LM (LAN Manager—extremely weak, stores passwords in uppercase and split into two 7-character chunks), NTLMv1 (uses MD4 hash, vulnerable to pass-the-hash and relay attacks), and NTLMv2 (uses HMAC-MD5 with a timestamp and client challenge, resistant to simple relay attacks but still vulnerable to pass-the-hash). Windows Server 2019 defaults to NTLMv2 but can send older versions for compatibility with legacy systems. The goal is to disable LM and NTLMv1 entirely and restrict NTLMv2 usage.

Configuring the LAN Manager Authentication Level

The most important NTLM security setting is the LAN Manager authentication level, controlled by a Group Policy security option. Set this to the highest level: “Send NTLMv2 response only. Refuse LM & NTLM.” This ensures clients and servers only use NTLMv2 and reject any LM or NTLMv1 challenges.

# Check current LAN Manager authentication level
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
    -Name "LmCompatibilityLevel" -ErrorAction SilentlyContinue

Values: 0=Send LM & NTLM, 1=NTLMv2 if negotiated, 2=Send NTLMv2 only, 3=Send NTLMv2 only/refuse LM, 4=refuse LM, 5=refuse LM & NTLM (NTLMv2 only). Set to 5 for maximum security.

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
    -Name "LmCompatibilityLevel" -Value 5 -Type DWord

Configure via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > “Network security: LAN Manager authentication level” = “Send NTLMv2 response only. Refuse LM & NTLM.”

Disabling LM Hash Storage

By default, Windows does not store LM hashes for passwords longer than 14 characters. However, explicitly disabling LM hash storage is a security best practice that prevents any LM hashes from being stored in the SAM database or Active Directory, even for short passwords.

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
    -Name "NoLMHash" -Value 1 -Type DWord

Configure via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > “Network security: Do not store LAN Manager hash value on next password change” = Enabled.

Configuring Minimum Session Security

Configure minimum session security for NTLM to require NTLMv2 session security and 128-bit encryption. These settings are in the Security Options under Group Policy.

# Minimum session security for NTLM SSP based clients
# Value 537395200 = Require NTLMv2 + 128-bit encryption
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "NTLMMinClientSec" -Value 537395200 -Type DWord

# Minimum session security for NTLM SSP based servers
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "NTLMMinServerSec" -Value 537395200 -Type DWord

Auditing NTLM Authentication

Before restricting NTLM, audit which applications and services are using it. Enable NTLM auditing to log all NTLM authentication requests. Event ID 4776 in the Security log captures NTLM credential validation attempts on domain controllers.

auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable

Enable NTLM incoming authentication audit on domain controllers:

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesNetlogonParameters" `
    -Name "AuditNTLMInDomain" -Value 7 -Type DWord

Query NTLM authentication events:

Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id = 4776
    StartTime = (Get-Date).AddHours(-24)
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    [PSCustomObject]@{
        Time = $_.TimeCreated
        TargetUser = $xml.Event.EventData.Data[1].'#text'
        Workstation = $xml.Event.EventData.Data[2].'#text'
        Status = $xml.Event.EventData.Data[3].'#text'
    }
} | Group-Object Workstation | Sort-Object Count -Descending

Restricting NTLM for Domain Controllers

After auditing, restrict incoming NTLM authentication on domain controllers. This prevents clients from using NTLM to authenticate to DCs while still allowing Kerberos. Configure via Group Policy: Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > “Network security: Restrict NTLM: Incoming NTLM traffic.” Set to “Deny all domain accounts.”

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "RestrictReceivingNTLMTraffic" -Value 2 -Type DWord

Values: 0=Allow all, 1=Deny domain accounts, 2=Deny all accounts.

Adding NTLM Exceptions

After restricting NTLM, some applications or systems may still require it. Create a whitelist of servers that are allowed to use NTLM for authentication exceptions. This allows specific legacy servers to continue using NTLM while enforcing Kerberos everywhere else.

# Configure NTLM server exception list
# Group Policy: Network security: Restrict NTLM: Add server exceptions in this domain
# List servers that need NTLM exceptions, one per line

# Via registry (add entries as REG_MULTI_SZ values)
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "ClientAllowedNTLMServers" `
    -Value @("legacyserver01.yourdomain.com","printserver02.yourdomain.com") `
    -Type MultiString

Using the Protected Users Security Group

The Protected Users security group is a powerful tool for eliminating NTLM for privileged accounts. Members of this group: cannot authenticate using NTLM (Kerberos only), cannot use DES or RC4 Kerberos encryption, cannot use unconstrained delegation, and have TGT lifetimes limited to 4 hours. Add Domain Admins and other privileged accounts to Protected Users.

Add-ADGroupMember -Identity "Protected Users" `
    -Members "AdminUser1","AdminUser2","svc-critical"

# Verify membership
Get-ADGroupMember -Identity "Protected Users"

Conclusion

Hardening NTLM security on Windows Server 2019 is a layered process: require NTLMv2 exclusively, disable LM hash storage, enforce 128-bit encryption for NTLM sessions, audit NTLM usage to identify legacy dependencies, restrict NTLM on domain controllers after addressing those dependencies, and protect the most privileged accounts by adding them to the Protected Users group which blocks NTLM entirely. These controls dramatically reduce the attack surface for relay attacks, pass-the-hash, and credential theft that target NTLM authentication.