LDAP Signing and Channel Binding: How to Enforce Secure LDAP on Domain Controllers Without Breaking AD-Integrated Applications

The LDAP diagnostic event log is disabled by default. Enable it on domain controllers to generate Event ID 2889 for every unsigned LDAP bind:

# Enable LDAP diagnostics for unsigned bind detection on all DCs
$DCs = Get-ADDomainController -Filter * | Select-Object -ExpandProperty HostName

foreach ($DC in $DCs) {
    Invoke-Command -ComputerName $DC -ScriptBlock {
        # Set LDAP Interface Events diagnostic level to 2 (verbose) for signing detection
        $ldapDiagPath = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics"
        Set-ItemProperty -Path $ldapDiagPath -Name "16 LDAP Interface Events" -Value 2
        Write-Output "LDAP diagnostics enabled on $env:COMPUTERNAME"
    }
}

After enabling, unsigned LDAP bind attempts generate Event ID 2889 in the Directory Services event log on the DC that processed the bind. The event contains:

• The client's IP address
• The distinguished name (DN) of the account used for the bind
• The LDAP bind type (Simple / SASL without signing)

Collect Event 2889 from all DCs over 30 days:

# Collect Event 2889 across all DCs
$results = foreach ($DC in $DCs) {
    Get-WinEvent -ComputerName $DC -FilterHashtable @{
        LogName = 'Directory Service'
        Id = 2889
        StartTime = (Get-Date).AddDays(-30)
    } -ErrorAction SilentlyContinue | ForEach-Object {
        $xml = [xml]$_.ToXml()
        [PSCustomObject]@{
            DC = $DC
            Time = $_.TimeCreated
            ClientIP = $xml.Event.EventData.Data[0].'#text'
            Account = $xml.Event.EventData.Data[1].'#text'
            BindType = $xml.Event.EventData.Data[2].'#text'
        }
    }
}
$results | Export-Csv -Path "unsigned_ldap_binders.csv" -NoTypeInformation

After collecting 2889 events, group the client IPs into categories to prioritize remediation:

# Summarize unsigned LDAP sources by client IP and account
Import-Csv -Path "unsigned_ldap_binders.csv" |
    Group-Object ClientIP |
    Select-Object @{N='ClientIP';E={$_.Name}},
                  @{N='EventCount';E={$_.Count}},
                  @{N='Accounts';E={($_.Group.Account | Sort-Object -Unique) -join '; '}} |
    Sort-Object EventCount -Descending |
    Format-Table -AutoSize

Common unsigned LDAP source categories:

Network devices (switches, printers, firewalls): These use LDAP for authentication (802.1X, LDAP-based login). Most cannot be upgraded to support signing. Solution: migrate these to LDAPS (port 636) with a valid DC certificate, or use a separate read-only DC for LDAP authentication from legacy devices with a limited credential scope.

Monitoring and backup systems: SNMP-based monitoring tools, backup agents, and ITSM integrations often use LDAP for user lookups. Most modern versions support LDAPS. Update to the current version and configure the LDAPS endpoint.

Legacy applications: On-premises applications with hardcoded LDAP endpoints. Solution: configure the application to use LDAPS (port 636) with certificate validation, or move authentication to SAML/OIDC via ADFS/Entra ID.

Automation scripts: PowerShell or Python scripts using the DirectorySearcher or ldap3 library with unsigned binds. Update the script to use LDAPS or SASL signing.

LDAPS requires each DC to have a valid server certificate. In environments with an internal PKI, deploy certificates automatically via autoenrollment:

# Verify DCs have certificates with Server Authentication OID (1.3.6.1.5.5.7.3.1)
foreach ($DC in $DCs) {
    $cert = Invoke-Command -ComputerName $DC -ScriptBlock {
        Get-ChildItem Cert:\LocalMachine\My | 
        Where-Object { $_.EnhancedKeyUsageList.ObjectId -contains '1.3.6.1.5.5.7.3.1' } |
        Select-Object Subject, NotAfter, Thumbprint | Select-Object -First 1
    }
    Write-Output "$DC - Certificate: $($cert.Subject), Expires: $($cert.NotAfter)"
}

If DCs do not have suitable certificates:

1. Create a certificate template for Kerberos Authentication or Domain Controller Authentication in your CA
2. Configure autoenrollment via GPO: Computer Configuration > Windows Settings > Security Settings > Public Key Policies > Certificate Services Client - Auto-Enrollment
3. Force enrollment: certutil -pulse or gpupdate /force

Verify LDAPS is functional after certificate deployment:

# Test LDAPS connectivity from a client (Linux)
ldapsearch -H ldaps://dc01.domain.com -x -b "DC=domain,DC=com" -D "svc-ldap@domain.com" -W "(objectClass=domain)" -LLL

# Test from Windows
ldp.exe # Connect to DC on port 636 using SSL

After remediating or documenting all unsigned LDAP clients, enable signing and channel binding on domain controllers:

LDAP Signing Policy (Domain Controller-side requirement):

GPO: Default Domain Controllers Policy (or a DC-specific GPO)
Path: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Setting: Domain controller: LDAP server signing requirements
Value: Require signing

LDAP Channel Binding (requires Windows Server 2019 or later with the March 2020 patch):

Path: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Setting: Domain controller: LDAP server channel binding token requirements
Value: Always (most secure) or When supported

Set to When supported initially, which only enforces channel binding for clients that advertise channel binding support. Move to Always after confirming all clients are compatible.

Client-side setting (enforce on all domain-joined clients as well):

GPO: Default Domain Policy or workstation/server OU GPO
Path: Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
Setting: Network security: LDAP client signing requirements
Value: Require signing

Deploy in this sequence:

1. Enable DC diagnostic (Event 2889) and collect for 30 days
2. Remediate unsigned LDAP clients
3. Set DC signing requirement to Negotiate signing (allows signed or unsigned, but logs violations)
4. Monitor for new Event 2889 events
5. After 2 weeks of zero 2889 events, set DC signing requirement to Require signing

Despite thorough pre-enforcement auditing, some applications surface only after enforcement because they perform LDAP binds infrequently (password reset workflows, quarterly report generation, emergency access scenarios).

Diagnosing post-enforcement breaks: When an application fails after LDAP signing enforcement, check:

1. The application's error log for LDAP authentication errors (LDAP error code 52 = Unavailable, 49 = Invalid credentials after signing failure)
2. The DC Directory Services event log for Event 2889 (if any remain after enabling enforcement, the diagnostic level must be rechecked)
3. Network capture from the application server to verify whether it is connecting to port 389 (unsigned) or 636 (LDAPS)

Common break scenarios and fixes: