LDAP Channel Binding Disabled: Open Season for Relay Attacks

Quick Summary

If you want to see whether your domain controllers enforce channel binding without touching anything, Insight Recon's free read-only scan checks every DC.

What the Finding Means

LDAPS is LDAP wrapped in TLS on port 636. The TLS part encrypts the traffic, but it doesn't tie the logon inside to the connection it arrived on. Someone in the middle can take a logon meant for them, open their own TLS connection to a domain controller and pass the logon along. The DC sees valid credentials on a valid TLS session and accepts it.

Channel binding closes that gap. The client mixes a value taken from its TLS connection, the channel binding token, into its authentication. The DC checks that the token matches the TLS session it actually received the logon on. A forwarded logon carries no token, or one from a different connection. Either way the DC rejects it.

One detail matters for rollout. Channel binding applies to NTLM and Kerberos logons over TLS. Simple binds over LDAPS, where an app sends a username and password, don't carry a token. The setting doesn't touch them.

The setting lives in the LdapEnforceChannelBinding registry value on each DC. Group Policy sets it through Domain controller: LDAP server channel binding token requirements:

"When supported" is a stepping stone. A forwarded logon can come from a client that doesn't advertise support. The DC will still let it through. Only Always closes the gap.

Insight Recon doesn't read the setting at all. It tests what each domain controller actually does. It binds to the DC over LDAPS on port 636 twice, first with a channel binding token and then without one. If the DC accepts the bind without the token, channel binding isn't enforced. That means only Always passes. A DC on When supported, including a Server 2025 DC on its default, gets flagged. DCs with port 636 closed, or where the first bind fails, are skipped. If no DC gives a clear answer, the check shows as not assessed.

LDAP Channel Binding vs LDAP Signing

These two get mixed up constantly. They cover different ports. A DC needs both.

The two depend on each other. Requiring LDAP signing pushes apps doing unsigned or clear-text binds onto LDAPS, which is exactly where channel binding takes over. Do one without the other and the gap just moves to the other port.

Why It's Risky

Microsoft's own description in KB4520412 is that a DC without channel binding, signing or sealing can let a man-in-the-middle attacker forward an authentication request to it. If the forwarded account can change things in the directory, so can the attacker. That could mean adding an account to a group, changing permissions on an object or setting up a way back in later.

The bigger risk is false confidence. Teams that moved everything to LDAPS often assume the job is done. Encryption keeps the traffic private. It doesn't stop a logon from being used somewhere it wasn't meant to go.

Real-World Context

Microsoft has been working on this since 2017, mostly through new settings and logging rather than new defaults:

1. July 2017: the CVE-2017-8563 updates added channel binding support to Windows Server 2008 and later, along with the LdapEnforceChannelBinding setting.
2. August 2019: Microsoft published ADV190023, its guidance for enabling LDAP channel binding and signing.
3. March 2020: updates added the channel binding Group Policy setting and events 3039, 3040 and 3041. KB4520412 says these updates and "updates in the foreseeable future" would not change the default policies. They didn't.
4. August 2023 to January 2024: audit events 3074 and 3075 arrived for Server 2022 and then Server 2019. Admins could finally see which clients would break before enforcing. They worked without a manual step from November 2023 on Server 2022 and January 2024 on Server 2019.
5. Windows Server 2025: the effective default on DCs moved to "When supported."

Client support isn't new either. Windows 10 has supported channel binding since version 1709. Windows Server has supported it since the 2017 updates. Most Windows clients are ready. The holdouts are usually third-party apps and appliances.

What Breaks When You Require It

Setting Always only affects NTLM and Kerberos logons over LDAPS and StartTLS. Simple binds over LDAPS aren't affected. Plain LDAP on port 389 isn't touched either, which is what LDAP signing is for. What can break:

• Apps with older LDAP libraries. Third-party apps and appliances that do NTLM or Kerberos logons over LDAPS but can't send a channel binding token. Apps doing simple binds over LDAPS keep working.
• Very old Windows. Microsoft notes Windows XP fails once channel binding is set to Always. Anything that old has bigger problems, but it's worth knowing if one is still hiding on the network.

The fix is usually an update from the vendor, or a newer LDAP library that supports channel binding. The audit step below shows you exactly which clients to chase.

How Attackers Use It

This falls under MITRE ATT&CK T1557, adversary-in-the-middle. It's the same relay pattern as SMB and plain LDAP. An attacker on the internal network gets an account to authenticate to them, then forwards that logon to a domain controller over their own LDAPS connection. If the DC doesn't require channel binding, it accepts the logon and the attacker can work in the directory with that account's rights.

Channel binding breaks it because the forwarded logon has no token for the attacker's TLS connection. It either carries none or carries one from a different connection. A DC set to Always checks, sees it doesn't match and drops the bind.

How to Check Your Domain Controllers

Check One DC with PowerShell

Run this in an elevated PowerShell session on the domain controller:

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" `
    -Name "LdapEnforceChannelBinding" -ErrorAction SilentlyContinue

What it does: Shows the DC's LdapEnforceChannelBinding value, if one is set.

How to interpret results: 2 means Always. 1 means When supported, which still lets clients that don't advertise support through. 0 means Never. No output means the value isn't set. The DC uses its default: Never on Server 2022 and earlier, When supported on Server 2025.

Check Every DC

The same check across the domain over PowerShell remoting, with each DC's OS so you know which default applies:

Import-Module ActiveDirectory
$dcs = (Get-ADDomainController -Filter *).HostName
Invoke-Command -ComputerName $dcs -ScriptBlock {
    $p = Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -ErrorAction SilentlyContinue
    [pscustomobject]@{
        OS                        = (Get-CimInstance Win32_OperatingSystem).Caption
        LdapEnforceChannelBinding = $p.LdapEnforceChannelBinding
    }
} | Select-Object PSComputerName, OS, LdapEnforceChannelBinding

How to interpret results: anything other than 2 needs work.

Check in Registry Editor

On the DC, open regedit and go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Look for LdapEnforceChannelBinding. If it's missing or not 2, channel binding isn't fully enforced.

Check Group Policy

In the GPO that hardens your DCs, usually the Default Domain Controllers Policy, go to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options and find Domain controller: LDAP server channel binding token requirements. Not defined means each DC uses its default.

See Which Clients Would Break

Domain controllers log channel binding events in the Directory Service log. Which ones you get depends on the setting:

• 3041: logged at startup and every 24 hours while the DC is set to Never, as a reminder to turn it on.
• 3040: logged every 24 hours under Never, with a count of LDAPS logons that didn't carry channel binding.
• 3074: a client would have failed the channel binding check under enforcement. Audit only, the logon still worked.
• 3075: a client that supports channel binding didn't send any. It's rejected if the DC enforces the check.
• 3039: a client failed the channel binding check and was rejected.

Events 3039, 3074 and 3075 only show up under When supported or Always. They also need LDAP diagnostic logging at level 2:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" `
    -Name "16 LDAP Interface Events" -Value 2

Those events include the client's IP address and, where logged, the account it used. That's your fix list. Set the logging value back to 0 when you're done, since level 2 gets noisy.

Finding Channel Binding Gaps with Insight Recon

The commands above are the manual way. Insight Recon's read-only Active Directory security assessment checks channel binding along with 150+ other checks:

• LDAPS Channel Binding Disabled (Moderate): tests each domain controller live over LDAPS and flags any that accept a bind without a channel binding token.
• LDAP Signing Not Enforced on Domain Controllers (High): the plain LDAP half of the same relay protection.
• Weak LDAP Encryption (Moderate): flags LDAPS still allowing old SSL versions. Channel binding only helps if the TLS underneath is sound.
• Domain Controller with SMB Signing Not Required (High): the same relay story over SMB.

Every finding comes with the attacker context and the remediation steps.

How to Fix It

Step Through When Supported First

Don't jump straight from Never to Always. Set the DCs to When supported and turn on diagnostic logging at level 2. That way you start collecting events 3039, 3074 and 3075 without breaking clients that don't advertise channel binding support. Watch 3039 from day one, though. Under When supported the DC already rejects capable clients that send a bad token or none at all. Leave it running for a couple of weeks. Then go through every client IP and account the events turn up.

Fix the Clients

Most of what shows up will be third-party apps and appliances. Check for a vendor update or a newer LDAP library that supports channel binding. Give anything that can't be fixed yet an owner and a date. Microsoft is clear that clients without channel binding support can't query the DCs once Always is set.

Set It to Always

Group Policy is the best way to keep every DC consistent. In the Default Domain Controllers Policy, or whichever GPO hardens your DCs, set Domain controller: LDAP server channel binding token requirements to Always. It takes effect on the next policy refresh. No restart needed.

To set it on a single DC with PowerShell instead:

# 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

Or in Registry Editor, create or edit the LdapEnforceChannelBinding DWORD under the same key and set it to 2. Security settings from a GPO get reapplied whenever the GPO changes. By default they're also reapplied every 16 hours even when it doesn't change. A manual registry change won't stick if a GPO says otherwise. Pick one method and stick with it.

After the change, watch for event 3039 on each DC. Every one is a client that just got turned away.

Then Do LDAP Signing

Channel binding covers port 636. Plain LDAP on port 389 needs LDAP signing. Our LDAP signing guide covers the audit and rollout for that side. It's worth cutting down NTLM where you can too, since forwarded NTLM logons are what most of these attacks rely on.

Quick Validation Checklist

• Is LdapEnforceChannelBinding set to 2 on every domain controller?
• Is it set through Group Policy so new and restored DCs pick it up?
• Did you run in When supported long enough to catch the clients that would break?
• Is event 3039 quiet since you moved to Always?
• Do your DCs also require LDAP signing?

A no on any of these leaves an LDAPS path where a forwarded logon still works.

Risk & Compliance Mapping

Channel binding ties each LDAPS logon to the connection it arrived on. It lines up with the frameworks like this:

Frequently Asked Questions

Help Stop Authentication Relay at the Domain Controller

LDAPS without channel binding looks secure and still leaves a relay path open. Step through When supported and fix the clients that show up. Then set Always on every DC and pair it with LDAP signing so both ports are covered.

Additional References

• Microsoft Support: KB4520412, LDAP channel binding and LDAP signing requirements for Windows
• Microsoft Learn: Domain controller: LDAP server channel binding token requirements
• Microsoft Security Response Center: ADV190023
• Microsoft Learn: How to enable LDAP signing in Windows Server
• Microsoft Learn: Securing Domain Controllers Against Attack