How to Configure NTLM Authentication on Windows Server 2012 R2

NT LAN Manager (NTLM) is a challenge-response authentication protocol that predates Kerberos in Windows environments. While Kerberos is the preferred protocol for domain authentication, NTLM remains in use for several scenarios: authentication to servers by IP address rather than FQDN, workgroup authentication, legacy applications, and authentication when Kerberos infrastructure is unavailable. Understanding how to configure, restrict, and audit NTLM on Windows Server 2012 R2 is important for hardening your environment and reducing exposure to pass-the-hash and relay attacks. This guide covers NTLM configuration through Group Policy and monitoring tools.

Prerequisites

NTLM configuration is performed through Group Policy. Domain Admin or Group Policy creation rights are required. You should have a clear understanding of which applications and workloads use NTLM in your environment before implementing restrictions, to avoid disrupting legitimate authentication flows.

Import-Module GroupPolicy

Understanding NTLM Authentication Flow

NTLM uses a three-way challenge-response mechanism. When a client authenticates to a server using NTLM: the client sends a negotiation message identifying its capabilities; the server responds with a challenge (a random nonce); the client hashes the challenge with the user’s password hash (NT hash) and sends the response. For domain accounts, the server passes the response to a domain controller for validation. NTLM does not provide mutual authentication, making it vulnerable to relay attacks where an attacker intercepts and replays the challenge response to another server.

NTLM Versions and LAN Manager Compatibility

Windows supports three NTLM variants: LM (LAN Manager, extremely weak), NTLMv1, and NTLMv2. Configure the LAN Manager Authentication Level policy to enforce NTLMv2 and prevent weaker variants:

Navigate in Group Policy to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: LAN Manager authentication level.

The recommended setting for Windows Server 2012 R2 environments is “Send NTLMv2 response only. Refuse LM and NTLM.” This is level 5 of the 6-level scale (0-5):

# Create a GPO for NTLM hardening
New-GPO -Name "NTLM-Security-Hardening" -Domain "contoso.com"
New-GPLink -Name "NTLM-Security-Hardening" `
    -Target "DC=contoso,DC=com" `
    -LinkEnabled Yes

Set the following security option in the GPO:

# Apply via secedit template to the GPO
# Security Options registry path:
# HKLMSYSTEMCurrentControlSetControlLsaLmCompatibilityLevel
# Value: 5 = Send NTLMv2 only, refuse LM and NTLM

# View current LM compatibility level
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
    -Name "LmCompatibilityLevel" -ErrorAction SilentlyContinue

# Set directly (backup approach when GPO is not yet applied)
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
    -Name "LmCompatibilityLevel" -Value 5 -Type DWord

Restricting NTLM Authentication

Windows Server 2012 R2 includes Group Policy settings to restrict NTLM usage at a granular level. These settings are found in Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options:

Network security: Restrict NTLM: NTLM authentication in this domain — controls whether DCs allow NTLM authentication for domain accounts. Network security: Restrict NTLM: Incoming NTLM traffic — restricts which servers can receive NTLM authentication requests. Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers — controls whether clients send NTLM to remote servers.

# Registry paths for NTLM restriction policies:
# HKLMSYSTEMCurrentControlSetControlLsaMSV1_0

# AuditReceivingNTLMTraffic = 2 (audit all NTLM incoming)
# RestrictReceivingNTLMTraffic = 1 (allow only for domain accounts)
# AuditNTLMInDomain = 7 (enable auditing of NTLM in the domain)

# Enable auditing mode first (before enforcement)
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "AuditReceivingNTLMTraffic" -Value 2 -Type DWord

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

Auditing NTLM Usage

Before restricting NTLM, audit its usage to identify applications and services that rely on it. Enable NTLM auditing via Group Policy and collect the Operational event logs:

# Enable the NTLM operational event log channel
wevtutil sl "Microsoft-Windows-NTLM/Operational" /e:true

# Query the NTLM operational log for recent events
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 100 |
    Select-Object TimeCreated, Id, Message |
    Where-Object {$_.Id -in @(8001,8002,8003,8004)} |
    Format-List

Key NTLM audit event IDs: 8001 (outgoing NTLM blocked), 8002 (outgoing NTLM pass-through blocked), 8003 (incoming NTLM blocked), 8004 (domain NTLM blocked). Events in the Security log: 4776 (DC validated credentials via NTLM).

# Find all NTLM validation events on DCs (Event 4776)
Get-WinEvent -LogName Security -FilterHashtable @{
    Id = 4776
    StartTime = (Get-Date).AddDays(-7)
} | ForEach-Object {
    $xml = [xml]$_.ToXml()
    [PSCustomObject]@{
        Time = $_.TimeCreated
        Account = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "TargetUserName"} |
            Select-Object -ExpandProperty "#text"
        WorkStation = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "Workstation"} |
            Select-Object -ExpandProperty "#text"
        ErrorCode = $xml.Event.EventData.Data | Where-Object {$_.Name -eq "Status"} |
            Select-Object -ExpandProperty "#text"
    }
} | Group-Object Account | Sort-Object Count -Descending

Creating NTLM Exceptions (Allowed List)

When restricting NTLM, you can create exception lists for servers that legitimately require it. Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Network security: Restrict NTLM: Add server exceptions in this domain:

# Add exceptions via registry (servers exempt from NTLM restriction)
# HKLMSYSTEMCurrentControlSetControlLsaMSV1_0ClientAllowedNTLMServers
$exceptions = @("LEGACYAPP01","LEGACYAPP02.contoso.com")
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "ClientAllowedNTLMServers" `
    -Value $exceptions `
    -Type MultiString

Configuring Session Security

Require NTLMv2 session security to enable message signing and sealing, which provides integrity and confidentiality for NTLM authenticated sessions:

# Network security: Minimum session security for NTLM SSP based clients
# Require NTLMv2 session security + Require 128-bit encryption
# Registry: HKLMSYSTEMCurrentControlSetControlLsaMSV1_0NtlmMinClientSec
# Value: 537395200 (0x20080000) = NTLMv2 + 128-bit

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "NtlmMinClientSec" -Value 537395200 -Type DWord

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "NtlmMinServerSec" -Value 537395200 -Type DWord

Blocking NTLM for Specific Scenarios

# Block NTLM entirely for incoming connections on a specific server
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" `
    -Name "RestrictReceivingNTLMTraffic" -Value 2 -Type DWord
# Value 2 = Deny all incoming NTLM traffic

# View all current NTLM restriction settings
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsaMSV1_0" |
    Select-Object NtlmMinClientSec, NtlmMinServerSec,
    RestrictReceivingNTLMTraffic, AuditReceivingNTLMTraffic

Summary

Configuring NTLM authentication on Windows Server 2012 R2 is primarily a security hardening exercise. The key actions are enforcing NTLMv2 only via the LAN Manager Authentication Level policy, enabling NTLM audit logging before implementing restrictions, identifying applications that depend on NTLM, creating exception lists for legitimate use cases, and then gradually restricting NTLM starting with the most sensitive systems. The long-term goal for most organisations should be eliminating NTLM where possible in favour of Kerberos, as Kerberos provides mutual authentication, is not vulnerable to relay attacks, and is more efficiently designed for domain environments.