LDAP channel binding and signing enforcement breaks applications
Domain controllers now reject unsigned simple LDAP binds. Applications that were never updated stop authenticating.
What you see
An application, appliance or printer that authenticates against Active Directory suddenly cannot, usually after a controller update or a hardening change.
What is actually wrong
Simple LDAP binds over an unencrypted connection are refused. The application is binding on port 389 without TLS and without signing.
Codes and articles
Fixes (2)
Find every unsigned bind before enforcing anything
Before enabling enforcement. This is the step that prevents the outage.
Turn on the diagnostic logging that records unsigned binds.
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name '16 LDAP Interface Events' -Value 2 -Type DWordEvent 2889 records the client address and the account for every unsigned bind. Left running for a week it produces the complete list of what will break — which is the only way to do this without an outage.
Collect the events after several days, covering month-end and any weekly jobs.
Get-WinEvent -LogName 'Directory Service' -MaxEvents 2000 | Where-Object Id -eq 2889 | ForEach-Object { ($_.Message -split "`n" | Select-String 'Client IP|Identity') -join ' ' } | Group-Object | Sort-Object Count -Descending | Format-Table Count,Name -AutoSize
Work through the list: multifunction printers, monitoring systems, backup appliances and older line-of-business applications are the usual occupants.
Reconfigure each to use LDAPS on port 636, or LDAP with sign and seal. Most support it and simply were not configured for it.
Only when the 2889 events have stopped, enable enforcement.
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name LdapEnforceChannelBinding -Value 2 -Type DWordSet-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'LDAPServerIntegrity' -Value 2 -Type DWord
Restore service, then fix the client properly
Enforcement is already on and something is broken.
Identify what is failing, from the controller's own log.
Get-WinEvent -LogName 'Directory Service' -MaxEvents 200 | Where-Object Id -in 2889,3039,3040 | Format-List TimeCreated,Id,MessageFix the client first if you can — configure it for LDAPS on 636. That is the permanent answer and it is often a single setting.
Test-NetConnection dc01.example.local -Port 636 -InformationLevel DetailedConfirm the controller has a certificate suitable for LDAPS, or the client cannot switch even when configured to.
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.EnhancedKeyUsageList.FriendlyName -contains 'Server Authentication' } | Format-Table Subject,NotAfter,ThumbprintOnly if a critical system cannot be fixed immediately, relax enforcement temporarily and schedule the real fix.
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name LdapEnforceChannelBinding -Value 1 -Type DWordRestart-Service NTDS -Force
Value 1 is "when supported", which lets older clients through. It is a genuine reduction in protection against relay attacks, so it belongs on a dated ticket rather than in the permanent configuration.
Restore enforcement once the clients are fixed.
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name LdapEnforceChannelBinding -Value 2 -Type DWord
Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' | Format-List LdapEnforceChannelBinding,LDAPServerIntegrityWhere this stops. This write-up was written and checked by hand. It says what each step changes, how to confirm it worked and how to reverse it, and anything destructive is flagged before you reach it. If it does not match what your machine is doing, search the Support Centre for the exact code or message — and when something needs a person, get in touch.