Security on an LDAP connection: Bind, SASL, LDAPS, signing, and channel binding

1. Core mechanism

This lesson follows RFC 4511 §4.2 for the BindRequest alternatives simple [0] and sasl [3]. It distinguishes session types because TLS, SASL security layers, and channel binding do not apply identically to every bind. Microsoft KB4563239 is the session-specific reference: TLS provides signing/integrity for the LDAPServerIntegrity requirement; CBT is relevant to SASL authentication over TLS, while TLS simple bind has no CBT and depends on sound client certificate validation. Policy values and diagnostic events are checked against Microsoft KB4520412 and the dedicated LDAP signing guidance.

Interfaces and specifications

• simple bind: BindRequest authentication=simple [0] OCTET STRING carries credentials, commonly a password; TLS simple bind has no CBT (RFC 4511 §4.2; KB4563239).
• SASL bind: authentication=sasl [3] SaslCredentials carries a mechanism and credentials, for example Negotiate, Kerberos, NTLM, or Digest (RFC 4511 §4.2).
• TLS/LDAPS: port 636 starts TLS on connect; StartTLS can protect a connection on port 389. A properly validated TLS session protects transport confidentiality and integrity.
• LDAPServerIntegrity: LDAPServerIntegrity=2 requires signing for applicable unsigned sessions. TLS provides signing/integrity and satisfies this requirement; for non-TLS SASL, the client must request signing or sealing.
• SASL signing and sealing: SASL can provide LDAP message integrity and confidentiality on a non-TLS session, depending on the mechanism and negotiated protection.
• Channel binding (CBT): for SASL authentication over TLS, CBT cryptographically binds the authentication context to the TLS session; it does not apply to TLS simple bind (KB4563239).
• Policy values: LDAPServerIntegrity (None=1, Require Signing=2) and LdapEnforceChannelBinding (Never=0, When Supported=1, Always=2) under NTDS\Parameters (KB4520412).

Bind is the answer to the question 'who are you'

LDAP Bind is the authentication step in which the client identifies itself to the server (RFC 4511 §4.2). A simple bind carries credentials in the simple [0] OCTET STRING choice; a SASL bind carries a mechanism and credentials in the sasl [3] choice.

A bind succeeding does not say which protections were active. A simple bind over a connection without TLS exposes its password; TLS simple bind protects the transport but does not use CBT. A SASL bind may negotiate signing or sealing, depending on its mechanism and session type.

Different session protections: TLS, SASL signing/sealing, and CBT

TLS/LDAPS protects the transport. With correct server-certificate validation, it provides confidentiality and integrity and meets the LDAPServerIntegrity requirement. SASL signing provides LDAP-message integrity on applicable non-TLS SASL sessions; SASL sealing can add confidentiality, depending on the mechanism. CBT serves a different purpose: for SASL authentication over TLS, it binds the authentication context to that TLS session and helps prevent relay across TLS channels (KB4563239).

Do not apply the CBT rule to every bind. Microsoft states that TLS simple bind adds no CBT; in that session type, the TLS client’s certificate-name and revocation checks matter. For TLS+SASL authentication, including the documented NTLM case, channel binding is the separate control against a relay between TLS sessions.

Controls to turn this on at AD

On AD domain controllers, the “Domain controller: LDAP server signing requirements” policy corresponds to LDAPServerIntegrity (None=1, Require Signing=2). For TLS sessions, the TLS channel supplies signing/integrity; for non-TLS SASL sessions, Require Signing rejects a bind that does not request signing. Cleartext simple binds are rejected when signing is required (KB4520412; KB4563239).

The “Domain controller: LDAP server channel binding token requirements” policy maps to LdapEnforceChannelBinding (Never=0, When Supported=1, Always=2). It governs applicable SASL authentication over TLS and has no effect on TLS simple bind (KB4563239). The current Microsoft Learn default guidance says new Windows Server 2025 deployments require signing by default and set CBT to When Supported; upgrades preserve existing policy. Defaults therefore depend on deployment history—inspect the target DC’s effective policy.

Why this distinction determines relay

Relay analysis must identify the session type. For SASL/NTLM authentication over TLS, TLS encrypts and protects the transport, but CBT is needed to bind that authentication context to the specific TLS session. For a non-TLS SASL bind, signing or sealing protects session integrity/confidentiality. A cleartext simple bind exposes the password. These are distinct cases, so “TLS is on” is not a complete assessment.

Record the target DC’s effective signing and channel-binding policies, the client bind type and mechanism, whether TLS certificate validation succeeds, and the relevant diagnostic events. The next NTLM relay lesson builds on this distinction.

State and data flow

1. The client connects on LDAP port 389 or establishes TLS on 636/3269, or uses StartTLS on a supported port.
2. The client sends a BindRequest: simple [0] with credentials, or SASL [3] with a mechanism and credentials.
3. For a non-TLS SASL session, signing or sealing may be negotiated. For a TLS+SASL session, CBT may be included; TLS simple bind does not use CBT.
4. LDAPServerIntegrity=2 requires protection for applicable unsigned sessions: it rejects unsigned non-TLS SASL and cleartext simple binds. TLS itself provides signing/integrity and satisfies the requirement.
5. LdapEnforceChannelBinding=2 (Always) requires a valid CBT for applicable SASL authentication over TLS; it has no effect on TLS simple bind.
6. Diagnostic evidence is session-specific: 2887 summarizes accepted unsigned non-TLS binds, 2888 summarizes rejected attempts, 2889 identifies a client when diagnostic level 2+ is enabled, and 3039 reports CBT validation failure.

2. Exploitation

Broken trust assumption

The broken assumption is that TLS alone binds every LDAP authentication to the TLS session and therefore blocks relay.

Technical prerequisites

• An attacker can intercept or induce an authentication attempt and relay it to an LDAP endpoint.
• For a non-TLS SASL relay path, the target does not require signing and the client does not negotiate SASL signing/sealing.
• For a TLS+SASL/NTLM relay path, CBT is not required or the client does not provide a valid token under the effective policy.
• The mechanism and target accept the relayed authentication; assess the target DC and the exact bind type.
• A separate cleartext-simple-bind risk exists on a connection without TLS: the password is exposed. TLS simple bind has no CBT and relies on proper TLS server-certificate validation.

Exploitation mechanism

The relay path depends on session type. An unsigned non-TLS SASL bind may be accepted when signing is not required; a cleartext simple bind exposes its password. In a TLS+SASL/NTLM session, TLS protects the channel, but without a valid CBT the authentication context may be relayed over another TLS session. TLS provides signing/integrity for LDAPServerIntegrity, yet that alone does not channel-bind the SASL authentication. TLS simple bind is a separate case: no CBT is added, so the client must validate the server certificate correctly.

Each control turns off a different gate

Do not stop the relay assessment at “TLS is enabled.” Record whether the bind is simple or SASL, whether the SASL mechanism is NTLM, whether signing/sealing applies, whether TLS certificate validation succeeds, and whether the applicable TLS+SASL session has CBT.

State the result conditionally: an unsigned non-TLS SASL bind, a TLS+SASL/NTLM session without required CBT, and a cleartext simple bind are different findings with different impacts.

Version and policy change the result

The same attempt can produce different results across DCs because effective policies, operating-system version, and deployment or upgrade history can differ. The bind type also determines which policy is applicable: TLS satisfies LDAP signing integrity, while CBT applies to SASL authentication over TLS and not TLS simple bind.

Report the effective policy and observed session details for the target DC. Do not infer a result from another server’s defaults.

3. Defense & Detection

Telemetry scope

• Events 2886–2889 and CBT diagnostic events are recorded in the Directory Service log under the Microsoft-Windows-ActiveDirectory_DomainService provider; they are diagnostic events, not Security-log auditing.
• Event 2887 is a 24-hour summary of accepted unsigned SASL binds without TLS and simple binds over cleartext. Event 2888 is the 24-hour summary for rejected attempts. Event 2889 reports a client making such an unsigned bind and requires “16 LDAP Interface Events” diagnostic level 2 (Basic) or higher (KB4520412; Microsoft LDAP signing guidance).
• CBT event meanings differ: 3039 reports an LDAP-over-TLS bind that failed CBT validation; 3040 counts unprotected LDAP binds over the previous 24 hours when CBT policy is Never and at least one completed; 3041 is a reminder when policy is Never (KB4520412).
• Events 3074/3075 help assess CBT compatibility: 3074 reports a bind that would fail because its CBT is malformed; 3075 reports a CBT-capable client that supplied no CBT. They require LDAP Interface Events level 2+ and CBT policy When Supported or Always. Availability depends on Windows Server version and installed updates (KB4520412).

Events and relevant fields

• Event 2889 is a Directory Service diagnostic from Microsoft-Windows-ActiveDirectory_DomainService. The documented message includes client IP/port, attempted identity and Binding Type: 0 means an unsigned SASL bind; 1 means a simple bind over cleartext.
• The consulted references describe rendered event fields, not a named raw EventData schema. The synthetic artifact therefore uses unnamed Data items and does not invent XML field names.
• Event 2887 is a 24-hour summary without per-client detail; 2889 provides client detail when LDAP Interface Events diagnostic level 2+ is enabled. Event 2888 is the summary for rejected unsigned-bind attempts (KB4520412 and LDAP signing guidance).

Reading the diagnostic log

Events 2886–2889 and CBT events are Directory Service diagnostics, not Security-log audit events. Event 2889 requires LDAP Interface Events diagnostic level 2 or higher and can create substantial volume, so use it as a bounded compatibility view.

Use 2887/2889 to find unsigned non-TLS binds, and interpret CBT events according to their own trigger conditions: 3039 is validation failure, 3040 is the unprotected-bind daily count under Never, and 3041 is a reminder under Never. Remediate clients before enforcing stricter policy.

For 3074/3075, Windows Server 2022 received CBT auditing in August 2023 and Windows Server 2019 in October 2023. The initial manual enablement step was removed by the November 14, 2023 update for Server 2022 and January 9, 2024 update for Server 2019. LDAP Interface Events level 2+ and When Supported or Always still matter. These events help identify clients that need attention before stricter enforcement; they do not replace application testing.

Detection logic · XPath

*[System[(EventID=2889 or EventID=2887)]]

Query assumptions

• The statement selects events 2889 and 2887 in the log Directory Service; provider Microsoft-Windows-ActiveDirectory_DomainService is assumed.
• 2889 is generated only when LDAP Interface Events diagnostic level 2+ is on; This is a diagnostic log, not a security audit.
• Unsigned binds do not produce 2889 if diagnostics are not on; 2887 gives only a summary. The absence of an event does not prove that there is no unsigned bind.
• The query was not run on the actual Windows DC or SIEM; There is no dataset, volume and baseline.

False positives

• Outdated or incorrectly named structure, but legitimate applications may routinely produce unsigned/simple bind performing 2887/2889.
• Since there are 2889 diagnostic logs, they can be high volume and impact DC performance; It is not recommended to leave it on all the time (Microsoft, dd941849).
• A single 2889 means incompatible client, not malicious intent; It is an expected signal during the migration period.
• The 2887 counter does not tell which client is responsible; Additional correlation is required for source identification.

Hardening

• Inventory unsigned non-TLS binds with 2887/2889. For CBT, distinguish validation failure (3039), the Never-policy count/reminder (3040/3041), and compatibility signals (3074/3075). Check version, update, diagnostic level and policy conditions before treating an absent event as evidence of compatibility.
• Fix or retire incompatible clients, then stage signing and CBT enforcement. Validate application behavior before moving to Require Signing and Always.
• Map the requested policy values to the intended state: LDAPServerIntegrity=2 (Require Signing), LdapEnforceChannelBinding=2 (Always). CBT Always governs applicable TLS+SASL sessions, not TLS simple bind.
• Disable cleartext simple binds; use TLS with correct server-certificate validation where simple bind remains necessary.
• Event 2889 can be high-volume and affect DC performance; enable the detailed diagnostic level for a bounded compatibility investigation, then return it to the required operational level.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-ActiveDirectory_DomainService"/><EventID>2889</EventID><Channel>Directory Service</Channel><Computer>DC01.outreason.example</Computer></System><EventData><Data>192.0.2.55:52310</Data><Data>OUTREASON\svc-legacy</Data><Data>0</Data></EventData></Event>

Two reality checks

Assumption: An encrypted LDAPS connection makes bind type irrelevant.

In fact: Bind type still determines which controls apply. TLS meets LDAPServerIntegrity. Channel binding applies to SASL authentication over TLS, while TLS simple bind carries no CBT. For simple bind over TLS, the client must correctly validate the server certificate; changing the CBT policy does not add a token to that bind.

Assumption: LDAP signing and channel binding perform the same check.

In fact: LDAP signing protects message integrity. Channel binding ties SASL authentication to its underlying TLS session. Neither the policy name nor a successful bind alone proves which protection was used; read the bind mechanism and transport together.

Sources

• RFC 4511 · LDAP: The Protocol
  §4.2 Bind Operation; BindRequest simple [0]/sasl [3] AuthenticationChoice and SaslCredentials.
• Microsoft · LDAP signing for AD DS on Windows Server
  Default security behavior, upgrade considerations and Event monitoring: the current October 2, 2026 page describes 2889 as per-client unsigned/cleartext bind detail.
• Microsoft · 2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements (KB4520412)
  Policy values; diagnostic event Tables 1–3; 3074/3075 requirements and August/October 2023 introduction, November 2023/January 2024 enablement changes.
• Microsoft · LDAP session security settings after ADV190023 (KB4563239)
  TLS simple bind has no CBT and TLS meets LDAPServerIntegrity; LdapEnforceChannelBinding applies to TLS+SASL sessions.
• Microsoft · LDAP Interface Events (Event 2889, archived)
  Event 2889 source and rendered client IP/port and attempted identity fields; cross-checked with KB4520412 and KB 935834.
• Microsoft · How to enable LDAP signing (KB 935834)
  Event 2889: Information level, rendered client IP/port, identity and Binding Type (0 unsigned SASL; 1 simple); diagnostic level 2 and daily summaries.
• Microsoft · Configure firewall for AD domains and trusts
  LDAP 389 and LDAP SSL 636 port distinction.
• Microsoft · LDAP channel binding on Windows Server
  Supported authentication methods and event conditions: TLS+SASL versus TLS simple bind; 3039/3074/3075 policy and update requirements.