Windows Server 2025 LDAP hardening: validate signing and channel binding before enforcement

Short answer: requiring LDAP signing rejects simple binds without TLS and SASL binds without signing or sealing outside TLS. Simple bind over TLS satisfies the server signing requirement and is unaffected by LdapEnforceChannelBinding. SASL authentication over TLS is the relevant channel-binding case: Always requires a valid channel-binding token (CBT). Prove compatibility with successful directory transactions against a known, enforcing domain controller—not just an application login or a quiet event log. Microsoft: LDAP session security

Windows Server 2025 requires LDAP signing by default for new AD deployments and defaults channel binding to When Supported. Upgrades preserve existing LDAP security policies. These are documented product behaviors, not a newly announced September 2026 change. Check the policies actually applied in your environment. Microsoft: LDAP signing overview

A source conflict matters here. Microsoft's overview associates simple bind over TLS with CBT and gives event descriptions that conflict with its detailed guidance. This article follows the session-security guidance, updated February 12, 2026, for transport and authentication behavior, and KB4520412 for event meanings and collection prerequisites. In particular, neither 2889 nor 3041 proves a successful protected connection. Session-security guidance · KB4520412

Classify connections by transport and authentication

Include LDAP on ports 389/636 and Global Catalog connections on 3268/3269. TLS can begin immediately on 636/3269 or be established through StartTLS on 389/3268. Record whether StartTLS actually completed before authentication; the port alone does not establish protection.

These distinctions follow Microsoft's session-security guidance. Validate server certificates on TLS connections, including trust and hostname checks. A client that negotiates signing and supplies CBT when supported still needs testing under the intended policy.

Inventory individual application connections, including libraries, service accounts, scheduled tasks, remote sites, recovery nodes, and failover destinations. Treat the work as part of Active Directory security, with its evidence and exceptions recorded in Reporting and risk.

Establish policy and logging prerequisites

Export effective settings from every DC serving in-scope connections, including read-only domain controllers (RODCs). Record the GPO whose settings take precedence. Keep any AD LDS instances in a separate scope.

On Windows Server 2025, Domain controller: LDAP server signing requirements enforcement overrides Domain controller: LDAP server signing requirements. Enabled enforces signing; Disabled defers to the older policy. Changing only the older policy may therefore leave enforcement unchanged. For managed Windows clients, Network security: LDAP client signing requirements offers Negotiate signing as a migration setting: it requests signing when the server supports it. Verify application behavior afterward. Microsoft: Group Policy configuration

The CBT policy is Domain controller: LDAP server channel binding token requirements, corresponding to LdapEnforceChannelBinding:

• Never (0): no CBT validation.
• When Supported (1): permits clients without CBT support, but validates applicable CBT-capable authentication. Invalid tokens, or missing tokens from clients considered capable, can cause rejection.
• Always (2): requires valid CBT for applicable authentication over TLS.

When Supported is not a universally nondisruptive audit mode. Test that transition before applying it broadly. These settings do not make CBT applicable to simple bind over TLS. Microsoft: KB4520412

Record each DC's OS build and installed updates. KB4520412 identifies March 2020 updates as the baseline for the older CBT events. For 3074/3075 without the former manual enablement step, use Windows Server 2022 with November 14, 2023 or later updates, or Windows Server 2019 with January 9, 2024 or later updates. Windows Server 2025 also supports these audit events. Microsoft: update history · Windows Server 2025 features

Set 16 LDAP Interface Events under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics to 2 or higher for detailed collection. Microsoft states that 3039, 3074, and 3075 require When Supported or Always. Do not interpret their absence under Never as compatibility evidence. Microsoft: KB4520412

Interpret events correctly

Use the detailed definitions and diagnostic fields in KB4520412, alongside Microsoft's unsigned-client discovery instructions. Read the complete event and effective policy together; an event number alone cannot establish compatibility.

For this validation procedure, verify logging with controlled test traffic using a dedicated test account. Record the expected event, its appearance in the local Directory Service log, and its arrival in the collection system. Check timestamps, retention, and filters. If an expected event is missing, resolve the collection gap before interpreting production silence. Use connection and application telemetry for paths whose event coverage has not been demonstrated, including Global Catalog and StartTLS connections.

For each test, retain the source host, application owner, account identity, actual destination DC, destination port, authentication method, TLS or SASL protection, certificate-validation result, effective policies, event references, transaction, and outcome. Mark CBT not applicable where appropriate. A successful transaction and an absence of failure events are separate observations.

Test enforcement on explicitly selected DCs

The following is a proposed rollout procedure. Server enforcement applies to the DC and affects connections reaching it; assigning a service owner does not scope a DC policy. Microsoft: Group Policy configuration

1. Build the baseline. Collect across every DC serving the defined scope for a representative business cycle. Exercise infrequent jobs and recovery paths separately. Assign owners and remediation actions to incompatible connections.
2. Prepare an isolated test environment or explicitly selected pilot DCs. Document exactly which DC computer accounts receive the GPO and every client that can reach those DCs. If that population cannot be bounded safely, use the isolated environment first.
3. Control destinations. Configure test clients to use the selected DCs and constrain their test network paths so they cannot silently fall back to permissive DCs. Preserve certificate hostname validation. Record the actual destination for every connection, including referrals and failover tests. A transaction completed through an unexpected DC does not pass.
4. Change one control at a time. Test signing enforcement, then the intended CBT setting. Repeat directory lookups, authentication, group resolution, scheduled jobs, and restart or password-change workflows relevant to each service.
5. Prepare rollback before the change. Record the exact previous values of both signing policies, the CBT policy, and any changed client policy, plus GPO scope and test routing. Name the rollback operator and affected clients. Restore the recorded settings and verify their effective state if a critical transaction fails. On Server 2025, changing only the older signing setting may not undo enforcement.

Intentional policy differences between pilot and nonpilot DCs must have a documented scope and expiration. Unexpected differences are a reason to stop expansion.

Use this compact validation matrix with dedicated test credentials and valid authentication otherwise:

For each row, record the effective policy and actual destination DC for both outcomes. Repeat applicable rows across LDAP and Global Catalog paths and direct TLS and StartTLS paths in scope. CBT is not applicable to the non-TLS rows or to simple bind over TLS. The expected results derive from Microsoft's session-security guidance.

Require resolution before expanding enforcement

Every incompatible in-scope dependency must be remediated and retested, retired, or technically excluded from the enforcement scope through a documented arrangement. Naming an owner is insufficient. A network boundary does not exempt a connection from the receiving DC's signing or CBT requirements.

For an exclusion, document the actual endpoint and routing restrictions, remaining exposure, owner, expiration, and removal plan. Demonstrate that the dependency cannot reach enforcing DCs and that pilot tests cannot use its permissive path. Report it as an exclusion, not a compatibility success.

Proceed only when logging is verified, unexplained failures are resolved, applicable positive and negative tests pass, and every critical service path has succeeded against the intended enforcing DCs. Stop expansion for a critical transaction failure, an unresolved incompatible bind, an unexpected destination, or an unexplained policy or certificate change.

After rollout, repeat representative transactions and review rejected-bind activity. Keep policy exports, connection inventory, exclusions, test results, and rollback records together. This provides evidence for the tested scope and observation period; it cannot establish compatibility for an untested seasonal job or an offline recovery node.

FAQ

Does LDAPS satisfy the server signing requirement?

Yes: TLS satisfies that requirement without requiring separate LDAP message signing. This also applies to successfully established StartTLS. SASL over TLS remains subject to CBT policy; simple bind over TLS does not. Certificate validation still matters. Microsoft: session-security guidance

Why did an upgrade leave the previous behavior in place?

Windows Server 2025 upgrades preserve existing LDAP security policies. Review effective settings rather than assuming the defaults for new deployments were applied. Microsoft: LDAP signing overview

What evidence supports a decision to enforce without disrupting services?

Verified logging, an inventory of actual connections, resolved incompatibilities, successful service transactions against enforcing DCs, rejected negative controls, and tested rollback. State any exclusions and coverage limits explicitly. This supports a bounded rollout decision; it does not guarantee that every future connection will succeed.