Directory authentication often looks like a single event: a client connects, presents credentials, and receives a result. Active Directory treats the transport, the bind method, and the integrity of the session as separate concerns. LDAP signing protects messages in a SASL session that does not use TLS. Channel binding ties the authentication exchange to the TLS session on the connection. A team that enables one control and assumes the other is covered can leave a gap.

Microsoft's current guidance describes LDAP signing as cryptographic signing of LDAP messages to verify authenticity and integrity during SASL sessions that do not use TLS. It also recommends SASL with Kerberos for LDAP authentication. Channel binding cryptographically ties SASL authentication to the TLS session, which helps prevent an attacker from relaying an authentication exchange into a different connection.

Simple binds and cleartext exposure

A simple bind sends a password to the server. Without TLS, the password and the session can be exposed to network interception. With TLS, the channel is encrypted, but the authentication exchange still needs an appropriate identity and authorization model. LDAP signing does not encrypt a simple bind, and channel binding does not repair a client that sends credentials to the wrong server.

Administrators should inventory clients before enforcing stricter policy. Old appliances, monitoring agents, applications, and scripts may use unsigned SASL binds or fail to negotiate a channel binding token. A staged rollout should collect the relevant directory-service events, identify the client accounts and hosts, fix or retire the clients, and then move the domain controller policy to the required setting.

What each control adds

LDAP signing gives the server evidence that a SASL message was not modified in transit and that the sender participated in the signing operation. Channel binding gives the server evidence that the authentication exchange is tied to the expected TLS channel. Neither control authorizes a user to read a directory object. Access control, group scope, and service-account ownership remain separate decisions.

This distinction is useful during incident review. A signed session can still use an overprivileged account. A channel-bound session can still be initiated by a compromised endpoint. A valid Kerberos ticket can still be replayed within its validity window if the service and client do not enforce the expected constraints. The controls reduce specific relay and integrity risks; they do not replace least privilege or endpoint security.

Rollout plan

Start with a read-only audit of domain controllers and a representative sample of clients. Confirm which protocols and ports are in use, whether LDAPS is available, and which applications depend on simple binds. Test changes in a pilot domain or a controlled set of domain controllers. Keep a rollback path that is documented and time-bounded, but do not make rollback the permanent state.

Monitor authentication failures by client and account. A burst of failures after policy enforcement is an operational signal, not proof of an attack. Check certificate trust, time synchronization, service principal names, and proxy behavior. If a client cannot support the required protocol, move it behind a controlled application gateway or replace it.

Evidence to retain

Record the policy change, the domain controller scope, the client population, the test cases, and the observed failures. Store directory-service events with the identity, source address, bind method, and policy result where available. Protect those logs from modification and correlate them with endpoint inventory.

LDAP signing and channel binding are mature controls, but they are often discussed as a single checkbox. Treating them as separate session protections makes the rollout more accurate and the remaining risk easier to explain.

References