NTLM Restriction and Auditing: How to Identify and Reduce NTLM in Your Active Directory Environment

NTLM audit mode logs NTLM usage without blocking it. Enable it everywhere before making any restrictions.

Group Policy path (apply to domain root or all OUs): Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Setting: Network Security: Restrict NTLM: Audit NTLM authentication in this domain

• Value: Enable all
• This generates Event ID 8003 on DCs for every NTLM authentication through the domain

Setting: Network Security: Restrict NTLM: Audit Incoming NTLM Traffic

• Value: Enable auditing for all accounts
• This generates Event ID 8003 on member servers for incoming NTLM (useful for identifying NTLM-using services)

Setting: Network Security: Restrict NTLM: Audit NTLM authentication to servers in this domain

• Value: Enable all
• Generates Event ID 8004 on DCs for authentication to domain servers

Increase the Security event log size on DCs:

# Increase DC event log to capture two weeks of NTLM audit events
WevtUtil sl Security /ms:1073741824  # 1 GB maximum log size

After two weeks of audit logging, query for NTLM events to build your inventory:

# Query NTLM audit events from a single DC
Get-WinEvent -ComputerName dc01 -FilterHashtable @{
    LogName = 'Security'
    Id = @(8003, 8004)
    StartTime = (Get-Date).AddDays(-14)
} | ForEach-Object {
    [PSCustomObject]@{
        Time        = $_.TimeCreated
        EventID     = $_.Id
        Client      = $_.Properties[0].Value  # Machine making NTLM request
        Domain      = $_.Properties[1].Value
        Server      = $_.Properties[2].Value  # Target server
        PackageType = $_.Properties[3].Value  # NTLM version
    }
} | Group-Object Client, Server, PackageType | Sort-Object Count -Descending |
    Select-Object Count, Name |
    Export-Csv C:\NTLM-Audit.csv -NoTypeInformation

Analyze the output:

• PackageType = NTLM V1: Immediate priority -- no modern app needs NTLMv1
• PackageType = NTLM V2: Document the client/server pair -- this is what will break when you restrict
• Client = a server (not a workstation): A server-to-server NTLM auth -- common for services with hardcoded credentials
• Server = a domain controller: NTLM auth to a DC itself -- should almost always be Kerberos

Common sources of NTLM in enterprise environments:

• Applications using Windows integrated auth with localhost as the target (Kerberos cannot be used for loopback; NTLM is used)
• Applications connecting by IP address instead of hostname (Kerberos requires hostname for SPN lookup; IP triggers NTLM)
• Old IIS applications using Windows Auth without SPN registration
• SQL Server linked servers using Windows Auth without proper SPN configuration
• Printers and scanners with NTLM authentication baked in

NTLMv1 can be blocked without significant compatibility risk in modern environments.

Group Policy path: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options

Setting: Network Security: LAN Manager authentication level

• Value: Send NTLMv2 response only; refuse LM and NTLM
• This is Level 5. It blocks NTLMv1 and LM authentication while allowing NTLMv2.
• Apply to all computers in the domain via a GPO at the domain root

Check current setting:

# Check LM compatibility level on an endpoint
(Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel).LmCompatibilityLevel
# 0 = LM and NTLMv1 allowed (extremely insecure)
# 3 = NTLMv2 only sent, LM and NTLMv1 accepted (Windows default before policy)
# 5 = NTLMv2 only, refuse LM and NTLMv1 (recommended)

Verify no NTLMv1 traffic after blocking:

# After applying the policy, check for any Event 8003 events with PackageType = 'NTLM V1'
# If they still appear, those machines are not receiving the GPO -- investigate
Get-WinEvent -ComputerName dc01 -FilterHashtable @{
    LogName = 'Security'; Id = 8003
} | Where-Object { $_.Properties[3].Value -like '*V1*' }

After blocking NTLMv1, progressively restrict NTLMv2 based on your audit inventory.

Stage 1: Block NTLM to domain controllers DCs should almost never need NTLM -- all DC authentication should be Kerberos. Computer Configuration > Security Settings > Local Policies > Security Options (Applied to Domain Controllers OU GPO)

• Network Security: Restrict NTLM: NTLM authentication in this domain: Deny for domain accounts
  • Start with: Deny for domain accounts to domain servers
  • Later: Deny all domain accounts

Stage 2: Block NTLM from specific servers that you have confirmed are clean Network Security: Restrict NTLM: Outgoing NTLM traffic to remote servers

• Value: Audit all (already done), then: Deny all
• Apply this to server OUs where you have verified all NTLM sources are remediated

Exception list for applications that cannot be remediated immediately: Network Security: Restrict NTLM: Add server exceptions in this domain

• Specify the server FQDN of servers that must receive NTLM (buys time for remediation)

Fix NTLM from IP-address connections:

# Find applications connecting by IP (NTLM indicator)
# Update connection strings from IP to hostname to enable Kerberos
# Ensure SPNs are registered for the service:
setspn -A HTTP/serverhostname domain\serviceaccount
setspn -L domain\serviceaccount  # Verify SPN registration