LDAP signing in Active Directory

LDAP signing has been part of Active Directory for years, yet most environments either misunderstand it or leave it unconfigured. Neither option will work anymore.

With Windows Server 2025 effectively requiring LDAP signing by default on domain controllers (DCs), organizations that have ignored this setting are about to feel it. Applications will break, authentication flows will fail, and troubleshooting will begin under pressure.

The smarter move is to have clear Active Directory visibility properly before enforcing it.

Let's walk through what LDAP signing actually is, how it differs from LDAPS and channel binding, what changed in Server 2025, and how to implement it without breaking production systems.

What is LDAP signing?

LDAP signing is an integrity protection mechanism applied to LDAP authentication requests. It uses Simple Authentication and Security Layer (SASL) to ensure that the authentication message sent from a client to a domain controller has not been tampered with.

The DC refuses unsigned authentication request when LDAP signing is required. The client must use a SASL mechanism, typically Kerberos or NTLM, that provides message signing. This guarantees that the authentication portion of the LDAP session is digitally protected.

How ever, LDAP signing does not encrypt the entire session. The rest of the LDAP communication may still travel in plaintext unless you’re using LDAPS. Signing protects the authentication exchange itself, not the entire data stream.

This distinction is where a lot of confusion begins.

LDAP signing operates over the standard LDAP ports:

• TCP 389 (LDAP)
• TCP 3268 (Global Catalog)

It does not require port 636. That's LDAPS, which is something different.

LDAP signing vs. LDAPS vs. channel binding

LDAP signing ensures the authentication request cannot be modified in transit. It protects integrity but does not encrypt the session.

LDAPS, on the other hand, wraps the entire LDAP communication inside a TLS session. Everything is encrypted. It typically uses:

• TCP 636 (LDAP over SSL/TLS)
• TCP 3269 (Global Catalog over SSL/TLS)

Channel binding is yet another layer. It ties the TLS tunnel to the authentication exchange to prevent credential relay attacks. In simple terms, it ensures that the authentication being performed is actually happening inside the same TLS session that was established.

Here's the practical takeaway:

• LDAP signing protects authentication integrity.
• LDAPS encrypts the entire session.
• Channel binding strengthens LDAPS against relay attacks.

If you are already using LDAPS, Active Directory considers the session signed. However, enabling LDAP signing still supports a defense-in-depth model and strengthens relay resistance. They are complementary, not competing, controls.

What changed in Windows Server 2025?

Windows Server 2025 introduces a significant behavioral shift.

A new policy called Domain controller: LDAP server signing requirements Enforcement is now available. When left unconfigured, the default behavior effectively translates to Require Signing.

This means new Windows Server 2025 DCs expect signed LDAP communication by default.

In earlier versions such as Server 2019 and 2022, the default was None, which allowed unsigned binds unless the client required signing.

Channel binding behavior has not changed. It is still disabled by default unless explicitly configured.

This change matters for organizations planning domain controller upgrades. If unsigned LDAP traffic still exists in your environment, upgrading DCs without auditing first can cause authentication failures.

Is LDAP signing enabled by default?

The answer depends on your server version.

On Server 2019 and 2022 DCs, LDAP signing is not required by default. The server will negotiate signing if the client requests it, but it does not enforce it.

On Server 2025 DCs, signing is effectively required unless explicitly disabled through policy.

On the client side, modern Windows systems typically default to Negotiate Signing, meaning they will sign if the server requires it.

The result is that older environments may appear functional while still allowing unsigned LDAP binds.

Why not enforcing LDAP signing is risky?

Unsigned LDAP traffic is vulnerable to manipulator-in-the-middle and relay-style attacks.

If an attacker can position themselves between a client and a domain controller, they can intercept authentication requests and potentially forward them to the DC. Without signing, there is no guarantee that the message hasn't been altered or replayed.

This class of attack has repeatedly been demonstrated and is directly tied to vulnerabilities like CVE-2017-8563 .

The traffic appears legitimate and the attacker is not brute-forcing passwords, which makes this especially dangerous. They are relaying valid authentication attempts. Requiring LDAP signing shuts down that path by refusing unsigned authentication exchanges.

How to check whether LDAP signing is enabled

Before changing anything, you need visibility.

On a domain controller, review the group policy setting:

1. Open Group Policy Management (gpmc.msc).
2. Locate the Group Policy Object applied to the Domain Controllers OU.
3. Right-click the GPO and select Edit.
4. In the Group Policy Editor, navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options.
5. In the right panel, locate Domain controller: LDAP server signing requirements.
6. Double-click the setting to view or modify its configuration.

Review whether it is set to:

• None
• Require signing

If running Server 2025, also review:Domain controller: LDAP server signing requirements Enforcement

You can confirm via the registry by checking the LdapServerIntegrity value under:HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

On client systems, review:Network security: LDAP client signing requirements

This setting determines whether the client requires, negotiates, or ignores signing.

The most common scenario in legacy environments is that neither side requires signing, even though both technically support it.

How to enable LDAP signing safely

This is not a setting you flip casually. The right way to implement LDAP signing begins with auditing.

First, enable LDAP diagnostic logging on DCs by increasing the 16 LDAP Interface Events registry value to two or higher. Once enabled, DCs will begin logging unsigned bind attempts.

You should monitor Event ID 2889, which identifies specific clients attempting unsigned LDAP binds and includes their source IP address. Events 2887 and 2888 provide additional summary and enforcement information.

Run this audit for at least 30 days. That window allows you to identify legacy applications, appliances, or Linux systems that may not support signed binds. Only after confirming that no insecure binds remain should you enforce signing through Group Policy.

On older DCs, set:Domain controller: LDAP server signing requirements = Require signing

On Server 2025 DCs, configure the legacy setting to None and enable the new Enforcement policy instead.

Roll out gradually. Start with a test OU. Validate application functionality before enforcing across the forest.

LDAP signing and Linux or Ubuntu systems

In mixed environments, Linux systems often authenticate using simple bind over LDAP or LDAPS.

If you enforce signing on port 389, simple binds will fail unless the application supports SASL mechanisms. Many non-Windows applications prefer LDAPS because it is simpler to implement across platforms.

In cross-platform environments, moving to LDAPS while enforcing signing on domain controllers provides stronger compatibility and security alignment.

Audit carefully. Storage arrays, network appliances, and legacy monitoring tools are frequent offenders.

Common reasons LDAP signing appears not enforced

Sometimes administrators enable signing but see no visible change.

Typical causes include:

• The GPO is not linked to the DCs OU.
• Group policy replication has not been completed.
• Clients are still configured to allow unsigned binds.
• DCs are running mixed versions with inconsistent policies.
• Policy changes were not confirmed using gpresult or RSOP.

Always validate effective policy on both client and server before assuming enforcement is active.

LDAP signing best practices

If you want a secure and future-ready Active Directory environment:

• Require LDAP signing on both clients and domain controllers.
• Enable LDAP channel binding, at minimum set to When Supported.
• Transition applications to LDAPS wherever feasible.
• Monitor Event IDs 2889, 3074, and 3075.
• Eliminate legacy systems that cannot comply.

Security hardening is not about a single checkbox. It's about reducing attack surface across multiple layers.

Strengthen LDAP signing with centralized AD governance using ADManager Plus

LDAP signing protects authentication integrity. But signing alone doesn't tell you whether the identities authenticating are over-privileged, inactive, or misconfigured.

ADManager Plus adds a governance layer on top of LDAP by providing centralized visibility into users, groups, delegated permissions, and privileged memberships across Active Directory.

Administrators can:

• Review privileged and nested group memberships to identify excessive or indirect administrative access.
• Migrate, manage and report on Group Policy Objects to ensure security policies are consistently configured across domain controllers.
• Detect inactive yet high-impact accounts that still retain elevated permissions.
• Analyze delegation exposure across OUs to prevent unintended administrative control.
• Generate audit-ready reports for compliance reviews for compliance and security reviews.

By combining LDAP signing enforcement with structured access reviews and privilege monitoring, organizations ensure that authentication requests are not just secure in transit, but aligned with least-privilege access policies.

Gain control over the identities LDAP relies on.

Explore now

FAQ

1. Is LDAP signing the same as LDAPS?

No. LDAP signing and LDAPS solve different problems.

LDAP signing protects the integrity of the authentication process over standard LDAP connections. LDAPS, on the other hand, encrypts the entire LDAP session using TLS.

Signing verifies that authentication messages are legitimate and unaltered. LDAPS encrypts all directory traffic. They are complementary security controls, not interchangeable ones.

2. What port does LDAP signing use?

LDAP signing operates over the standard LDAP ports:

• TCP 389 (LDAP)
• TCP 3268 (Global Catalog)

It does not require a separate transport layer. Unlike LDAPS, which uses ports 636 and 3269, LDAP signing enhances authentication security without changing the port.

3. Should I enable LDAP signing if I already use LDAPS?

Yes.

LDAPS encrypts the entire session, but LDAP signing adds an additional integrity check specifically for authentication. This strengthens protection against relay and man-in-the-middle attacks.

For a defense-in-depth approach, both LDAPS and LDAP signing should be enabled, especially in modern Active Directory environments.

4. How to Disable LDAP Signing in Windows Server 2025?

1. Open Group Policy Management (gpmc.msc).
2. Locate the Group Policy Object linked to the Domain Controllers OU.
3. Right-click the GPO and select Edit.
4. In the Group Policy Editor, navigate to Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options
5. Locate Domain controller: LDAP server signing requirements Enforcement.
6. Double-click the setting.
7. Set it to Disabled.
8. Click Apply, then OK.
9. Ensure it is set to: None. If this is set to Require signing, LDAP signing will still be enforced even if the new enforcement policy is disabled.