Getting Ready to Enforce LDAP Signing and Channel Binding

July 8, 2026 · InfraScout Team

You want to enforce LDAP signing and channel binding on your domain controllers, and first you need to know which clients would break. That sounds like one event log query. In practice it rarely is: the evidence is often missing, the certificate LDAPS presents may not be the one you think, and the Directory Service log is full of failed-bind noise you have to sort into benign and real.

This post walks through what it looks like to hand that job to InfraScout in a chat. You end up with logs that actually retain the evidence, a diagnostic-logging policy that sticks, clean LDAPS certificate selection, and change tickets for the teams that own the offending clients. Here is how that conversation typically goes.

The question you start with

You don't need to know which events to look for. You describe the goal and let the AI plan the investigation:

We plan to enforce LDAP signing and channel binding on our domain controllers.
Find every client that currently binds without signing or channel binding,
check that the evidence on the DCs is complete, and tell me what would break.
Ask before changing anything.

The AI starts from its memory of your environment, sees notes that LDAP diagnostic logging was enabled earlier, opens sessions on your domain controllers, and queries the Directory Service log. All of that is read-only, so it runs without interrupting you.

When the evidence isn't there

The event you are after is 2889, which lists each client performing an unsigned or simple bind. On a first pass, a common result is that there are no 2889 events at all. The AI may reach for related events instead, and this is where you steer. Ask whether that is the same thing, and it clarifies that it isn't.

If you then say your SIEM does show 2889 events, the AI doesn't defend its earlier answer. It re-queries both domain controllers with wider time windows, and when nothing turns up locally it looks for the reason. Typically the Directory Service log is still at its very small default size and wraps within minutes. The AI calculates actual retention from the oldest and newest records, for the Directory Service log and for the Security log too, which may cover only a few days. It proposes new sizes, you pick one, and it resizes the logs on each domain controller once you approve.

TIP

Check event log retention by time, not by size. The size setting tells you nothing until you compare the oldest record with the newest one.

Making sure policy doesn't undo the fix

The obvious next question is whether Group Policy will reset those sizes. The AI reads the applied policy values in the registry, the GPO files behind them, link order, and resultant policy. It keeps the units straight: the Group Policy event log setting is in kilobytes, while the registry value it writes is in bytes. If you export a GPO report, the AI can use it to pinpoint the policy that wins.

The same check matters for the diagnostic logging switch. Event 2889 only appears when the "16 LDAP Interface Events" value under NTDS Diagnostics is set to 2 or higher. It is common to find the value set on one domain controller and missing on the other. When the AI sets it manually and then runs a forced policy refresh, which it proposes only after checking for active Remote Desktop sessions, the value reverts. That proves a managed policy still enforces "off." The durable fix is at the policy level: once it's corrected, the AI refreshes and re-validates both domain controllers and closes the related insight.

INFO

A security baseline or a higher-precedence GPO can quietly override your custom policy. Always confirm the winning GPO in resultant policy before you call a setting fixed.

Which certificate LDAPS actually presents

Channel binding ties the LDAP session to the TLS channel, so the LDAPS certificate is part of your readiness check. A natural question is whether you can pin the LDAPS certificate to a specific template. The AI answers from current Microsoft documentation: you can't. Schannel picks the certificate automatically, and any valid certificate with the Server Authentication purpose in the machine store or the NTDS service store can win.

To find out what's winning, the AI inventories the certificate stores on each domain controller, the certificate templates in Active Directory, and the templates your CA actually issues (using certutil for issued templates and their permissions). A frequent result is that a general-purpose computer authentication certificate outcompetes the intended domain controller certificate. The AI checks the certificate bound to Remote Desktop as well, since a dedicated Remote Desktop Authentication purpose exists and RDP doesn't need a Server Authentication certificate.

The fix comes in two parts. First, you deny enrollment for domain controllers on the offending template. That stops future issuance but doesn't remove certificates that already exist. Second, the AI proposes deleting the stale certificates, shows you the store before and after, and waits for your yes. It works one domain controller at a time and verifies each change with a live TLS handshake on port 636, confirming the intended certificate is the one presented.

WARNING

Deny-enroll permissions only affect new requests. Existing certificates keep competing for LDAPS until you remove them, so verify with a live handshake rather than trusting the template change.

Sorting failed-bind noise into benign and real

With the evidence flowing, the Directory Service log often looks alarming. Some failed-LDAP events turn out to be informational and arrive on a fixed polling interval, for example ones tied to AD-integrated DNS and conditional forwarders. A regular cadence is a strong hint that you're looking at a scheduled process, not an attack.

Other events carry real signal. Event 1535 with "invalid credentials" in its data means a bad password. The AI correlates those with Security event 4625 to get the source and the account. A typical outcome is a single Linux service account with a stale password, used by many Linux hosts and generating continuous bad-password binds. Those are exactly the clients you need fixed before you enforce anything.

Handing off to the owning teams

Once the findings are clear, the AI drafts change tickets for the owning teams through your ticketing system's MCP server. You review each ticket before it's created. The AI also saves what it learned to memory and corrects the earlier notes that the live checks proved partly wrong, so your next conversation starts from accurate facts.

Where you stay in control

Throughout the investigation, read-only queries run freely, and every change to state is proposed first and waits for your explicit go-ahead. That includes resizing logs, changing policy values, forcing a policy refresh, deleting certificates, and creating tickets. Changes are staged per domain controller and verified before the next one. Whether a tool needs approval comes from its annotations and your role, not from the AI's judgment.

Just as important, you can challenge any conclusion, and the AI re-checks the live systems instead of defending a stale answer. That is often the step that surfaces the real problem.

Expect the whole exercise to take a few working sessions of under an hour or so each. You finish with larger event logs and a documented baseline, a diagnostic-logging policy that holds, domain controllers that present the intended LDAPS certificate, a list of the clients that would break, and tickets in the hands of the people who can fix them.

Next steps

• Persistent memory explains what the AI remembers about your environment and how to inspect it.
• Insights covers how findings are recorded, tracked, and closed.
• Tool annotations and roles shows how approvals for state-changing tools work.
• MCP servers describes connecting external systems such as your ticketing tool.