Quick answer
Set ldapserverintegrity to 2 or enable LDAP signing via GPO under Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements.
What's happening here
You're seeing ERROR_DS_CONFIDENTIALITY_REQUIRED (0X0000202D) when some app—maybe a legacy CRM, a monitoring tool, or even a PowerShell script—tries to bind to Active Directory without signing or sealing the LDAP connection. Windows Server 2019 and later default to requiring signed LDAP, so older tools that don't ask for it get slapped with this error. I've seen this most often with a vendor's LDAP integration that was written for Windows 2003 era and never updated.
The error code itself is self-explanatory: the domain controller says "I need confidentiality (signing + encryption), and you didn't provide it." The trigger is almost always a client that uses simple bind (username + password) over plain LDAP port 389 instead of LDAPS (636) or SASL with Kerberos.
Fix steps
Step 1: Check if the client supports LDAP signing
Before touching anything, figure out what's connecting. Is it a legacy app? A PowerShell script using System.DirectoryServices? If you control the code, add this to the connection string: LDAP://domain.com?LDAPSigning. For .NET apps, set AuthenticationTypes.Signing on the DirectoryEntry object.
Step 2: Enable LDAP signing on the client machine
If the client is a Windows box and you can't change the app, push a registry key:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\Parameters]
"LDAPClientIntegrity"=dword:00000001Set it to 1 (signing only) or 2 (signing + sealing). Reboot the machine or restart the Netlogon service. This tells the LDAP library to ask for signed LDAP even if the app doesn't.
Step 3: Lower the server requirement temporarily (if you're stuck)
On your domain controller, open secpol.msc. Go to Security Settings > Local Policies > Security Options > Domain controller: LDAP server signing requirements. Set it to None. This is a Band-Aid, not a fix. Test quickly, then revert. I only recommend this for a 15-minute troubleshooting window.
Step 4: Switch to LDAPS (port 636) if possible
If your app supports it, change the connection string from ldap:// to ldaps://. You'll need a CA-issued certificate on the domain controller. This is the cleanest fix—encryption and signing baked in.
Alternative fixes if the main one fails
- Check channel binding: Some security updates after 2023 require LDAP channel binding. Run
Get-ADDomainControllerand check theLdapChannelBindingSupportattribute. If it's "Always", the client needs to support it. Older apps may need a compatibility shim. - Use Kerberos instead of NTLM: Simple bind uses NTLM. If the app can do SASL with Kerberos, that satisfies signing requirements automatically. Update the app's authentication method if possible.
- Look at the event log: Event ID 2886 on the DC tells you which client failed and why. I've debugged entire outages just by reading that one event.
Prevention tip
Don't let legacy apps dictate your security posture. Set up a test domain controller with LDAP signing enforced, then run your vendor's tool against it. If it breaks, push them for an update. Microsoft won't roll back the signing requirement—expect it in all future Windows releases. Also, document every app that binds to AD and note whether it uses simple bind, SASL, or LDAPS. You'll thank me when you upgrade to Server 2025.