LDAP Signing Not Required on Domain Controllers Allows Unsigned Binds

Symptom

Domain controllers accept LDAP binds that are not signed, and nothing in normal operation reports it.

Directory lookups, application logins and scripts all work, so there is no outage to prompt a review. The only sign is a policy value that does not enforce signing, and, if diagnostic logging is raised, Directory Service events that name clients making unsigned binds.

False assumption

The common belief is that a working, domain-joined estate is already protected, or that signing is on because Windows clients usually support it. Supporting signing is not the same as the server requiring it. Unless the domain controller policy says Require signing, a client may choose not to sign and the bind still succeeds.

Root cause

The domain controller LDAP server signing requirement is not set to Require signing, so unsigned simple and SASL binds are accepted. Unsigned binds can be relayed by an attacker positioned between a client and the directory. The setting is documented by Microsoft, but confirm the exact policy name, registry value and version-specific defaults in the official Active Directory documentation listed in the sources, as defaults have differed between Windows Server releases.

Impact

The impact is exposure of directory operations to relay and tampering, with risk rated high because domain controllers are central to identity. Enforcing without preparation has its own impact: any client that cannot sign will have its binds rejected, which breaks the applications that depend on it.

Diagnosis

Diagnosis uses read-only evidence first. Check the effective policy on each domain controller, then look for Event ID 2889 in the Directory Service log, which records clients making unsigned binds, including the client address and identity. Microsoft documents that this event depends on raising the LDAP Interface Events diagnostic level, so confirm the supported procedure and any log volume implications in the vendor documentation before changing it. Build a list of distinct client addresses and owners over a representative period that covers batch jobs and month-end activity.

Correction

Correct the clients first, then the server. Reconfigure each listed application or appliance to use signing, LDAPS or StartTLS as its vendor supports, or retire it. Once the 2889 events stop for a sustained period in an isolated or non-production environment, set the domain controller policy to Require signing through Group Policy, one controlled scope at a time. Confirm product version and permissions before applying the change. Stop immediately if previously working applications begin failing binds.

Validation

Validation passes when the effective policy shows Require signing on every domain controller, no new Event ID 2889 entries appear, and each previously listed application still authenticates. Also test one deliberately unsigned bind from a test client and confirm it is refused.

Rollback

Rollback means reverting the Group Policy setting to its previous recorded value and allowing policy refresh on the affected domain controllers. Record the original value before the change. Keep the revert as a short, pre-approved step so a broken dependency can be restored quickly while the client is fixed, accepting that exposure returns until re-enforcement.

Prevention

Keep the setting in a baseline that is audited regularly, require new applications to support signed or encrypted LDAP before onboarding, and review Event ID 2889 on a schedule. The next safe decision is to inventory unsigned clients before any enforcement change.