Stop NTLM relay: LDAP, SMB signing and LLMNR

NTLM relay remains one of the most reliable paths to domain compromise because so many AD environments still permit unsigned LDAP binds, unsigned SMB, and legacy name resolution protocols that leak credentials to anyone listening on the local segment. None of the fixes here require new infrastructure — they are registry values, Group Policy settings, and audit logging you can enable this week. This guide covers locking down LDAP and SMB signing, killing LLMNR/NBT-NS, and retiring NTLMv1, with verification steps and a clear list of what breaks.

Why LLMNR and NBT-NS enable NTLM relay

LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) let Windows hosts resolve names when DNS fails, by broadcasting a request to the local subnet. Any host on that segment can answer — there is no authentication on the response. An attacker who answers these broadcasts induces the victim to authenticate to them with NTLM, capturing a hash or relaying the live authentication attempt to a target service such as LDAP or SMB. Turning off both protocols removes the easiest credential-harvesting foothold in most internal penetration tests.

Disable LLMNR

Group Policy path:

Computer Configuration > Policies > Administrative Templates > Network > DNS Client
  Turn Off Multicast Name Resolution: Enabled

Equivalent registry value:

HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
  EnableMulticast (DWORD) = 0

Disable NBT-NS

NBT-NS has no native GPO toggle; disable it per adapter via WMI, ideally pushed with a startup script or scheduled task so it survives new NICs:

# Disable NetBIOS over TCP/IP on all adapters (0 = default/enable via DHCP, 1 = enable, 2 = disable)
Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True" |
    ForEach-Object { $_.SetTcpipNetbios(2) }

Verification:

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient" -Name EnableMulticast
Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled=True" |
    Select-Object Description, TcpipNetbiosOptions

LDAP signing and LDAP channel binding

Unsigned LDAP binds allow an attacker to relay a captured NTLM authentication straight into an LDAP session on a domain controller, often enough to add themselves to a privileged group or read confidential attributes. Two independent settings close this: LDAP server signing (LDAPServerIntegrity) and LDAP channel binding (LdapEnforceChannelBinding), the latter closing the LDAPS/TLS-specific relay path that signing alone does not cover.

Set on every domain controller:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
  LDAPServerIntegrity (DWORD) = 2   ; 1 = None, 2 = Require signing

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
  LdapEnforceChannelBinding (DWORD) = 2   ; 0 = Never, 1 = When supported, 2 = Always

Both can be pushed via a GPO registry preference targeting the Domain Controllers OU, or set directly:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name LDAPServerIntegrity -Value 2
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name LdapEnforceChannelBinding -Value 2

Find non-compliant clients before enforcing

Before setting LDAPServerIntegrity to require signing, enable diagnostic logging on the DC and review the Directory Service event log for a rollout window (two to four weeks is typical):

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" -Name "16 LDAP Interface Events" -Value 2

Watch for these Directory Service event IDs, which identify exactly which clients and services are binding without signing or channel binding:

Get-WinEvent -LogName "Directory Service" | Where-Object { $_.Id -in 2887,2889,3039 } |
    Select-Object TimeCreated, Id, Message | Format-List

Only move LDAPServerIntegrity and LdapEnforceChannelBinding to their enforcing values (2) once events 2889 and 3039 stop firing, or the remaining sources are accepted exceptions. See LDAP channel binding for the mechanics of how binding ties the LDAP session to the TLS channel.

SMB signing

SMB relay works the same way as LDAP relay: a captured NTLM authentication is replayed against a file server or, worse, a domain controller's SMB stack. Requiring SMB signing means a relayed session fails integrity checks and is dropped.

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
  Microsoft network server: Digitally sign communications (always): Enabled
  Microsoft network client: Digitally sign communications (always): Enabled

Registry equivalents:

HKLM\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
  RequireSecuritySignature (DWORD) = 1

HKLM\SYSTEM\CurrentControlSet\Services\LanManWorkstation\Parameters
  RequireSecuritySignature (DWORD) = 1

Apply to domain controllers first (they are the highest-value relay target), then workstations and file servers in a phased rollout. Verify:

Get-SmbServerConfiguration | Select-Object RequireSecuritySignature
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature

Auditing and restricting NTLM

Rather than disabling NTLM outright — which breaks anything that hasn't migrated to Kerberos — use the Restrict NTLM audit-then-enforce workflow.

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
  Network security: Restrict NTLM: Audit NTLM authentication in this domain: Enable all
  Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers: Audit all

Audit events (IDs 8001-8004) land in the Microsoft-Windows-NTLM/Operational log, not the System log. Review for a full business cycle, build an allow list of services that legitimately still need NTLM, then move from Audit to Deny for everything else:

Network security: Restrict NTLM: NTLM authentication in this domain: Deny all
Network security: Restrict NTLM: Add server exceptions in this domain: <legacy app servers>

Disable NTLMv1

NTLMv1 is cryptographically weak and should be disabled outright; only NTLMv2 needs to remain available as a fallback for equipment that can't yet reach Kerberos.

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
  Network security: LAN Manager authentication level: Send NTLMv2 response only. Refuse LM & NTLM

Registry:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa
  LmCompatibilityLevel (DWORD) = 5

Verify:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" -Name LmCompatibilityLevel

What it breaks

• LDAP signing/channel binding: older network scanners, printers/MFDs with embedded LDAP address-book lookups, some backup and monitoring appliances, and third-party identity bridges that bind without signing. Events 2886-2889 identify these before you enforce.
• SMB signing: very old SMBv1-only NAS devices and some industrial/embedded systems; signing overhead also has a minor throughput cost on high-volume file transfer over slow links.
• LLMNR/NBT-NS disablement: environments still relying on NetBIOS name resolution for legacy flat-name lookups (pre-DNS applications, some line-of-business software) may see intermittent name resolution failures — check DNS coverage first.
• LmCompatibilityLevel = 5: any device or application hardcoded to NTLMv1, typically very old copiers, some SCADA/ICS gear, and unpatched non-Windows SMB clients.

For related hardening, see Kerberos hardening and Domain controller hardening. Background on the relay technique itself is covered at NTLM relay.