LDAP Security Deep Dive Guide: Signing, Channel Binding and Safe Binds

Most directories still accept LDAP binds that can be read, replayed or relayed on the network, and the applications that depend on them are rarely inventoried. Unsigned SASL binds, simple binds over port 389 and LDAPS sessions without channel binding all give an attacker on the network path a way to steal a password or relay an authentication into the directory. This guide goes deeper than the general Active Directory hardening material: it explains the bind types defined in RFC 4513, the exact Microsoft settings for LDAP signing and channel binding, how to audit before you enforce, and how to make the service binds used by applications, appliances and scripts safe. It is written for directory engineers, identity architects and the people who own the applications that bind to AD, AD LDS or OpenLDAP.

Key takeaways

• Know which bind is which. RFC 4513 separates anonymous, unauthenticated and name/password simple binds from SASL binds, and only some of them protect the credential or the session.
• Signing and channel binding solve different problems. Signing protects SASL binds on port 389; channel binding ties an LDAPS session to the authentication so it cannot be relayed through someone else's TLS tunnel.
• Audit first, enforce second. Events 2887, 2889, 3074 and 3075 tell you exactly which clients will break before you turn on enforcement.
• Service binds are non-human identities. The accounts that applications use to bind need an owner, least privilege, an encrypted channel and rotation, like any other service account.
• Windows Server 2025 changes the defaults, upgrades do not. New deployments require signing and audit channel binding out of the box, but upgraded domains keep whatever they had before.

LDAP bind types and why they matter

A bind is the LDAP operation that sets the authentication state of a connection. RFC 4513 defines the mechanisms and their security properties, and most directory weaknesses trace back to accepting the wrong one.

Two points from the standard are worth holding on to. First, RFC 4513 section 2 says implementations SHOULD disallow name/password binds by default when suitable data security is not in place, and section 6.3.3 requires servers to support a policy that rejects them with confidentialityRequired. Second, StartTLS adds no security of its own (section 6.2): the protection comes from TLS, and the client MUST verify the server's identity against its certificate (section 3.1.3). A client that accepts any certificate gets encryption without authentication, which an on-path attacker can terminate.

The ports in normal use are 389 (LDAP, optionally upgraded with StartTLS), 636 (LDAPS, TLS from the first byte) and, in Active Directory, 3268 and 3269 for the global catalog in clear and TLS form. For how the TLS layer itself works, see the How TLS Works Guide.

LDAP signing in Active Directory

LDAP signing applies integrity protection to SASL binds on port 389, so a relayed or modified bind fails. It also causes the domain controller to reject simple binds over a connection that is not protected by TLS. Microsoft controls it with two security options, both under Computer Configuration, Policies, Windows Settings, Security Settings, Local Policies, Security Options.

Microsoft's own verification test is simple: run ldp.exe, connect to a domain controller on port 389 without TLS and attempt a simple bind. With signing enforced the bind fails with "Strong Authentication Required". The AD LDS registry change takes effect without a restart.

Windows Server 2025 changed the starting point. Microsoft documents that new Active Directory deployments require LDAP signing by default through the "Domain controller: LDAP server signing requirements enforcement" policy, with channel binding set to "When supported", client encryption set to "Preferred" and channel binding auditing on. Upgrade installations keep their existing LDAP settings, so a domain that has been in place since Windows Server 2012 does not become safer just because the newest domain controller runs 2025. Check the effective policy, not the operating system version.

LDAP channel binding and Extended Protection

Signing does not help on LDAPS, because the TLS session already provides integrity. The weakness there is different: an attacker who can make a victim authenticate to them with NTLM can open their own TLS session to the domain controller and relay the authentication into it. Channel binding, part of Extended Protection for Authentication (EPA), puts a value derived from the TLS channel into the authentication so the domain controller can tell that the authentication was made for a different tunnel. This is the specific defence against relaying NTLM to LDAPS; see the NTLM Relay Guide for the wider relay picture.

KB4520412 defines the control:

• Policy: "Domain controller: LDAP server channel binding token requirements", added in March 2020.
• Values: Never, When supported, Always, which map to LdapEnforceChannelBinding = 0, 1 and 2 (DWORD) under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
• When supported: rejects clients that are capable of channel binding but send a wrong token, and still allows old clients that send nothing. A client counts as capable if EPA is present and not disabled through SuppressExtendedProtection.
• Always: rejects every LDAPS bind without a valid channel binding token, which breaks clients that cannot send one.
• Defaults: Microsoft's updates added the setting and the audit events but did not change the default policy on existing domain controllers.

Audit events: find the clients before you break them

The directory tells you who will fail. These events are written to the Directory Service log with source Microsoft-Windows-ActiveDirectory_DomainService.

Event 2889 is not written by default. Set the diagnostic logging category 16 LDAP Interface Events to 2 (basic) on each domain controller, under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics, then collect the events centrally. Turn the level back down once the inventory is complete, as it is noisy in large estates. Audit events 3074 and 3075 were added in 2023 updates for Windows Server 2019 and 2022.

Rolling out signing and channel binding

1. Inventory: enable category 16 logging, collect 2887, 2889, 3074 and 3075 for at least one full business cycle (month end and quarter end jobs bind too), and map each client IP to an application and owner.
2. Fix clients: move each application to LDAPS with certificate validation, or to a SASL bind with signing (Kerberos via GSSAPI is the usual choice on Windows). Replace or isolate appliances that support neither.
3. Set clients first: push "Network security: LDAP client signing requirements" to Negotiate signing so Windows clients sign whenever the server supports it.
4. Pilot on one domain controller: set server signing to Require signing and channel binding to When supported on a single domain controller in a site where you can steer test traffic, and watch 2888 and 3039.
5. Enforce widely: apply to all domain controllers through the Default Domain Controllers Policy. Keep a short exception list for isolated legacy systems with a named owner and an end date.
6. Move to Always: once 3074 is quiet, set channel binding to Always.
7. Rollback: the rollback is the reverse policy change (signing to None, channel binding to When supported or Never), which takes effect after policy refresh. Document it, but treat a rollback as an incident with a fix date, not a permanent state.

For the surrounding domain hardening programme, see the Active Directory and Entra ID Hardening Guide.

Safe service binds

The bind that matters most in practice is not a user at a workstation: it is the account a VPN concentrator, a web application, a printer, an HR system or a Linux host uses to search the directory and check passwords. These are non-human identities with long-lived credentials, and they are often configured once and never revisited. See the Service Account Security Guide.

Choosing a bind method

Controls for every service bind

• Dedicated account: one bind account per application, never a shared "ldapbind" account and never a person's account.
• Least privilege: most applications need only read access to specific attributes in specific OUs. Do not grant write, password reset or group management unless the application provably needs it, and never add a bind account to a privileged group.
• Certificate validation: confirm the application validates the server certificate chain and hostname. A "trust all certificates" checkbox turns LDAPS into a relay opportunity.
• Credential storage and rotation: keep the bind password in a secrets manager, not in a configuration file, and rotate it on a schedule and on staff changes. Bind passwords in files are a recurring find (ATT&CK T1552.001 Credentials In Files).
• Restrict use: deny interactive logon for bind accounts and, where the directory supports it, restrict the hosts the account can be used from.
• Reject empty passwords in the application: an empty password produces an unauthenticated bind that many servers will accept. RFC 4513 asks clients to disallow empty passwords in name and password interfaces, and the OWASP LDAP Injection Prevention Cheat Sheet makes the same point for login forms.
• Escape input: applications that build search filters from user input must escape filter characters (RFC 4515) and DN characters separately. A valid bind does not stop filter injection.

Non-Microsoft directories: OpenLDAP and AD LDS

The same principles apply outside Active Directory, with different switches. For OpenLDAP, the administrator's guide documents these slapd options:

• disallow bind_anon: turns off anonymous bind, which is on by default.
• require authc: needed in addition, because disabling anonymous bind alone does not stop anonymous directory access.
• allow bind_anon_cred: enables unauthenticated binds (name, empty password). It is off by default and the guide advises keeping it off, because some applications send unauthenticated binds when they meant to authenticate.
• security simple_bind= and security ssf=1 update_ssf=112: require confidentiality for simple binds and set minimum security strength factors for operations and updates.
• Password storage: hashed schemes such as {SSHA} for userPassword, never clear text.

For AD LDS, use the LDAPServerIntegrity value per instance as shown above and apply the same LDAPS and service bind controls.

Detection and measurement

Attacks against LDAP usually show up as relay attempts, password guessing through simple binds, and bulk reconnaissance. Useful detections include 3039 spikes (possible relay), simple binds from unexpected IP addresses using bind accounts, failed bind bursts across many accounts (ATT&CK T1110.003 Password Spraying, see the Password Spraying and Credential Stuffing Defence Guide), and unusually broad searches for users and groups (T1087.002 Domain Account). Relay itself sits under T1557 Adversary-in-the-Middle, and capture of clear-text binds under T1040 Network Sniffing.

Metrics that show the programme is working:

• Unsigned and clear-text binds per day: the 2887 count across all domain controllers, trending to zero.
• Channel binding readiness: distinct clients raising 3074 or 3075, trending to zero before Always.
• Enforcement coverage: percentage of domain controllers with Require signing and channel binding at When supported or Always.
• Bind account hygiene: percentage of bind accounts with a named owner, least privilege review in the last 12 months and a rotated credential.
• Exceptions: number of legacy exceptions open past their end date.

Framework mapping

In ISO/IEC 27001:2022 Annex A the same work falls mainly under A.8.5 Secure authentication, A.8.20 Networks security and A.8.15 Logging.

Common failure patterns

• Enforcing without the inventory: signing is switched on after a penetration test finding, a month end batch job fails, and the setting is rolled back for good. Collect 2889 events through a full business cycle first.
• LDAPS without certificate validation: the application uses port 636 but trusts any certificate, so the password is still exposed to whoever sits in the middle.
• Channel binding left at Never: signing is enforced on 389 and the team assumes LDAP is done, while NTLM can still be relayed to 636.
• Over-privileged bind accounts: a VPN or wiki bind account sits in Domain Admins or Account Operators "because the wizard needed it", so a stolen appliance configuration becomes a domain compromise. The Ivanti Connect Secure exploitation in 2024 showed how credentials and service accounts held by an edge appliance become an attacker's next step.
• Blank passwords treated as success: an application binds with the user's DN and whatever password was typed, and accepts the unauthenticated bind that results from an empty field.
• Assuming upgrades fix defaults: a new Windows Server 2025 domain controller joins an old domain and inherits its weak policy.

Practitioner checklist

• Enable 16 LDAP Interface Events at level 2 on every domain controller and collect 2887, 2889, 3039, 3074 and 3075 centrally.
• Map every client in 2889 and 3074 to an application and a named owner.
• Set "Network security: LDAP client signing requirements" to Negotiate signing across clients, then Require signing where possible.
• Pilot "Domain controller: LDAP server signing requirements" at Require signing on one domain controller, then enforce on all.
• Set the channel binding token policy to When supported, then Always once 3074 is quiet.
• Move every service bind to Kerberos, gMSA, LDAPS with validated certificates or SASL EXTERNAL; remove simple binds on 389.
• Review every bind account for ownership, least privilege, interactive logon denial and credential rotation from a secrets manager.
• Disable anonymous and unauthenticated binds on OpenLDAP and AD LDS, and confirm applications reject empty passwords.
• Track the five metrics above monthly and close legacy exceptions by their end date.

Standards and references

• IETF: RFC 4513 LDAP Authentication Methods and Security Mechanisms
• Microsoft: LDAP channel binding and LDAP signing requirements for Windows (KB4520412)
• Microsoft Learn: How to enable LDAP signing in Windows Server
• Microsoft Learn: LDAP signing and channel binding in Windows Server
• OpenLDAP: Administrator's Guide, Security Considerations
• OWASP: LDAP Injection Prevention Cheat Sheet
• NIST: SP 800-53 Rev. 5
• MITRE ATT&CK: Adversary-in-the-Middle

Related NHI Mgmt Group resources: Active Directory and Entra ID Hardening Guide · NTLM Relay Guide · Kerberos Security Guide · Service Account Security Guide · RADIUS Security Guide