Find unsigned LDAP binds before requiring signing

Bottom line: Requiring LDAP signing on Windows directory servers rejects SASL binds that do not request integrity and simple binds sent over an unprotected connection. Microsoft warns that dependent clients stop working. Use directory events to discover and remediate those clients before enforcement.

Source fact: what Microsoft documents

Microsoft’s LDAP signing guide explains that unsigned LDAP traffic is susceptible to replay and man-in-the-middle modification. A directory server configured to require signing rejects unsigned SASL binds and LDAP simple binds performed over a non-SSL/TLS connection.

Microsoft documents Event ID 2887 as a daily summary when such binds are detected but permitted. More detailed LDAP Interface Events logging can produce Event ID 2889 with the client IP address and attempted identity for each problem bind. When the server rejects problem binds, Event ID 2888 summarizes rejected attempts. The page recommends configuring clients to stop using the unsafe bind patterns and observing an extended period without detection before requiring signing. It includes Group Policy, AD LDS, and ldp.exe verification procedures.

What the source does not establish

One quiet domain controller does not prove the forest is ready. Rare monthly jobs, disaster-recovery systems, isolated networks, load-balanced directory clients, or applications pointed at another server may be missed. LDAP signing provides integrity; it is not the same as TLS encryption or LDAP channel binding. An IP address in an event does not identify the application owner, and a successful bind does not prove least-privilege directory access.

Applicability questions

• Which AD DS domains, read-only domain controllers, AD LDS instances, sites, and network segments receive LDAP?
• Which applications, appliances, physical-security products, scripts, and service accounts bind to them?
• Does each client use signed SASL, simple bind over TLS, unsigned SASL, or cleartext simple bind?
• Does the observation period include month-end, certificate renewal, failover, recovery, and dormant integrations?
• Is LDAP channel binding being assessed separately where TLS and applicable authentication are used?

DSE recommendation: controlled next steps

The following steps are DSE recommendations based on the cited source.

1. Enable the documented discovery logging on all relevant directory servers for an approved, time-bounded period and protect the resulting identity and IP data.
2. Map every problem bind to an application, owner, identity, server, bind type, business purpose, and supported remediation.
3. Configure clients for signed SASL or an appropriately protected TLS path according to vendor support. Correct certificate trust and name validation where TLS is used.
4. Observe an extended clean period that covers low-frequency workloads, then stage the server requirement with rollback criteria.
5. Monitor rejected-bind events and application health after enforcement; do not permanently weaken the server for an unidentified client.

Verification and evidence

• Preserve discovery scope, logging level, observation dates, event exports, and client-remediation register.
• Record successful vendor-supported bind tests after remediation without exposing credentials.
• Use the documented negative test to prove an unsigned simple bind is rejected after enforcement.
• Confirm all directory servers have the intended effective policy and no unexpected rejection events persist.

Official references

• How to enable LDAP signing in Windows Server — Microsoft