LDAP Signing and Channel Binding: Shutting Down NTLM Relay to Active Directory

Unsigned LDAP and missing channel binding let attackers relay coerced NTLM straight into Active Directory. Here's how to enforce both and audit your domain controllers.

Most Active Directory compromises don't start with a zero-day. They start with a domain controller that happily accepts an unsigned LDAP bind from anyone who can speak the protocol. Pair that with a coercion trick like PetitPotam or a poisoned name-resolution response, and an attacker doesn't need a single valid password — they relay someone else's NTLM authentication straight into your directory and start writing objects. LDAP signing and channel binding are the two controls that break that relay, and they remain unenforced on a surprising number of production DCs.

How the relay actually works

NTLM was never designed to prove which server a client meant to talk to. When a Windows host authenticates over NTLM, the challenge/response can be captured mid-flight by a machine-in-the-middle and replayed to a different service. The attacker's chain usually looks like this:

Coerce a privileged account — often a computer account like a DC or an Exchange server — into authenticating to an attacker-controlled host (PetitPotam, PrinterBug/SpoolSample, WebDAV coercion, or LLMNR/NBT-NS poisoning).
Relay that NTLM authentication to a domain controller's LDAP or LDAPS endpoint using a tool like ntlmrelayx.
Abuse the authenticated session: grant DCSync rights, add a computer with resource-based constrained delegation, or write msDS-KeyCredentialLink for shadow credentials.

The relay only succeeds because the LDAP session lacks integrity protection. Two settings close the gap.

Control 1: LDAP server signing

LDAP signing forces the client and DC to negotiate a signed session so the traffic can't be silently relayed or tampered with. The domain controller policy Domain controller: LDAP server signing requirements has three states: None, Negotiate signing, and Require signing. The registry value lives at:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
    LDAPServerIntegrity  (DWORD)
      1 = None / Negotiate (relay still possible)
      2 = Require signing

Set it to 2. Signing only protects unencrypted LDAP (port 389); it does not cover LDAPS (636), because a TLS wrapper looks encrypted but the underlying NTLM can still be relayed. That is exactly why the second control exists.

Control 2: LDAP channel binding

Channel Binding Tokens (CBT) cryptographically tie the NTLM authentication to the specific TLS channel it rides on. Relay the auth to a different TLS session and the token no longer matches, so the DC rejects it. This is the control that protects LDAPS. It is governed by:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
    LdapEnforceChannelBinding  (DWORD)
      0 = Never (vulnerable)
      1 = When supported (compatible, recommended stepping stone)
      2 = Always (strict)

Microsoft has shipped these as disabled by default for years to avoid breaking legacy clients, which is precisely why so many domains are still exposed. Value 1 enforces binding for every client that can do it while tolerating the stragglers, and value 2 refuses anything that can't. Start at 1, fix the clients that appear in your logs, then move to 2.

Roll it out without breaking logons

Before flipping to "require," turn on the diagnostic logging that tells you who would break:

Set 16 LDAP Interface Events to verbose under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics.
Watch the Directory Service log for Event ID 2889 (clients performing unsigned/unprotected binds) and 3039 (channel-binding rejections when enforcement is on).
Chase down each source IP: legacy Linux SSSD, old network appliances, vendor MFA connectors, and scanners are the usual offenders.

Enforce in a ring: enable diagnostics fleet-wide, remediate every 2889 source, set channel binding to "when supported," confirm the noise stops, then require signing and strict binding on every DC together. A half-enforced domain is still relayable through the weakest DC.

Defense in depth around the relay

Signing and channel binding kill the LDAP endpoint as a relay target, but a mature program also cuts off the coercion and the protocol itself: disable NTLM where you can, restrict inbound NTLM to servers, patch and disable the coercion surfaces (Print Spooler, EFSRPC/PetitPotam, WebClient), and enable SMB signing so those aren't relay targets either. The goal is that no single misconfiguration hands over the directory.

Where WinSentinel fits

WinSentinel audits all 64 modules on a machine for free, with no limits — and its directory and authentication checks flag exactly the state that makes relay possible: LDAPServerIntegrity not set to require signing, LdapEnforceChannelBinding left at 0, NTLM left unrestricted, and coercion-prone services still listening. You get the specific registry value, the risk, and the remediation on the box you're standing on.

For teams running a domain of controllers and member servers, WinSentinel Pro rolls those findings up across the fleet from a central node: it shows which DCs still accept unsigned binds, alerts when a rebuilt server drifts back to the insecure default, and tracks the "when supported → always" migration as a compliance metric instead of a spreadsheet. One relayable DC is a domain-wide problem, and fleet visibility is how you prove every one of them is closed.