LDAP Signing & Channel Binding Troubleshooting (2026): Event 2889, 3074/3075 & Windows Server 2025 Enforcement

Updated: August 6, 2026

LDAP signing and channel binding troubleshooting on Windows Server 2025 comes down to three questions: which clients are still doing unsigned binds, why they still are, and whether you can move them before enforcement takes the phones down. In my helpdesk, the vast majority of "the app broke after the DC patched" tickets since Windows Server 2025 went GA trace back to Event ID 2889, Event ID 3074, or Event ID 3075 in the Directory Services log. Get those three events feeding a SIEM, work the list, and this stops being an outage story.

• Windows Server 2025 promoted with a new forest enforces LDAP signing by default and audits channel binding. Clients doing unsigned simple binds on port 389 will fail immediately.
• Event ID 2889 identifies the client IP and account making unsigned binds; Event IDs 3074 and 3075 identify clients that omit or send an invalid Channel Binding Token.
• Set the registry value 16 LDAP Interface Events = 2 on every DC to turn on the diagnostic logging that generates these events.
• Audit for at least 30 days before flipping "LDAP server signing requirements" to Require signing. Most environments discover between 5 and 40 non-compliant systems they didn't know about.
• The fix for most non-compliant apps is LDAPS on port 636 or StartTLS on 389 with a proper certificate and DNS name, not relaxing the DC policy.
• Load balancers that terminate and re-originate TLS in front of your DCs will break channel binding regardless of what the endpoint does, so plan for that separately.

What LDAP signing and channel binding actually do

LDAP signing forces every LDAP request and response between a client and a domain controller to be cryptographically signed, so an attacker sitting on the wire can't silently rewrite an add-member or password-reset operation. Channel binding goes one step further. On top of a TLS-wrapped LDAP session (LDAPS on port 636 or StartTLS on 389), the client proves that the same TLS session it thinks it's on is the one the DC sees, by binding a token derived from the server certificate into the authentication exchange. Without both, a determined attacker with any kind of network foothold can relay authentication and modify Active Directory. That's not a theoretical threat. Honestly, the LDAP-relay path is one of the most reliable ways I've seen Red Team engagements go from "one dropped shell" to "domain admin" in a lunch break.

The reason unsigned LDAP survived so long is that it "just worked" for everything: appliances, scripts, and 15-year-old ERP integrations that were written when Active Directory was called Windows 2000 Server. Enforcing signing breaks all of that at once. That is why the practical work is not the GPO click. It's the inventory. The Microsoft Learn LDAP signing documentation is worth reading end-to-end before you start, but it will not tell you which of your applications are broken. Only Event 2889 and its friends can do that.

What Windows Server 2025 changed and why 2026 tickets look different

Before Windows Server 2025, the LDAP signing policy on domain controllers shipped as "None." Clients could negotiate signing but nothing was enforced, and channel binding auditing was off. A new forest promoted on Server 2025 enforces LDAP signing on the DCs by default, defaults channel binding to "When supported," turns on the 3074/3075 audit events, and prefers LDAP client encryption. Existing domains upgraded in place inherit their old settings, but any freshly promoted DC brings the new defaults with it, which is precisely why a helpdesk that "just added a new DC last week" starts seeing broken apps this week.

The other change worth knowing is that Server 2025 introduces a second, higher-priority signing policy: Domain controller: LDAP server signing requirements enforcement. When this new policy is configured, it overrides the older Domain controller: LDAP server signing requirements setting. That lets you leave the audit policy in place while you temporarily relax enforcement for a specific pain-point application, which is a much cleaner escape hatch than the "back it out and start over" workflow we had on earlier versions. The Server 2025 LDAP updates post on the Microsoft Community Hub has the exact GPO paths for both policies.

The important thing to communicate to leadership is that this is not a fire drill Microsoft dropped this year. Microsoft has been telegraphing this for six years across KB4520412 and multiple advisories. What Server 2025 changes is who bears the cost of the default: it used to be "everyone who ever got compromised through LDAP relay." It now becomes "everyone with a legacy client they haven't inventoried."

How to turn on the diagnostic logging that generates 2889, 3074, and 3075

None of these events fire on a fresh DC. You have to enable the LDAP Interface Events diagnostic level first, on every DC in the domain. If you only enable it on one, you'll only see the fraction of unsigned traffic that happens to land on that box. Run this from an elevated PowerShell prompt against each DC:

# Enable LDAP Interface Events diagnostic logging on every DC
$dcs = (Get-ADDomainController -Filter *).HostName
foreach ($dc in $dcs) {
    Invoke-Command -ComputerName $dc -ScriptBlock {
        $key = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics'
        Set-ItemProperty -Path $key -Name '16 LDAP Interface Events' -Value 2 -Type DWord
        Write-Output "$env:COMPUTERNAME set to level 2"
    }
}

A value of 2 logs basic events including 2889 (unsigned binds) and 3074/3075 (channel binding). No reboot is required; the change is picked up by NTDS immediately. If you're paranoid about log volume, set it during a quiet window and monitor the Directory Services log size for the first hour. On a typical domain of a few thousand endpoints, I've seen it add roughly 10 to 50 MB per DC per day, which is fine for centralized log forwarding but might dwarf a small local log if you left the default 20 MB cap in place.

Channel binding audit events have one more prerequisite that trips people up. They only fire when the Domain controller: LDAP server channel binding token requirements policy is set to "When supported" or "Always". Leaving it at Never (the pre-2025 default) means you will never see 3074 or 3075 no matter how much you enable the diagnostic. Configure the GPO to "When supported" during the audit window so failures log without blocking connections. Setting it to "Always" during audit will block them, which defeats the point.

How do I decode Event ID 2889?

Event ID 2889 is the workhorse of an LDAP signing rollout. It fires every time a client completes an unsigned bind against the DC. The event body contains three fields you actually care about: the Client IP:port, the Identity the client authenticated as, and the Binding Type, where 0 means a SASL bind without signing (common from Java LDAP libraries), and 1 means a simple bind without TLS (common from appliances and homegrown scripts).

Get the last 24 hours of 2889 events across the domain into a spreadsheet and dedupe on IP + identity. That gives you your target list. Usually 5 to 40 rows even in large environments, because unsigned LDAP tends to be concentrated in a handful of clients making a lot of connections. Here's the query I use:

# Collect Event ID 2889 across all DCs into one CSV
$dcs = (Get-ADDomainController -Filter *).HostName
$since = (Get-Date).AddDays(-1)

$results = foreach ($dc in $dcs) {
    Get-WinEvent -ComputerName $dc -FilterHashtable @{
        LogName   = 'Directory Service'
        Id        = 2889
        StartTime = $since
    } -ErrorAction SilentlyContinue | ForEach-Object {
        # Property indexes: 0 = client IP:port, 1 = identity, 2 = binding type
        [pscustomobject]@{
            DC          = $dc
            TimeCreated = $_.TimeCreated
            ClientIP    = $_.Properties[0].Value
            Identity    = $_.Properties[1].Value
            BindingType = $_.Properties[2].Value  # 0=SASL 1=SimpleBind
        }
    }
}

$results |
    Group-Object ClientIP, Identity, BindingType |
    Select-Object Count, Name |
    Sort-Object Count -Descending |
    Export-Csv -NoTypeInformation -Path C:\Temp\ldap-unsigned.csv

Once you have the list, resolve each IP to a hostname (reverse DNS is usually good enough; if you have Defender for Identity, its device inventory is faster) and start filling in an "owner" column. That column is the one that determines how long remediation takes. Not the technical fix, but who signs off on changing the LDAP integration on the accounting system nobody's touched since 2019. So, if you're new to reading Directory Service events at scale, our Windows Event Viewer troubleshooting guide covers the filter syntax and PowerShell patterns that make this bearable.

How do I fix Event IDs 3074 and 3075 channel binding failures?

Event ID 3075 fires when a client authenticates over an LDAP-over-TLS session but doesn't provide a Channel Binding Token at all. Event ID 3074 fires when the client provides a token, but it doesn't match the DC's TLS session, usually because a middlebox terminated TLS between the two ends. Between them, they cover essentially every real-world failure mode for channel binding.

The remediation depends entirely on which one you're seeing. For 3075, the client needs to be updated so it supports EPA (Extended Protection for Authentication) and includes the CBT in its bind. On Windows, that support has been available since CVE-2017-8563 shipped, but the client library the application uses has to opt in. In practice: modern .NET LDAP clients using System.DirectoryServices.Protocols with SessionOptions.ChannelBinding = true and current Java UnboundID LDAP SDK builds handle this correctly; older Novell JLDAP, ancient PHP ldap_bind() builds, and most self-written Perl integrations do not.

For 3074, the fix is architectural. The client is sending a token derived from a certificate that is not the certificate the DC is presenting. That happens when a load balancer or WAF terminates TLS with its own cert and re-encrypts to the DC, or when a client is pinned to an old cert after a DC certificate rotation. Rotate the client's trust anchor, take the middlebox out of the LDAP path (or configure it in TCP passthrough mode), and 3074 goes away.

LDAPS, StartTLS, and simple binds: the port and protocol map

Half of the tickets I've triaged around signing enforcement come from people who don't have a clear mental model of which port does what. Here's the version I've printed on a card next to the helpdesk queue:

Attribute	Simple bind on 389	StartTLS on 389	LDAPS on 636
Transport encryption	None	Negotiated TLS after connect	TLS from first byte
Requires DC certificate	No	Yes	Yes
Signing satisfies policy?	Only if wrapped in Kerberos/NTLM SASL signing	Yes, when SASL binds are used	Yes, because TLS provides the integrity
Channel binding compatible?	N/A (no TLS)	Yes	Yes
Common failure mode after enforcement	Rejected outright ("Strong(er) authentication required")	Cert-name mismatch, TLS 1.2 disabled on client	Cert-name mismatch, load balancer breaking channel binding
Recommended for new integrations?	Never	Acceptable	Preferred

The certificate the DC presents on 636 has to have a Subject Alternative Name matching the fully qualified domain name the client used to connect. A common failure I see is a client hard-coded to dc01 instead of dc01.corp.contoso.com, which works over an unsigned bind but fails hostname validation the second you turn on TLS. If your DCs are using auto-enrolled certificates from AD CS with a Kerberos Authentication template, you're already fine on the SAN front. That said, see our ADCS security guide for how those templates interact with hardening controls, because the same template that fixes SANs can open ESC-class vulnerabilities if the ACLs aren't right.

Remediating the clients you will actually find

After running the audit query on dozens of environments, roughly the same shortlist of offenders appears. Here's the one I keep, in rough order of frequency:

1. Print servers and multifunction printers. Enterprise MFPs authenticate to LDAP for the address book and for "scan to email." Nearly every model made before 2020 defaults to simple bind on 389. Firmware updates from Xerox, Konica, Canon, and Ricoh in the past 24 months add LDAPS support, but the config is a hidden checkbox that has to be flipped per device. Combine this rollout with our printer troubleshooting guide to work through the fleet.
2. Backup software using service accounts. Veeam, Commvault, and older Backup Exec install profiles pointing at 389. In every recent version those products support LDAPS; you're editing a connection string, not upgrading the software.
3. Java applications with the default JNDI provider. Almost all of them do SASL DIGEST-MD5 without signing (Binding Type 0). The fix is usually setting java.naming.security.protocol=ssl and pointing at 636, plus importing the CA cert into the JVM's cacerts. Occasionally the app owner will insist "we can't change it." They can; it's a properties file.
4. Homegrown PowerShell using [ADSI]. [ADSI]"LDAP://..." uses signed binds by default. [ADSI]"LDAP://server:389" with a port disables the signing negotiation. Fix is to remove the port or switch to System.DirectoryServices.Protocols.
5. Linux/UNIX SSSD and nslcd. Distributions ship configs that work on unsigned 389 out of the box. Set ldap_id_use_start_tls = true in /etc/sssd/sssd.conf, put the CA cert in /etc/openldap/cacerts, and run authselect apply-changes.
6. Network appliances doing LDAP auth for admin login. Firewalls, switches, and VPN concentrators. Same story as MFPs: the firmware has the option; nobody enabled it. The VPN troubleshooting guide covers the specific config paths for the common vendors.

Whatever you do, resist the urge to reduce enforcement so the appliance keeps working. Every environment that told me "we'll fix it next year" ended up at least once with a Red Team walking straight through it, and the year passed anyway.

The load balancer trap and other footguns

The single most common thing that turns an LDAP hardening project into a two-month outage is a load balancer in front of the DCs. If your load balancer terminates TLS and re-encrypts to the backend, every client connection appears to the DC as coming from a single IP with a single TLS session. Event ID 2889 shows you the load balancer IP for every unsigned bind, and channel binding is architecturally impossible because the certificate presented to the client isn't the certificate the DC has.

The remediation is to run the LDAP virtual server in TCP passthrough mode: no TLS termination, no health probes that do LDAP binds, just Layer 4 forwarding. If you can't do that (some architectures depend on the load balancer for client affinity), you need to point the affected clients directly at DCs instead of the VIP, at least for the LDAP path. The Part 5 of the Microsoft AD Hardening series has a diagram of the failure mode that's worth showing your network team.

Other footguns worth flagging in your rollout plan: DCs with expired or self-signed certificates (LDAPS still starts, but modern clients reject it and fall back to unsigned 389); Netlogon DNS registrations pointing at the wrong site (clients connect to the wrong DC and log 2889 events on a box that "shouldn't be seeing traffic"); replication problems that leave one DC out of the loop and applying old GPOs. Chase those down through our Active Directory replication troubleshooting guide before you enforce. And if channel binding suddenly starts failing on a wave of endpoints after they patched, check for a certificate rollover on the DC. You'll see the same 3074 spike we discussed above.

A rollout playbook from audit to enforcement

The playbook I hand new team leads for this looks like a boring project plan on purpose, because the technical work is small and the coordination work is large.

1. Week 0: Enable 16 LDAP Interface Events = 2 on every DC. Set channel binding GPO to "When supported." Point Directory Service events on all DCs at your SIEM.
2. Weeks 1–4: Collect. No changes to the DCs. Build the offenders list from Event 2889 + 3074 + 3075. Assign an owner to each row.
3. Weeks 4–8: Remediate. Fix printers, backup jobs, Java apps, PowerShell scripts, and Linux workstations. Verify each fix by watching the offender's IP fall out of the daily 2889 count. Group Policy misapplication is a common blocker here, so if a fix "doesn't stick" on some DCs, walk through our GPO troubleshooting guide.
4. Week 8: Enforce signing on one DC by setting the new Server 2025 LDAP server signing requirements enforcement policy on a filtered OU. Monitor for a week. If you're still on Server 2022, use the legacy LDAP server signing requirements policy scoped to one DC.
5. Week 9: Enforce signing domain-wide. Watch Event ID 2888 (rejected unsigned binds) for a spike, since that's the "we missed one" indicator.
6. Weeks 10–12: Flip channel binding from "When supported" to "Always." At this point 3074/3075 counts should be at or near zero. The same escape hatch (a filtered rollout) applies. Once you're clean, you're done.

The reason this cadence works is that it separates the two policies. Enforcing signing has a well-understood blast radius: some apps break, you know which ones. Enforcing channel binding failures are subtler, especially with middleboxes involved. Doing them in one push means every ticket looks the same and root-causing gets hard. Splitting them keeps the diagnosis simple, and simple diagnoses close tickets fast.

Frequently Asked Questions

What is the difference between LDAP signing and LDAP channel binding?

LDAP signing cryptographically signs the LDAP request/response body so it can't be tampered with in transit; it works whether or not the transport is encrypted. Channel binding is only used when the LDAP session is wrapped in TLS (LDAPS or StartTLS) and cryptographically binds the authentication to the specific TLS session, preventing a middlebox from relaying the auth. In practice you want both, but they enforce at different layers.

How do I check if LDAP signing is enabled on my domain controllers?

Run Get-ADRootDSE | Select-Object ldapServiceName to confirm the DC is up, then check the effective setting with gpresult /h report.html and look under Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options for "Domain controller: LDAP server signing requirements." A registry check on the DC (Get-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters -Name LDAPServerIntegrity) returns 1 for None, 2 for Require signing.

Does LDAPS on port 636 require channel binding?

Not automatically. LDAPS gives you the TLS transport, but the channel binding policy is separate. When "Domain controller: LDAP server channel binding token requirements" is set to "Always," an LDAPS client that doesn't include the CBT is rejected; when set to "When supported," it's allowed but logged. TLS by itself does not stop LDAP relay attacks, which is what channel binding closes.

What causes LDAP error 8341 or "Strong(er) authentication required"?

That error means the DC rejected an unsigned bind attempt because the LDAP server signing policy is set to "Require signing." The client either did a simple bind on port 389 or a SASL bind without negotiating signing. The fix is to have the client use LDAPS on 636, StartTLS on 389, or negotiate integrity/signing during the SASL exchange, not to relax the DC policy.

How long should I audit before enforcing LDAP signing?

Microsoft and the community consensus is 30 days minimum. Some clients only touch LDAP for a monthly job: payroll integrations, month-end reporting, quarterly billing runs. If you can afford a full quarter of audit before enforcement in a large environment, take it. Enforce sooner and you will discover the miss during a business-critical window, which is the ticket you never want.

Will enforcing LDAP signing break Kerberos or NTLM authentication?

No, signing enforcement applies to the LDAP protocol specifically, not to Kerberos ticket exchanges or NTLM negotiation for other services. That said, some applications use LDAP as a preflight check before falling back to Kerberos, and if the preflight fails they never get to the ticket step. If you see broader authentication weirdness after enforcement, cross-check with our Kerberos troubleshooting guide to confirm the LDAP change didn't mask something else.