LDAP Signing and Why It Matters

LDAP signing is a security control that helps protect communication between LDAP clients and Active Directory domain controllers. It helps ensure that LDAP traffic has not been tampered with in transit and reduces exposure to certain man-in-the-middle and relay-style attacks.

In many Active Directory environments, LDAP is used constantly. Applications, servers, workstations, network appliances, and administrative tools may query domain controllers to look up users, groups, computers, and other directory objects. Because LDAP is so widely used, weak LDAP security settings can create broad exposure across the environment.

What is LDAP?

LDAP stands for Lightweight Directory Access Protocol. In Active Directory, LDAP is commonly used to query and interact with directory data, including users, groups, computers, organizational units, service accounts, and other objects.

Domain controllers commonly listen for LDAP traffic on:

Port	Purpose
389	LDAP
636	LDAPS, LDAP over TLS
3268	Global Catalog LDAP
3269	Global Catalog LDAPS

LDAP itself is not only an Active Directory concept. It is a protocol used by many directory services. In Microsoft environments, however, LDAP is one of the primary ways systems communicate with Active Directory.

What is LDAP signing?

LDAP signing adds integrity protection to LDAP communication. When LDAP signing is used, the LDAP messages are cryptographically signed so the receiving system can verify that the traffic was not modified in transit.

In simple terms LDAP signing helps prevent an attacker from silently modifying LDAP traffic between a client and a domain controller. It does not mean LDAP traffic is encrypted. Signing protects integrity. Encryption protects confidentiality. For encryption, LDAPS or StartTLS is typically used.

Why LDAP signing matters

LDAP is often used for authentication, authorization, application lookups, group membership checks, and administrative workflows. If LDAP traffic is not protected, attackers may be able to abuse insecure communication paths.

LDAP signing matters because it helps reduce the risk of:

• Man-in-the-middle tampering
• LDAP relay attacks
• Credential and authentication abuse paths
• Unsafe simple bind behavior
• Weak communication between legacy applications and domain controllers

This is especially important because domain controllers are among the most sensitive systems in an Active Directory environment. If an attacker can manipulate authentication or directory communication involving a domain controller, the impact can be significant.

LDAP signing vs LDAPS vs channel binding

These terms are often confused, but they are not the same thing.

Control	What it protects	Simple explanation
LDAP signing	Integrity	Helps prove LDAP messages were not modified
LDAPS	Confidentiality and transport security	Encrypts LDAP traffic over TLS
LDAP channel binding	Authentication binding to TLS channel	Helps prevent certain relay attacks against LDAPS
StartTLS	TLS upgrade for LDAP	Starts on LDAP and upgrades the connection to TLS

LDAP signing is focused on message integrity. LDAPS is focused on encrypted transport. LDAP channel binding helps tie authentication to the secure TLS channel and is especially relevant for LDAPS scenarios.

How attackers can abuse unsigned LDAP

Unsigned LDAP can become useful to attackers when they are positioned on the network and can intercept, relay, or manipulate authentication traffic.

A common concern is NTLM relaying. In relay scenarios, an attacker tricks or captures authentication from one system and relays it to another service. If the target service accepts the relayed authentication without requiring stronger protections, the attacker may be able to perform actions as the relayed identity.

LDAP is a particularly sensitive relay target because successful LDAP operations against a domain controller can potentially modify directory objects, depending on the privileges of the relayed account.

Examples of high-impact LDAP-related abuse may include:

• Modifying group membership
• Changing delegation-related attributes
• Creating or modifying computer accounts
• Writing attributes used for privilege escalation
• Abusing weak permissions on directory objects

The exact impact depends on the permissions of the relayed identity and the configuration of the environment.

How to check LDAP signing requirements

There are two major areas to review:

1. Domain controller LDAP server signing requirements
2. LDAP client signing requirements

Domain controller setting

The domain controller setting controls whether domain controllers require LDAP signing.

Group Policy path:

Computer Configuration
  Windows Settings
    Security Settings
      Local Policies
        Security Options
          Domain controller: LDAP server signing requirements

The recommended setting is Require signing

Microsoft documents this policy as Domain controller: LDAP server signing requirements and describes it as the setting that determines whether the LDAP server requires LDAP clients to negotiate data signing.

Client setting

The client setting controls whether Windows LDAP clients request or require signing.

Group Policy path:

Computer Configuration
  Windows Settings
    Security Settings
      Local Policies
        Security Options
          Network security: LDAP client signing requirements

Common values include:

Setting	Meaning
None	Client does not request LDAP signing
Negotiate signing	Client requests signing if supported
Require signing	Client requires LDAP signing

For most environments, the long-term goal should be to require signing where feasible, but this should be tested before broad enforcement.

PowerShell checks

You can review the configured LDAP server signing requirement on domain controllers using Group Policy analysis or local security policy review. In many environments, the effective setting is controlled by Group Policy, so reviewing the relevant GPOs is usually more reliable than checking only one domain controller locally.

To identify domain controllers:

Get-ADDomainController -Filter * |
    Select-Object HostName, Site, OperatingSystem

To review Group Policy settings, use the Group Policy Management Console or generate a report:

Get-GPOReport -All -ReportType Html -Path .\GPOReport.html

Then search the report for:

Domain controller: LDAP server signing requirements
Network security: LDAP client signing requirements

You can also use gpresult on a domain controller to review applied policy:

gpresult /h C:\Temp\dc-gpo-report.html

Event logs to monitor

Before enforcing LDAP signing, monitor for clients that may fail once signing is required.

Microsoft provides event logging guidance for LDAP signing and channel binding. These events can help identify clients using unsigned LDAP binds or clients that may not support the required protections.

Common event IDs associated with LDAP signing and channel binding visibility include:

Event ID	General purpose
2886	Indicates domain controller is not configured to require LDAP signing
2887	Summary count of unsigned LDAP binds
2888	Details about clients performing unsigned LDAP binds
3039	LDAP channel binding related event
3040	LDAP channel binding related event
3041	LDAP channel binding related event

However, the exact logging behavior can vary based on operating system version, patch level, diagnostic logging configuration, and policy settings.

What can break if LDAP signing is required?

Requiring LDAP signing can break clients or applications that rely on unsigned LDAP binds. This does not mean LDAP signing should be avoided. It means enforcement should be planned, tested, and monitored.

Systems to review before enforcement include:

• Legacy applications
• Network appliances
• Linux systems using LDAP integrations
• Printers and scanners
• VPN and remote access systems
• Identity management platforms
• Older third-party directory tools
• Custom applications
• Monitoring tools

Recommended rollout approach

A safe rollout usually looks like this:

1. Inventory LDAP clients
   • Identify systems communicating with domain controllers over LDAP.
2. Enable LDAP diagnostic logging
   • Monitor for unsigned binds and incompatible clients.
3. Review application dependencies
   • Identify legacy systems, appliances, and applications using LDAP.
4. Move simple binds to LDAPS or StartTLS
   • Avoid sending credentials over unprotected LDAP.
5. Test LDAP signing in a controlled scope
   • Start with a lab, pilot OU, or limited set of systems.
6. Remediate incompatible clients
   • Update applications, adjust LDAP libraries, configure LDAPS, or replace unsupported integrations.
7. Require LDAP signing on domain controllers
   • Enforce the domain controller policy once compatibility issues are resolved.
8. Continue monitoring
   • Watch for authentication failures, application issues, and LDAP-related events.

Common mistakes

Practical recommendation

LDAP signing should generally be required in mature Active Directory environments, but it should not be enabled blindly without first identifying LDAP clients and testing compatibility.

A good practical target is:

• Require LDAP signing on domain controllers
• Require or negotiate LDAP signing on clients
• Use LDAPS or StartTLS for simple binds
• Review LDAP channel binding requirements
• Monitor event logs for incompatible clients
• Remediate legacy applications instead of permanently weakening domain controller security

References

• Microsoft Learn: LDAP signing for Active Directory Domain Services
• Microsoft Learn: How to enable LDAP signing in Windows Server
• Microsoft Support: LDAP channel binding and LDAP signing requirements for Windows
• Microsoft Learn: Domain controller LDAP server signing requirements
• Microsoft Support: Frequently asked questions about LDAP signing and channel binding changes