· r00t · 3 min read
LDAP Channel Binding: What It Is, How Attackers Exploit It, and How to Fix It
A look into how the absence of LDAP channel binding exposes environments to NTLM relay attacks, and how to properly secure it.

When performing internal penetration tests, we often identify environments that lack proper LDAP channel binding. This misconfiguration can expose your Active Directory to man-in-the-middle (MitM) attacks, allowing attackers to intercept and relay credentials with minimal effort.
In this blog, we explain what LDAP channel binding is, why it matters, how it’s exploited, and the steps your organisation can take to mitigate the risk.
What Is LDAP Channel Binding?
LDAP (Lightweight Directory Access Protocol) is used by Windows clients and applications to communicate with Active Directory (AD). If this communication isn’t properly protected, attackers can intercept traffic, especially when using LDAP over simple TCP (port 389).
Channel binding ensures that the TLS layer is cryptographically tied to the application layer, preventing attackers from downgrading or hijacking LDAP sessions.
Without LDAP channel binding, clients may accept spoofed servers or be vulnerable to NTLM relay attacks.
How Attackers Exploit It
1. NTLM Relay to LDAP
Attackers on the internal network use tools like ntlmrelayx
to:
- Intercept or coerce NTLM authentication (e.g., via printer or WebDAV trickery)
- Relay those credentials to the LDAP service on a domain controller
- Perform privileged actions such as:
- Adding computers to the domain
- Modifying user attributes (e.g., changing passwords)
2. No Encryption + No Binding = Big Risk
If LDAP doesn’t require TLS encryption or binding, attackers can:
- Relay NTLM hashes
- Bypass authentication controls
- Move laterally and escalate privileges
This technique is extremely common and effective when combined with other misconfigurations like LLMNR or SMB signing disabled.
How to Fix It
Fixing this issue requires enforcing both LDAPS (LDAP over TLS) and channel binding.
If your network contains non-Microsoft systems (*nix systems, firewalls/gateways, etc.) that communicate with AD domain controllers, its recommended to check all remediation is still compatible with those devices.
1. Enable LDAP Signing and Channel Binding
Use Group Policy to enforce secure LDAP settings:
Navigate to:Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options
Set the following:
- Domain controller: LDAP client signing requirements → Negotiate signing
- Domain controller: LDAP server signing requirements → Require signing
- Wait until all domain controllers receive and apply new GPO. Test if all systems are able to communicate with domain controllers. In the event of failure, revert signing requirements to “None” and consult with vendor support to identify and resolve the problem.
- If testing is complete enforce client signing- Domain controller: LDAP client signing requirements → Require signing
2. Enable Channel Binding for LDAP (ADV190023)
Microsoft released an update (ADV190023) to support LDAP channel binding. ADV190023
Registry keys:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"LdapEnforceChannelBinding"=dword:00000001
0
= Disabled (not recommended)1
= Enabled when supported2
= Always enforced (may break legacy apps)
Test thoroughly before enabling 2
.
3. Enforce LDAPS
- Configure and install a certificate on all Domain Controllers.
- Disable plain LDAP (port 389) or restrict it using firewall rules.
Final Thoughts
LDAP channel binding is an often-overlooked configuration that can prevent serious attacks in an Active Directory environment.
We routinely exploit this weakness during internal penetration tests, and often pair it with other low-effort techniques to gain domain-level access.
If you’re unsure whether your environment is protected, our team can help assess your LDAP configuration and test your internal exposure.
Get in touch to schedule an internal assessment and lock down your directory services. Get in touch