ERROR_DS_STRONG_AUTH_REQUIRED 0x2028 — Real Fix

ERROR_DS_STRONG_AUTH_REQUIRED fires when a client tries a weak or unsigned LDAP/SASL bind that your DC policy forbids. Fix it by enabling signing or LDAPS, or relaxing LDAPServerIntegrity.

Quick answer: Your domain controller is enforcing LDAP signing or channel binding, and the client is attempting an unsigned or weak SASL bind. Either switch the app to LDAPS (port 636) or a signed SASL bind, or — if you can't touch the app — relax the DC policy by setting LDAPServerIntegrity back to 1.

This error almost never appears on a fresh install. It shows up after someone tightens LDAP security on the DCs — usually as part of a hardening push, or after Microsoft's March 2020 LDAP channel binding and signing guidance got rolled into a patch cycle. You'll see it against older LDAP clients: Java apps using JNDI with no TLS, PHP LDAP bind, perl Net::LDAP, some NAS appliances, printers doing address book lookups, and yes, plenty of custom in-house tools. The DC is doing exactly what you told it to do. The client is the problem.

Specifically, the directory service returns ERROR_DS_STRONG_AUTH_REQUIRED (0x2028) when a bind comes in over plain LDAP on 389 with no signing and no TLS, and the DC has LDAPServerIntegrity set to 2 (Require signing). Same thing happens if LdapEnforceChannelBinding is set to 2 and the app isn't sending the channel binding token. Two separate registry knobs, same family of failure.

Fix it properly — numbered steps

1. Confirm which policy is biting you

On the DC, check both keys:

reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LDAPServerIntegrity
reg query "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LdapEnforceChannelBinding

If LDAPServerIntegrity is 2, signing is required. If LdapEnforceChannelBinding is 2, channel binding is enforced. Either value being 2 can produce 0x2028 depending on what the client does wrong.

2. Find out what's actually connecting

Don't guess. Turn up NTDS diagnostics on one DC:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics" /v "16 LDAP Interface Events" /t REG_DWORD /d 2 /f

Reproduce the failure, then check the Directory Service log in Event Viewer. You'll get the client IP and the bind type. That tells you whether it's an unsigned simple bind, an unsigned SASL bind, or a channel binding mismatch.

3. Fix the client first — always

This is the correct path. Point the app at LDAPS:

Change the connection string from ldap://dc.contoso.com:389 to ldaps://dc.contoso.com:636.
Make sure the DC has a valid certificate from your internal CA with the Server Authentication EKU.
Import the CA root into the client's trust store. Java apps need it in cacerts via keytool -import.

If the app supports SASL with GSSAPI (Kerberos), that also satisfies signing without TLS. It's the preferred option when the client is domain-joined.

4. If LDAPS isn't possible, allow signing-only

Signed but unencrypted SASL bind on 389 is acceptable. This means the app negotiates ldap_sasl_bind_s with GSSAPI or NTLM. If it's a Java app, set com.sun.jndi.ldap.connect.pool and enable SASL properly. This won't work with plain simple binds — a simple bind over 389 is exactly what the policy blocks.

5. Roll back the policy as a last resort

Only do this if the vendor won't ship a fix and you've accepted the risk in writing. On each DC (or via GPO — see below):

reg add "HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" /v LDAPServerIntegrity /t REG_DWORD /d 1 /f

Then restart the NTDS service or reboot. Value 1 means "negotiate signing if the client asks, don't require it." Value 0 is "none" — don't use it, that's worse than the original problem.

If the setting came from a GPO (Computer Config → Policies → Windows Settings → Security Settings → Local Policies → Security Options → "Domain controller: LDAP server signing requirements"), editing the registry directly won't stick. Fix the GPO or you'll be back here next Tuesday.

If that doesn't work

Channel binding is the culprit, not signing. Set LdapEnforceChannelBinding to 1 instead of 2. Value 1 is "when supported" — the DC only enforces it if the client advertises support. Value 2 is "always" and breaks every non-Windows LDAP client that predates 2015.
You're hitting a specific DC. Check whether the hardening was applied per-DC or via GPO. Uneven policy across DCs causes intermittent 0x2028 depending on which DC the client lands on.
It's a legacy service account doing simple bind for LDAP queries. Migrate it to a gMSA or at minimum use LDAPS. There's no way to make a simple bind over 389 compliant with Require Signing.
Third-party appliance you can't touch. Put an LDAPS proxy in front of it. stunnel works fine for LDAP. Not elegant but it gets you compliant.

Prevention

Before you flip LDAPServerIntegrity to 2, run the LDAP signing audit for at least a month. Microsoft's guidance and every competent AD admin will tell you the same thing: audit first, then enforce. Turn on the 16 LDAP Interface Events diagnostic at level 2, watch for unsigned binds, fix every client, and only then roll out enforcement via GPO. If you skip the audit step you will spend a weekend doing it anyway, except with the help desk screaming at you. Also: document every service account that does LDAP binds. The ones you forgot will be the ones that page you at 3 AM.