.svg){kind=icon}
Newsletter
Stay up to date with our monthly newsletter.
Covering the latest thought leadership, events, and news about identity security
.svg)
What We Do
Partners
© MajorKey 2026
.svg)
Active Directory Domain Services relies heavily on Lightweight Directory Access Protocol (LDAP) for authentication, directory searches, and application integrations. However, not every LDAP connection is automatically protected against interception, modification, or authentication-relay attacks.
Two important controls help protect these connections:
These controls address different risks and should be evaluated separately.
LDAP relay attacks remain a common post-compromise technique because Active Directory (AD) is broadly trusted by applications, network devices, and identity systems. In these attacks, an adversary intercepts a network authentication request and forwards it to a domain controller over LDAP, potentially using the relayed identity’s permissions to perform directory operations. If successful, the attacker may be able to modify directory objects, escalate privileges, or gain unauthorized access without ever cracking the user’s credentials.
LDAP signing protects the integrity of LDAP communications. It allows the client and domain controller to verify that LDAP messages have not been altered while in transit.
When LDAP signing is required on a domain controller, the domain controller rejects:
This helps protect LDAP traffic from tampering, replay attacks, and man-in-the-middle (MitM) attacks.
LDAP signing does not necessarily mean that the connection is using Secure LDAP (LDAPS). Signed LDAP sessions can operate over the standard LDAP port, TCP 389, when supported SASL authentication methods such as Kerberos or Negotiate are used.
LDAP signing is primarily configured through two Group Policy settings:
Domain controller: LDAP server signing requirements
Network security: LDAP client signing requirements
In most environments, LDAP clients should be configured and tested before domain controllers are configured to require signing. Otherwise, legacy applications and devices may stop communicating with AD.
LDAP channel binding protects supported SASL authentication performed over a TLS connection by binding the authentication transaction to the TLS session. It does not apply in the same way to LDAP simple binds over TLS, because simple binds do not provide channel-binding information.
When a client establishes a TLS connection, it can provide a Channel Binding Token (CBT) as part of the authentication process. The domain controller verifies that the authentication request originated from the same TLS session the client originally established.
This helps prevent an attacker from intercepting authentication on one TLS session and relaying it over another.
LDAP channel binding can be configured with three general behaviors:
LDAP channel binding is configured through the following Group Policy setting: Domain controller: LDAP server channel binding token requirements
Organizations commonly begin with When supported while identifying older applications that do not support CBT.
LDAP signing, LDAP encryption, and LDAP channel binding are often confused with one another, but they are not the same.
Moving an application from unprotected LDAP on port 389 to LDAPS on port 636 is usually a substantial improvement. For LDAP simple binds, TLS provides encryption and satisfies the domain controller’s LDAP integrity requirement. However, simple binds over TLS do not provide channel-binding information. For SASL authentication over TLS, administrators must separately verify whether the client supports CBT and whether its authentication method satisfies the applicable signing and channel-binding requirements.
Administrators should therefore test the application’s actual bind method, certificate-validation behavior, and authentication flow before concluding that moving to LDAPS fully addresses LDAP security requirements.
In 2020, Microsoft introduced additional auditing and logging capabilities to help organizations identify insecure LDAP usage and prepare for stronger LDAP signing and channel-binding enforcement. While these changes increased visibility into unsigned binds and channel-binding issues, most existing AD environments retained backward-compatible behavior unless administrators explicitly enabled enforcement.
As a result, many organizations still have domain controllers that permit unsigned LDAP binds for compatibility with older applications.
Windows Server 2025 improves the default security posture for new AD deployments by requiring LDAP signing through the Domain controller: LDAP server signing requirements enforcement policy. Existing environments that are upgraded, however, retain their prior policy configuration, so an operating system upgrade alone does not enforce the stronger settings.
Active Directory domain controllers record events that can help identify insecure LDAP activity.
Common LDAP-signing event IDs include:
In many environments, Event ID 2887 provides the fastest initial indication that unsigned LDAP binds are still occurring. Event ID 2889 can then help identify the source IP address and account associated with those connections.
LDAP channel-binding monitoring can be performed using Directory Service events 3039, 3074, and 3075. Event 3039 identifies an actual CBT validation failure, while events 3074 and 3075 provide audit information about clients that would fail if stricter channel-binding enforcement were applied.
Be aware, however, that the availability of events 3074 and 3075 depends on the Windows Server version and installed updates. In addition, events 3039, 3074, and 3075 are generated only when channel binding is configured as “When supported” or “Always,” and the applicable LDAP Interface diagnostic logging level may need to be enabled.
Logging should be reviewed across all domain controllers. Looking at only one domain controller may miss applications connecting through another site, subnet, or DNS response.
A practical approach is:
Pay particular attention to older Java applications, Linux appliances, multifunction printers, network devices, and applications that use simple LDAP binds. These are often where long-forgotten LDAP dependencies emerge from whatever basement they have occupied since 2007.
LDAP signing, TLS encryption, and LDAP channel binding each play a distinct role in securing Active Directory communications. LDAP signing protects the integrity of LDAP messages, TLS protects the confidentiality of the connection, and LDAP channel binding helps prevent authentication-relay attacks by ensuring authentication remains tied to the correct TLS session. Organizations should audit existing LDAP usage, remediate incompatible applications, and then enforce the appropriate controls in stages. Windows Server 2025 provides stronger defaults for new deployments, but existing AD environments still require deliberate assessment and configuration.
If your organization has never reviewed LDAP signing and channel-binding settings, there is a reasonable chance that legacy applications are still relying on insecure LDAP behaviors. Auditing now provides an opportunity to remediate those dependencies before future security requirements force the change on your behalf. If you need assistance with this process or with your Active Directory environment, MajorKey's team can help.
Coming next: Securing LDAP in Microsoft Entra Domain Services
LDAP security requirements do not disappear when directory services move to the cloud. In our next post, we’ll examine how LDAP signing, LDAP channel binding, and secure LDAP work in Microsoft Entra Domain Services, including the key differences from traditional Active Directory Domain Services and what organizations should consider when planning a cloud-based directory strategy.
Learn why modern PAM strategies must extend beyond administrator accounts to include machine identities, cloud entitlements, Just-in-Time access, and Zero Standing Privilege. Dan Ross shares practical guidance for building a scalable privileged access program.
What C-suite leaders need to know about the upcoming Microsoft Entra ID SSPR changes, its operational risks, and how to mitigate them.
Auditors don’t just ask who has access today. Identity governance needs to be reframed as a continuous regulatory defense, not a periodic compliance exercise.
When effective change management is integrated with IGA implementations from the start, organizations reduce resistance, increase alignment, and ensure new identity processes take root in a sustainable, scalable way.
Learn about the challenges created by identity silos, the trade-offs between consolidation and governance, and how organizations can determine the most effective path forward.
Covering the latest thought leadership, events, and news about identity security