LDAP and LDAP Signing in Active Directory: Channel Binding, Relay, and Hardening

1. Introduction

The Lightweight Directory Access Protocol (LDAP) is how virtually everything in a Windows environment reads and writes Active Directory: logon processes, management tools, line-of-business apps, and attackers performing reconnaissance all speak LDAP to a domain controller. Because LDAP can carry credentials and can be used to modify directory objects, an unauthenticated or unsigned LDAP channel is a direct path to credential theft via relay and to stealthy enumeration. Enforcing LDAP signing and channel binding is one of the highest-value, lowest-cost hardening steps in AD.

2. How It Works

LDAP is a query/modify protocol against the directory’s hierarchical database. A client binds (authenticates), then performs searches, adds, modifies or deletes subject to its permissions.

LDAP        (389/tcp)  cleartext transport, optional signing/sealing via SASL
LDAPS       (636/tcp)  LDAP wrapped in TLS (certificate on the DC)
GC / GC-SSL (3268/3269) Global Catalog equivalents

Bind types:

• Simple bind: username + password sent in the request. Over plain 389 this is effectively cleartext — dangerous.
• SASL bind (Negotiate/Kerberos/NTLM): supports signing and sealing, protecting integrity and confidentiality even over 389.
• Anonymous bind: no credentials; historically allowed limited reads.

LDAP signing adds a cryptographic integrity check (via SASL) so the request cannot be tampered with or relayed. LDAP channel binding (CBT) ties the authentication to the specific TLS channel of an LDAPS connection, so an authentication captured on one channel cannot be replayed onto another — this is the specific defence against LDAPS relay.

3. The Security Problem

By default many domains historically permitted unsigned simple binds and did not enforce channel binding. That means: (1) credentials in simple binds over 389 can be captured passively, and (2) an attacker who coerces a machine or user into authenticating can relay that NTLM authentication to a domain controller’s LDAP/LDAPS service and, if signing/CBT is not enforced, perform privileged directory writes — for example granting themselves rights or configuring delegation. LDAP is also the enumeration engine behind attack-path mapping tools, because read access to the directory reveals users, groups, ACLs, SPNs and trusts.

4. How Attackers Abuse It

LDAP relay (concept): Combine a coercion technique that forces a privileged machine account to authenticate with a relay to the DC’s LDAP service. Without enforced signing (for 389) or channel binding (for 636), the DC accepts the relayed session and the attacker acts with the victim’s privileges — a known path toward configuring Resource-Based Constrained Delegation on a target computer object.

Reconnaissance (concept): Even a low-privileged, read-only bind lets an attacker pull the full object graph for offline analysis. This is normal-looking traffic, which is why volume and breadth of queries matter more than any single query for detection.

In an authorized test, the assessor confirms whether the DCs enforce signing and CBT by attempting a benign signed vs unsigned bind in a lab, then reports the exact policy gaps.

5. How to Detect It

Command

Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=2889} -MaxEvents 100 | Select-Object TimeCreated, Message

What it does: Reads Event 2889 from the Directory Service log, which each DC logs when a client performs an unsigned or simple LDAP bind (when the diagnostic is enabled).

What to look for: The client IP and account in each 2889 event — these are the callers that will break when you enforce signing, and the ones to fix first.

Defensive use: Gives you a precise remediation list before flipping enforcement, so you do not cause outages.

Command

$dc = 'dc01.corp.local'; (Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "LDAPServerIntegrity" -ErrorAction SilentlyContinue).LDAPServerIntegrity

What it does: Reads the LDAPServerIntegrity value that controls LDAP signing enforcement on a DC (run locally on the DC or via remoting).

What to look for: A value of 2 means “Require signing”; 1 means “None” (negotiated but not required) — the weaker, undesired state.

Defensive use: Confirms the effective enforcement level per DC so you can standardise across all of them.

Command

Get-ADObject -SearchBase (Get-ADRootDSE).configurationNamingContext -Filter "objectClass -eq 'nTDSService'" -Properties * | Select-Object dSHeuristics

What it does: Reads dSHeuristics, the flags string that (among other things) governs anonymous LDAP operations forest-wide.

What to look for: A 7th character of 2 enables anonymous binds — this should normally be off (default). Any non-default value deserves scrutiny.

Defensive use: Verifies anonymous LDAP is not silently enabled.

6. Relevant Group Policy Settings

• Domain controller: LDAP server signing requirements → set to Require signing.
• Domain controller: LDAP server channel binding token requirements → set to Always (after auditing with When supported).
• Network security: LDAP client signing requirements → set to Require signing on members.

7. How to Audit the Environment

• Enable “16 LDAP Interface Events” diagnostics on DCs so unsigned binds surface as Event 2889.
• Inventory every client/app performing unsigned or simple binds; work with owners to switch them to signed SASL or LDAPS.
• Confirm each DC has a valid certificate for LDAPS on 636.
• Verify channel binding is set to When supported first (audit), then Always.
• Confirm anonymous binds and unnecessary dSHeuristics flags are disabled.

8. How to Fix / Harden It

• Roll out Require signing and channel binding Always via GPO to all DCs after the audit window clears.
• Migrate legacy simple-bind apps to LDAPS (636) or signed SASL binds.
• Ensure DCs present valid TLS certificates; monitor expiry.
• Disable anonymous binds unless a documented, isolated need exists.
• Combine with SMB signing and NTLM restrictions — relay defence is only complete when all channels are covered.

9. Detection & Monitoring

• Event ID 2889 (Directory Service) — unsigned/simple binds, with client IP and identity.
• Event ID 2886/2887 — indicate the DC is not requiring signing and count of unsigned binds; 2888 confirms rejection once enforced.
• Event ID 3039/3040/3041 — channel binding audit/enforcement events.
• Behavioural: a single host issuing broad, high-volume LDAP searches across users, groups and ACLs suggests directory reconnaissance.

10. MITRE ATT&CK Mapping

Technique	ID
Adversary-in-the-Middle (relay to LDAP)	T1557
Account Discovery: Domain Account	T1087.002
Permission Groups Discovery: Domain Groups	T1069.002
Domain Trust Discovery	T1482

11. Practical Lab

In an isolated lab:

1. Enable LDAP Interface Events diagnostics on a lab DC and generate a simple bind from a test tool; confirm Event 2889 appears with the source.
2. Read LDAPServerIntegrity before and after applying the “Require signing” GPO and confirm the value changes to 2.
3. Set channel binding to When supported, review 3039 audit events, then move to Always.
4. Attempt an unsigned bind after enforcement and confirm it is rejected (Event 2888).
5. Document which lab “apps” broke, mirroring the production migration plan.

12. Key Takeaways

• Unsigned LDAP and missing channel binding are the enablers of LDAP relay to a DC — a fast path to privileged directory writes.
• Audit with Event 2889 first to find who breaks, then enforce Require signing and channel binding Always.
• LDAP is also the directory reconnaissance engine; watch for broad, high-volume read patterns.
• Relay defence must cover LDAP, LDAPS, SMB and NTLM together to be meaningful.

Continue learning: Active Directory security

This guide is part of our Active Directory Security series. Related guides:

• NTLM Authentication: Pass-the-Hash, Relay, and Why Enterprises Are Retiring It
• Kerberos in Active Directory: How It Works, How It Is Abused, and How to Defend It
• Active Directory Enumeration with BloodHound: A Beginner’s Guide