How to Enable LDAP Channel Binding on Domain Controllers (LdapEnforceChannelBinding)

PingCastle’s “Channel binding is not enabled for all DC for LDAPS” means a domain controller accepts LDAPS logons without an LDAP channel binding token, so a relayed authentication can reach the directory. To fix it, set the DCs to When supported, review Events 3039, 3074 and 3075, fix the clients listed, then set the channel binding policy to Always.

The change itself is one Group Policy option backed by one registry value, LdapEnforceChannelBinding. The real work is finding the LDAPS clients that cannot send a token before the DCs start refusing them.

What the scanner is actually detecting

Two sources usually report this control:

In PingCastle the rule sits in the Anomalies category, adds 5 points to the score and is mapped to the MITRE ATT&CK man-in-the-middle technique.

Real-world risk, stated honestly

LDAP signing protects LDAP on port 389, but it does not apply to LDAPS on port 636, where integrity comes from TLS. PingCastle’s explanation is that without channel binding, a forged or relayed authentication can be carried inside a new TLS tunnel to the DC and still be accepted. Channel binding (Microsoft also calls it Extended Protection for Authentication, EPA) closes that gap: the client places a value derived from its TLS channel, typically a hash of the server certificate, inside the authentication, and the DC checks that it matches the TLS session it is actually on.

Microsoft’s KB4520412 describes the unhardened default as an elevation of privilege issue: a man-in-the-middle attacker can forward an authentication request to a DC that does not require channel binding, signing or sealing. The practical scenario is relaying a captured or coerced authentication from a privileged user or computer account into LDAPS and making directory changes as that identity.

The limits: the attacker needs a position inside the network and an authentication to relay, and this is not remote code execution by itself. It is a privilege escalation path, and it matters most in domains that already require LDAP signing, because LDAPS then becomes the remaining relay target. Reducing NTLM, following a plan for disabling NTLM safely, shrinks the relay surface further.

Defaults matter. On Windows Server 2022 and earlier the effective setting is Never. Microsoft documents When supported as the effective default for Windows Server 2025 DCs, but DCs upgraded in place keep their existing policy, and CIS still expects Always.

How to confirm it on the host

On each domain controller, in an elevated PowerShell session:

# 0 = Never, 1 = When supported, 2 = Always (no value = OS default)
Get-ItemProperty -Path 'HKLM:SYSTEMCurrentControlSetServicesNTDSParameters' -Name LdapEnforceChannelBinding -ErrorAction SilentlyContinue

# 3041 = logged at startup and every 24 hours while the policy is Never
# 3040 = daily count of unprotected LDAPS binds while the policy is Never
Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=3040,3041} -MaxEvents 10 -ErrorAction SilentlyContinue |
    Format-List TimeCreated, Id, Message

Event 3040 tells you LDAPS binds without channel binding are happening, but not who makes them. To see whether a Group Policy object defines the setting, run gpresult /scope computer /h C:Temprsop.html on the DC and look for Domain controller: LDAP server channel binding token requirements.

How to fix it

Step 1: turn on LDAP interface diagnostics

Client-level events need diagnostic logging level 2 or higher. Run this on every DC:

reg add HKLMSYSTEMCurrentControlSetServicesNTDSDiagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2 /f

Step 2: move to When supported and collect the client list

Microsoft notes that Events 3039, 3074 and 3075 are only generated when channel binding is set to When supported or Always, so the audit happens at When supported. Microsoft recommends a value of 1 when older systems must keep working. For a single DC you can set the registry value directly; a GPO that defines the policy will overwrite it at the next refresh.

reg add HKLMSYSTEMCurrentControlSetServicesNTDSParameters /v LdapEnforceChannelBinding /t REG_DWORD /d 1 /f

No restart is needed; the LDAP server picks up the change dynamically. The events mean:

• 3039: the client failed channel binding validation. At When supported this is a client that claims support but sent a malformed or missing token. Investigate these first.
• 3074: the bind would have failed validation if the DC enforced channel binding.
• 3075: a channel-binding-capable client did not send a token; with enforcement, this bind will be rejected.

Events 3074 and 3075 need Windows Server 2019 or 2022 with the November 14, 2023 or later updates, or Windows Server 2025; Windows Server 2016 DCs log only 3039. After a full business cycle, summarize each DC’s log:

Get-WinEvent -FilterHashtable @{LogName='Directory Service'; Id=3039,3074,3075} -ErrorAction SilentlyContinue |
    ForEach-Object {
        [PSCustomObject]@{
            EventId  = $_.Id
            ClientIP = if ($_.Message -match 'Client IP address:s+(S+)') { $Matches[1] -replace ':d+$', '' }
            Identity = if ($_.Message -match 'authenticate as:s+([^rn]+)') { $Matches[1].Trim() }
        }
    } | Sort-Object ClientIP, Identity, EventId -Unique |
    Export-Csv C:Templdaps-cbt-clients.csv -NoTypeInformation

Run it on every DC; each one logs only the binds it received.

Step 3: fix the clients

• Windows: channel binding requires the CVE-2017-8563 security update, which patched, supported Windows builds already carry. A client counts as capable only if EPA is not switched off: check that SuppressExtendedProtection under HKLMSYSTEMCurrentControlSetControlLsa is absent or 0 (1 and 3 disable it). On Windows Server 2008 and earlier, install KB5021989 (Extended Protection for Authentication) before the CVE-2017-8563 update, or LDAPS fails with LDAP error 81.
• Linux and Unix: Red Hat states that SASL over TLS against a DC enforcing channel binding needs the cyrus-sasl, openldap and krb5-libs versions from RHEL 8.3 or later. For OpenLDAP-based clients, set SASL_CBINDING tls-endpoint in /etc/openldap/ldap.conf (the default is none).
• Appliances: NAS devices, printers, firewalls and VPN gateways need a firmware version from the vendor that supports channel binding. Microsoft’s advice is to contact the device provider.

Step 4: enforce Always

Edit the Default Domain Controllers Policy (or another GPO linked to the Domain Controllers OU) and go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server channel binding token requirements. Tick Define this policy setting and select Always, which writes LdapEnforceChannelBinding = 2. Run gpupdate /force on the DCs. PingCastle’s solution text accepts 1 or 2, but only Always refuses every bind without a token, and it is what CIS requires.

For AD LDS, create the same DWORD under HKLMSYSTEMCurrentControlSetServices<instance name>Parameters.

How to verify the fix and rescan

1. Check every DC from a machine with the ActiveDirectory module and WinRM access:

   Get-ADDomainController -Filter * | ForEach-Object {
       Invoke-Command -ComputerName $_.HostName -ScriptBlock {
           [PSCustomObject]@{
               DC    = $env:COMPUTERNAME
               Value = (Get-ItemProperty 'HKLM:SYSTEMCurrentControlSetServicesNTDSParameters' -Name LdapEnforceChannelBinding -ErrorAction SilentlyContinue).LdapEnforceChannelBinding
           }
       }
   }

   Every DC should report 2.

2. Events 3040 and 3041 should stop, because they are only logged while the policy is Never. New 3039 events now mean a client is being refused.
3. Rerun PingCastle from a domain member that is not a DC: PingCastle.exe –healthcheck –server contoso.local. Rerun the CIS audit for compliance scanners.
4. When finished, set “16 LDAP Interface Events” back to 0.

What can break and how to roll back

• Legacy Windows: Windows XP, and unpatched Windows Server 2008 hosts, cannot provide a token and are refused once Always is set.
• Hosts with EPA disabled: SuppressExtendedProtection set to 1 or 3.
• Older Linux clients and appliances doing SASL binds (NTLM or Kerberos) over LDAPS without token support.
• TLS-terminating load balancers or proxies in front of DCs: the token is typically derived from the certificate the client sees, so a device that presents its own certificate produces a mismatch.

To roll back, set the policy to When supported (or Never in an emergency) in the same GPO and run gpupdate /force on the DCs. No restart is required. Change it in the GPO rather than the registry, or the GPO will reapply Always.

Common false positive reasons

• Scanners disagree on value 1. A DC at When supported may still fail a CIS audit, which accepts only Always. Decide on Always as the end state.
• Server 2025 default not written to the registry. A new Server 2025 DC is effectively at When supported with no value present, so registry-based compliance checks may report it as not configured.
• One DC is not receiving the policy. PingCastle lists DCs individually; a DC outside the Domain Controllers OU or with SYSVOL replication problems stays flagged.
• Scanner coverage. PingCastle skips the DC it runs on and only tests DCs that complete a TLS handshake on 636, so a clean result from a DC-hosted scan proves nothing about that DC.
• Timing. The scan ran before Group Policy refreshed on the DC.

FAQ

Is LDAP channel binding the same as LDAP signing?

No. Signing covers LDAP on port 389 (LDAPServerIntegrity); channel binding covers binds over TLS (LdapEnforceChannelBinding). Microsoft’s KB4520412 covers both hardening changes, and PingCastle reports them as separate rules.

Do the domain controllers need a reboot?

No. Microsoft documents that the LDAP server responds to the registry change dynamically, and the policy applies without a restart.

Are simple binds over LDAPS affected?

Channel binding is used when the bind is SASL, meaning NTLM or Kerberos. Microsoft notes that simple bind over TLS gets no channel binding protection and is not recommended. Test simple-bind applications during the When supported phase anyway.

When supported or Always?

When supported is the safe transition setting; Always is the end state recommended by Microsoft’s policy reference and required by CIS. Include it in your Windows Server hardening checklist so new DCs are built with it.

Tracking this finding across many hosts

Across several domains, the hard part is tracking which DCs and clients are still outstanding. SITEY imports findings from 16 scanners and merges duplicates per scanner, not across scanners, and its AI triage suggests false positives with evidence for a human to decide. AI-written remediation scripts run only after human approval, through SITEY agents on Windows endpoints. Per-finding retest covers only Nessus, Acunetix and Burp, so confirm closure for PingCastle or CIS audit findings with a fresh scan.

Sources

• Microsoft Support: LDAP channel binding and LDAP signing requirements for Windows (KB4520412)
• Microsoft Support: Use the LdapEnforceChannelBinding registry entry
• Microsoft Learn: Domain controller LDAP server channel binding token requirements
• Tenable: CIS Windows Server 2019 L1 DC audit item 2.3.5.3
• PingCastle rule descriptions (A-DCLdapsChannelBinding)