LDAP 8 strong auth required: signing and channel binding enforced on DCs

Fix it now

LDAP 8 is a domain controller refusing a bind because the connection was not protected, not because the credential was wrong. A simple bind outside TLS and a SASL bind that never requested integrity are both rejected before the password is looked at. You change how the client connects, not what it sends.

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

1. Read the Directory Service log. Event 2886 says this controller is not configured to reject unprotected binds; Event 2887 is the 24-hour count of unprotected binds it accepted; Event 2888 is the same count once it is rejecting them.
2. Collect Event 2889 for a full business cycle. That is the per-bind record, and it names the client IP address, the identity offered and whether it was an unsigned SASL bind or a simple bind. It only appears once you have raised the diagnostic value above.
3. Move each named client to LDAPS on TCP 636 – or 3269 for a global catalog – or to a bind that negotiates signing. Both are acceptable to a hardened controller with no change to the account.
4. If binds on 636 fail from everywhere including the controller itself, the certificate is the problem rather than the client. certutil -DCInfo Verify checks the domain controller certificates.

Set the diagnostic value back to 0 once you have your list, and do not raise enforcement across every controller before you have read 2889 for a full month, month end included. The clients you break will be the ones nobody documented.

If the application binds over TLS and stops appearing in Event 2889, you are done. If it cannot be moved, the next section covers the two settings involved and what each one actually does.

Why it happens

Microsoft publishes LDAP 8 as LDAP_STRONG_AUTH_REQUIRED, 0x08, “Strong authentication is required.” Its companion, LDAP 13, is LDAP_CONFIDENTIALITY_REQUIRED, 0x0d, “Confidentiality is required.” Neither says anything about your password or your account. They are the directory declining to have the conversation on the terms you offered.

Two separate controls produce them and they are constantly confused. LDAP server signing is the requirement that a SASL bind negotiate integrity; a simple bind cannot be signed at all, so the only way to keep one is to carry it inside TLS. Channel binding is a different thing: it ties an authenticated bind to the specific TLS channel it arrived on, so a session captured and relayed elsewhere cannot be reused. A client can satisfy one and fail the other.

Both are backed by registry values under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. LDAPServerIntegrity is 1 for none and 2 for require signing. LdapEnforceChannelBinding is 0 for never, 1 for when supported, and 2 for always. The Group Policy settings that write them are Domain controller: LDAP server signing requirements and Domain controller: LDAP server channel binding token requirements.

The events are the trail leading up to enforcement, and reading them in order is the whole job. Event 2886 warns that this server is not yet rejecting unprotected binds. Event 2887 is the 24-hour summary while it still accepts them, carrying two counts: simple binds performed without SSL or TLS, and Negotiate, Kerberos, NTLM or Digest binds performed without signing. Event 2888 is that same summary once the server is configured to reject, so it tells you what you are currently breaking. Event 2889 is the only one that names anybody, and it is switched off by default.

Full reference

The settings, and where each one lives

Export the NTDS Parameters and Diagnostics keys before editing them, and prefer the Group Policy settings where they exist. Raising enforcement on every controller at once, before you know who is still binding unprotected, will take out applications nobody knew were using LDAP – and the list always includes something that matters.

Reading the four events in order

So the sequence is: turn on the diagnostic, collect 2889 until you are confident the list is complete, fix the clients, watch 2887 fall to zero, then enforce, then watch 2888 to confirm nothing was missed. Enforcing before 2887 reaches zero is guessing.

Ports, once the client is moving to TLS

An application reading across domains in a multi-domain forest needs the global catalog port, so moving it to TLS means 3269 rather than 636. Changing the port without changing the target is a common way to turn a signing problem into a “the account cannot be found” problem.

What appears on the list, and what you can actually do about it

• Line-of-business applications with a settings page: usually a five-minute change to the port and a checkbox, provided the client trusts your issuing CA.
• Appliances – copiers, door controllers, storage arrays, network kit: check for firmware that supports LDAPS. Where none exists, this belongs with that vendor, and no Windows licence changes it.
• Linux and Unix hosts: normally a configuration change in the LDAP client library plus the CA certificate in the trust store.
• Scripts and scheduled tasks written years ago against port 389: often the largest group by count and the easiest to fix.
• Servers on a Windows build that no longer receives updates: the one case where there is nothing to configure.

If you have to retreat

Setting the controllers back to accepting unprotected binds works immediately and puts you back where you started, which is exposed. If you do it, do it with a date attached and a list of the clients you are waiting on. An indefinite retreat is how the estate ends up in the same position two years later with more clients on the list, not fewer.

Every code this article covers

Confirm the fix worked

1. A test bind on port 636 with SSL succeeds against every domain controller, not just the first one you tried.
2. Event 2889 no longer names the application you fixed, over a full day rather than a single test.
3. The Event 2887 counts have fallen to zero and stayed there for a business cycle before you enforce anything.
4. After enforcement, Event 2888 reports zero rejected binds.
5. certutil -DCInfo Verify reports the domain controller certificates as valid on each controller.

Questions people ask about this