LDAP Channel Binding: Prevent LDAPS Relay Attacks
LDAP Channel Binding Disabled: Open Season for Relay Attacks
LDAPS encrypts LDAP traffic, but encryption alone doesn't stop a relay attack. Channel binding is the setting that ties the TLS session to the LDAP authentication attempt inside it, and without it, an intercepted session can be forwarded to a different domain controller as if nothing happened. Here is what channel binding actually protects against, how attackers take advantage of its absence, and how to enforce it across your domain controllers.
Quick Summary
LDAP channel binding protects LDAPS authentication from relay attacks by binding the authentication exchange to the TLS connection. When domain controllers do not enforce channel binding, an attacker may be able to relay captured NTLM authentication to LDAPS and perform Active Directory actions using the victim’s existing permissions.
| Priority | Moderate |
| Risk | A domain controller continues to accept an obsolete SMB protocol with known security weaknesses |
| Impact | Unauthorized Active Directory changes, privilege escalation, persistence, and potential domain compromise |
| Exploitation | Attackers can coerce or intercept authentication and relay it to LDAPS when the authentication and client configuration permit it |
| Fix | Require LDAP channel binding on domain controllers after identifying and remediating incompatible LDAP clients |
What Is LDAP Channel Binding?
LDAPS is LDAP over TLS. The TLS layer encrypts the connection, but on its own, TLS has no way of confirming that the LDAP authentication happening inside that encrypted tunnel is actually meant for the server on the other end.
Channel binding remediates this as it generates a cryptographic value from the TLS channel itself and requires the LDAP client to include that value as part of authentication. The domain controller checks it before accepting the bind. If an attacker relays the LDAP traffic to a different server, the channel binding value no longer matches, and the domain controller rejects the authentication attempt.
Microsoft began rolling out default channel binding enforcement in 2020, following a wave of LDAP relay attacks that combined poisoning techniques with unprotected LDAP authentication. The registry setting that controls this behavior, LdapEnforceChannelBinding, is not enforced by default on every domain controller, and plenty of environments never went back to turn it on after the initial rollout.
Microsoft recommends configuring the policy to Always after client compatibility has been validated, below are the three enforcement levels:
| Value | Policy | Behavior |
|---|---|---|
| 0 | Never | Channel binding is not validated |
| 1 | When Supported | CBT-capable clients must provide a valid token, but clients without support can still connect |
| 2 | Always | All applicable LDAPS clients must provide valid channel binding information |
How Disabled Channel Binding Poses a Risk
LDAPS is sometimes assumed to be secure simply because TLS is being used. TLS protects the confidentiality and integrity of the connection, but without channel binding it may not prevent authentication from being relayed through another encrypted connection.
Common risks include:
- LDAP relay attacks
An intercepted LDAPS session can be forwarded to a different domain controller, where the relayed authentication may succeed without channel binding to reject it. - Credential and session abuse
Relayed authentication lets an attacker act with the intercepted account’s privileges against a target they chose, not the one the original request was meant for. - Privilege escalation
If the intercepted session belongs to a privileged account or a service account with elevated rights, a successful relay can hand the attacker a path toward broader domain access. - False confidence from LDAPS
Teams that assume LDAPS alone is sufficient often haven’t verified that channel binding is actually enforced, leaving a gap that looks closed from the outside.
Real-World Context
Channel binding tends to fall into the same category as LDAP signing which is a setting most teams assume is already handled because LDAPS is in use. Microsoft’s 2020 guidance pushed many organizations to review LDAP signing, but channel binding didn’t always get the same attention, partly because it requires a registry change rather than a policy toggle most admins already know to check.
LDAP relay attacks usually become dangerous when several weaknesses overlap rather than because of one configuration in isolation. An attacker may first gain a foothold on an internal workstation, use name-resolution poisoning or an authentication coercion technique to cause another system to authenticate, and then relay that authentication to a service that accepts it. If LDAPS is available and channel binding is not enforced, the domain controller becomes a potential relay destination.
How Attackers Exploit Disabled Channel Binding
The attack is better understood as authentication relay than as intercepting and replaying ordinary LDAP packets.
A typical sequence looks like this:
- Gain internal network access
The attacker compromises a workstation, obtains VPN access, or otherwise reaches a network where domain authentication traffic is available. - Trigger or capture authentication
The attacker uses network poisoning, name-resolution abuse, or an authentication coercion technique to cause another system or user to authenticate. - Capture an NTLM authentication exchange
Rather than attempting to crack the credential, the attacker forwards the authentication toward another service. - Relay authentication to LDAPS
The attacker establishes a separate TLS connection to a domain controller and attempts to use the victim’s authentication within that connection. - Channel binding validation is absent
If channel binding is disabled, the domain controller does not require the authentication exchange to be cryptographically associated with the attacker’s TLS session. - Active Directory permissions are inherited
Successful authentication gives the attacker whatever LDAP permissions the relayed identity already possesses.
LDAP Channel Binding vs. LDAP Signing
LDAP signing and LDAP channel binding are related controls, but they solve different problems.
LDAP signing protects LDAP communications against tampering and certain man-in-the-middle attacks by requiring integrity protection for LDAP traffic. LDAP channel binding protects authentication performed over TLS by tying supported authentication to the TLS session.
| Control | Primary Protection |
|---|---|
| LDAP Signing | Protects LDAP traffic integrity, particularly LDAP authentication that is not protected by TLS |
| LDAP Channel Binding | Protects supported LDAP authentication over TLS from being relayed through a different TLS connection |
| LDAPS | Encrypts LDAP communications using TLS |
Enabling LDAPS does not eliminate the need for channel binding, and enabling channel binding does not eliminate the need to review LDAP signing.
How to Detect Disabled Channel Binding
LDAP channel binding enforcement should be reviewed on every domain controller.
PowerShell Method
Run the following command from an elevated PowerShell prompt on each domain controller:
# Check the current LDAP channel binding enforcement level
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "LdapEnforceChannelBinding" -ErrorAction SilentlyContinue
What it does: Returns the current value of LdapEnforceChannelBinding on that domain controller, if it has been set.
How to interpret results: A missing value, or a value of 0, means channel binding is not enforced at all. A value of 1 means it’s enforced only when the client supports it, which still allows an unpatched or non-compliant clients to authenticate without it. A value of 2 means channel binding is always required.
Registry Editor
For manual verification:
- Open Registry Editor (regedit) on the domain controller.
- Navigate to HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
- Locate LdapEnforceChannelBinding.
- Review the current value.
If the value is absent or set to 0, channel binding is not enforced on that domain controller.
Group Policy
To confirm group policy:
- Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
- Locate “Domain controller: LDAP server channel binding token requirements“
- Review the settings, the available options are Never, When Supported, or Always
Audit LDAP Channel Binding Before Enforcement
Client compatibility is the primary reason organizations might delay moving directly to Always. Microsoft provides LDAP channel binding events that can help identify applications and systems that may have problems after enforcement.
On appropriately updated domain controllers, review the Directory Service event log for channel binding events including:
- Event ID 3039 – An LDAP client failed channel binding token validation.
- Event ID 3040 – Reports unprotected LDAPS binds during the previous 24-hour period when channel binding is configured as Never.
- Event ID 3041 – Indicates that LDAP channel binding validation is not being enforced.
Newer auditing capabilities on supported Windows Server 2019 and Windows Server 2022 systems also include Events 3074 and 3075 for identifying incompatible or unprotected clients.
To increase LDAP interface diagnostic logging:
# Enable LDAP Interface Events logging for channel binding assessment
Set-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" `
-Name "16 LDAP Interface Events" `
-Value 2
It’s suggested to monitor LDAP channel binding events before moving to full enforcement, so incompatible clients can be identified and remediated first.
Finding Disabled LDAP Channel Binding with Insight Recon
Insight Recon’s Active Directory security assessment checks channel binding enforcement across every domain controller in the domain within minutes.
It also provides:
- Visibility into every domain controller where channel binding isn’t enforced
- Risk prioritization alongside other LDAP and directory services findings
- Step-by-step remediation guidance
- Validation guidance to confirm the finding is resolved after remediation
This helps teams identify the weakness before it becomes one component of a larger relay attack chain.
How to Enable LDAP Channel Binding
The target configuration for a fully compatible environment is to require channel binding on every domain controller. Do not move directly to enforcement without first identifying clients that depend on incompatible LDAP authentication.
Prerequisites
Before enabling full enforcement:
- Identify all domain controllers and applications/services using LDAPS.
- Enable channel binding auditing and review Directory Service events for incompatible clients.
- Update or replace legacy LDAP applications where possible.
- Obtain change control approval.
- Test critical LDAP integrations in a pilot environment.
- Coordinate the change with LDAP signing hardening where appropriate.
Group Policy Method
Group Policy is generally the preferred method for maintaining consistent enforcement across domain controllers. Do this by editing the policy applied to your domain controllers:
- Navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
- Locate “Domain controller: LDAP server channel binding token requirements“
- Set the value to Always
After Group Policy refresh, applicable LDAP authentication over TLS must provide valid channel binding information. Clients that cannot provide the required CBT will be rejected.
PowerShell Method
The equivalent registry configuration can be applied with PowerShell:
# Require LDAP channel binding on this domain controller.
# Values: 0 = Never, 1 = When Supported, 2 = Always
$RegistryPath = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters"
New-ItemProperty `
-Path $RegistryPath `
-Name "LdapEnforceChannelBinding" `
-PropertyType DWord `
-Value 2 `
-Force
Registry Editor
For manual configuration:
- Open Registry Editor on the domain controller.
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
- Locate or create the DWORD value LdapEnforceChannelBinding.
- Set the value to 2.
- Test critical LDAPS applications.
- Review the Directory Service event log for authentication failures.
A domain controller restart is not required for the change to take effect
Preventing LDAP Channel Binding Drift
LDAP channel binding should be part of the domain controller security baseline instead of a one-time configuration change. After client compatibility has been validated, move domain controllers to Always enforcement and manage the setting centrally to prevent configuration drift.
Review LDAP signing alongside channel binding, since the two controls protect different authentication paths. Use audit events to identify incompatible clients and give legacy dependencies an owner and remediation date rather than leaving exceptions in place indefinitely.
LDAP protections should also be supported by reducing unnecessary NTLM use and addressing authentication coercion where practical. Include these settings in regular domain controller security reviews, and test new Active Directory-integrated applications for modern LDAP security support before deployment.
Quick Validation Checklist
Can you confidently answer “yes” to all of these?
✓ Is LDAP channel binding configured consistently on every domain controller?
✓ Are you monitoring channel binding audit and failure events?
✓ Is channel binding enforcement included in your domain controller build baseline?
If any of these are unclear, your LDAPS connections may vulnerable to relay attacks.
Risk & Compliance Mapping
Business Impact: Successful abuse may enable unauthorized directory modifications, privilege escalation, persistence, or broader Active Directory compromise
| Framework | Reference |
|---|---|
| NIST CSF 2.0 | PR.DS-2 (Data-in-Transit Is Protected), PR.AC-7 (User Authentication) |
| CIS Controls | Control 3 (Data Protection), Control 4 (Secure Configuration of Enterprise Assets and Software) |
| MITRE ATT&CK / DEFEND | T1557 (Adversary-in-the-Middle) |
| DISA STIG | V-254416 |
| Microsoft Security Baselines | Require LDAP signing and LDAP channel binding where applicable to reduce relay and man-in-the-middle authentication risk. |
Frequently Asked Questions
No. Encryption protects the contents of the session, but it doesn't verify that the authentication inside the session was meant for the server receiving it. Channel binding adds that verification.
LDAP signing protects the integrity of unencrypted LDAP traffic. Channel binding protects LDAPS by tying the TLS session to the LDAP authentication inside it. Microsoft recommends enforcing both together.
It can, if a client doesn't support channel binding. That's why it's important to review LDAPS client compatibility and test in a pilot environment before domain-wide enforcement.
Start with Directory Service Events 3039, 3040, and 3041. Supported and appropriately updated Windows Server 2019 and 2022 domain controllers also provide newer channel binding auditing through Events 3074 and 3075.
Help Stop Authentication Relay at the Domain Controller
LDAPS without channel binding looks secure from the outside, but it leaves a relay path open that attackers actively look for. Insight Recon flags this alongside the other authentication hardening gaps most likely to get missed.
See exactly where your Active Directory is exposed and what to fix first.