LDAP signing and channel binding: closing the door on relay attacks against your DCs
Domain controllers still often accept unsigned LDAP binds. That is exactly what NTLM relay attacks exploit to create accounts, change delegations or grant themselves rights. Two settings, rolled out properly, neutralise most of that risk.
The attack scenario
An attacker coerces a machine or user into authenticating to them, then relays that NTLM authentication to the LDAP service of a domain controller. If the DC does not require signing, the relayed session is accepted with the victim's rights. With a server or administrator account, the attacker can, for example, configure resource-based constrained delegation or modify ACLs. Over LDAPS, signing does not apply in the same way: channel binding is what stops relay, by tying authentication to the TLS session.
The two protections
| Protection | Policy setting | What it blocks |
|---|---|---|
| LDAP signing | Domain controller: LDAP server signing requirements | Unsigned SASL binds and clear-text simple binds over LDAP (port 389) |
| Channel binding | Domain controller: LDAP server channel binding token requirements | Authentication relay to LDAPS (port 636) |
Channel binding accepts three values: Never, When supported, Always. On clients, "Network security: LDAP client signing requirements" should at least negotiate signing. Recent Windows Server versions have tightened defaults for new deployments; do not assume your existing DCs benefit from them, and check the effective configuration.
Finding non-compliant clients
The Directory Service log on domain controllers is the reference source:
- 2886: warns that signing is not required;
- 2887: daily summary of the number of insecure binds;
- 2889: details of each insecure bind, with the client IP address and the account used;
- 3039, 3040, 3041: channel binding related information.
Event 2889 is only logged once the "16 LDAP Interface Events" diagnostic level is raised to 2 in the DC registry. That level generates volume, so enable it for the duration of the collection.
The usual suspects. Multifunction printers, network appliances, Java applications or older libraries using simple binds on port 389. Most of them support LDAPS or signing: a configuration change is often all it takes.
Rollout plan
- Enable LDAP diagnostic logging on every DC and collect 2889 events for several weeks.
- Fix each identified client: switch to LDAPS, enable signing, update.
- Set channel binding to "When supported" and monitor the related events.
- Require LDAP signing on domain controllers.
- Move channel binding to "Always" once the last clients are fixed.
What an audit checks
- the effective LDAP signing requirement on each DC;
- the channel binding configuration;
- 2887 or 2889 events showing insecure binds;
- consistent LDAP client policies across workstations and servers.