Find Cleartext LDAP Binds Before They Break

Part 2 of 6 · Moving Past LDAP Simple Bind

Landed here first? No problem – this one reads fine on its own. All you really need from the rest of the series is this: “securing LDAP” is three different jobs, not one – protecting the connection, proving the login, and locking down the account. This article is about why the old way of doing it quietly fails all three.

In Part 1, I argued that “fixing LDAP” is really three separate jobs – securing the data in transit (A), securing the authentication (B), and securing the account itself (C) – and that doing one does not do the other two. If you only have a second: a sealed tunnel around a reusable password on an over-privileged account is not secure. Hold that framing; this part shows you exactly where simple bind fails, sorted by those three concerns.

𝗪𝗵𝗮𝘁 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗴𝗼𝗲𝘀 𝘄𝗿𝗼𝗻𝗴

Simple bind is one of two ways LDAP can authenticate (the other is SASL, which Part 4 covers). The client hands over a distinguished name or UPN and the account password directly. When that request is not wrapped in TLS, the password is on the wire in cleartext – readable by anything sitting on the network path.

The password is on the wire in cleartext, readable by anything

It helps to sort the usual failures by which concern each one belongs to, because that is precisely why no single fix covers them all.

𝗧𝗿𝗮𝗻𝘀𝗶𝘁 𝗽𝗿𝗼𝗯𝗹𝗲𝗺𝘀 (𝗖𝗼𝗻𝗰𝗲𝗿𝗻 𝗔)

Cleartext credential exposure: on an unencrypted connection, anyone who can capture packets reads the password directly.
Man-in-the-middle: on plain port 389 the client does not verify a server certificate, so an attacker can impersonate the domain controller and harvest the bind.
No integrity protection: without signing, request and response contents can be altered in flight without anyone noticing.

𝗔𝘂𝘁𝗵𝗲𝗻𝘁𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗽𝗿𝗼𝗯𝗹𝗲𝗺𝘀 (𝗖𝗼𝗻𝗰𝗲𝗿𝗻 𝗕)

Credential relay and replay – a captured password bind can be reused against other services to impersonate the victim, because the password is reusable by design.

𝗜𝗱𝗲𝗻𝘁𝗶𝘁𝘆 / 𝗮𝗰𝗰𝗼𝘂𝗻𝘁 𝗽𝗿𝗼𝗯𝗹𝗲𝗺𝘀 (𝗖𝗼𝗻𝗰𝗲𝗿𝗻 𝗖)

Audit blind spots and over-privilege – service accounts doing simple binds are frequently shared and granted far more access than they need, which makes misuse both more damaging and harder to attribute.

A, B & C - 3 Failures

A, B & C – 3 Failures

𝗪𝗵𝗮𝘁 𝗰𝗵𝗮𝗻𝗴𝗲𝗱 𝗶𝗻 𝗪𝗶𝗻𝗱𝗼𝘄𝘀 𝗦𝗲𝗿𝘃𝗲𝗿 𝟮𝟬𝟮𝟱

Earlier Windows Server releases accepted unsigned LDAP and unprotected simple binds by default. Windows Server 2025 raises the floor for new deployments. It is worth being precise here, because there is a lot of loose information floating around on this one.

𝗟𝗗𝗔𝗣 𝘀𝗶𝗴𝗻𝗶𝗻𝗴 𝗶𝘀 𝗿𝗲𝗾𝘂𝗶𝗿𝗲𝗱 𝗯𝘆 𝗱𝗲𝗳𝗮𝘂𝗹𝘁 𝗼𝗻 𝗻𝗲𝘄 𝗱𝗲𝗽𝗹𝗼𝘆𝗺𝗲𝗻𝘁𝘀. A new policy: Domain controller: LDAP server signing requirements enforcement ships unconfigured and behaves as “Require signing.” In practice the DC now rejects unsigned binds, which is what closes the relay and tampering exposure. An unprotected cleartext simple bind on port 389 is unsigned, so it fails too. (In-place upgrades preserve your existing setting rather than flipping this on.)
𝗖𝗵𝗮𝗻𝗻𝗲𝗹 𝗯𝗶𝗻𝗱𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗼𝗻𝗲 𝘁𝗼 𝘃𝗲𝗿𝗶𝗳𝘆, 𝗻𝗼𝘁 𝗮𝘀𝘀𝘂𝗺𝗲. This is exactly the loose information I warned about. Microsoft’s own documentation is inconsistent: one current Microsoft Learn page lists the 2025 default as “When supported,” while other Microsoft and independent sources say channel binding behavior did not change and remains “Never” until you configure it. What is not in dispute: signing is the control 2025 actually tightened, and channel binding is not “Always” by default either way – so enforcing it is still a choice you make. Confirm the live value on your specific build before relying on it.
𝗔 𝘀𝗶𝗺𝗽𝗹𝗲 𝗯𝗶𝗻𝗱 𝘀𝘁𝗶𝗹𝗹 𝘄𝗼𝗿𝗸𝘀 𝗶𝗻𝘀𝗶𝗱𝗲 𝗧𝗟𝗦. This is the subtlety that surprises people. Requiring signing does not ban simple bind; it bans the unsigned, cleartext one. A simple bind carried inside LDAPS or StartTLS is still accepted. (Part 6 returns to this with the controlled exception.)

𝗙𝗶𝗻𝗱 𝘁𝗵𝗲 𝗰𝗹𝗲𝗮𝗿𝘁𝗲𝘅𝘁 𝗯𝗶𝗻𝗱𝘀 𝗯𝗲𝗳𝗼𝗿𝗲 𝘁𝗵𝗲𝘆 𝗯𝗶𝘁𝗲

Here is the most important practical step in the entire series, and it costs you nothing but patience: audit before you enforce. Turn on LDAP Interface Events on your existing DCs and watch the Directory Service log. Two events do the heavy lifting:

Event ID 2887: a periodic count of unsigned or cleartext simple binds received, so you know the scale.
Event ID 2889: names the client IP and the account behind each unsigned or cleartext bind. This is your remediation punch list.

Audit before enforcing

1. Raise LDAP Interface Events to level 2 on a DC:

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

2. Then mine the 2889 events for the offending clients and accounts:

Get-WinEvent -LogName ‘Directory Service’ | Where-Object { $_.Id -eq 2889 } | Select-Object TimeCreated, @{n=’Client’;e={$_.Properties[0].Value}}, @{n=’Identity’;e={$_.Properties[1].Value}}

Let it run for about 30 days, drive the relevant events toward zero through remediation, and only then enable enforcement – changing one setting at a time. Legacy clients, scanners, appliances, copiers, and home-grown scripts that do cleartext simple bind on port 389 will fail against a 2025 DC. The good news is you can find every one of them before they break.

find each before they break

𝗧𝗵𝗶𝘀 𝗶𝘀 𝗣𝗮𝗿𝘁 𝟮 𝗼𝗳 𝗮 𝟲-𝗽𝗮𝗿𝘁 𝘀𝗲𝗿𝗶𝗲𝘀.

Previously: Part 1: Did You Really Secure LDAP – or Just One-Third of It? The three-jobs framing this series runs on.
Next: Part 3: Is Your “Encrypted” LDAP Actually Protected? We tackle Concern A properly: LDAPS, StartTLS, and the trap that makes “encrypted” quietly meaningless.

Full series:

Part 1 – Did You Really Secure LDAP – or Just One-Third of It?
Part 2: Is Your Domain Controller Leaking Passwords? (this article)
Part 3 – Is Your “Encrypted” LDAP Actually Protected?
Part 4 – Why Send a Password You Can’t Take Back?
Part 5 – When Did That Service Account Last Rotate?
Part 6 – Are You Hoping Your LDAP Is Secure – or Do You Know?

Run the audit – were you surprised by what showed up in your 2889 events? Almost everyone is.

If you’re going to run that 2887/2889 audit this week, repost this so a peer runs theirs too – most teams have no idea what’s binding in cleartext until they look. Follow for Part 3, where “encrypted” turns out not to mean “protected.”

If this is making you want to check your own Directory Service logs — good, that’s the point. Repost it so someone else checks theirs. Drop a comment when you’ve run it: were you surprised by what showed up?

Find Cleartext LDAP Binds Before They Break supporting illustration

𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀:

𝗚𝗹𝗼𝘀𝘀𝗮𝗿𝘆

Simple bind: an LDAP login that sends an account name and password directly. Safe inside TLS; risky in cleartext.
SASL: Simple Authentication and Security Layer; a standard “slot” in LDAP that lets a stronger login method plug in place of a password (covered in Part 4).
Distinguished name (DN) / UPN: two ways of naming the account logging in: the full directory path, or the user-principal-name form (user@domain).
TLS: Transport Layer Security; the encryption that wraps a connection so it cannot be read or altered in transit.
LDAPS / StartTLS: the two ways to put LDAP inside TLS: a dedicated secure port (LDAPS, 636), or an upgrade of the standard port (StartTLS, 389).
Signing: an integrity control that signs LDAP messages so tampering in transit is detected and rejected; an unsigned cleartext bind is what 2025 blocks.
Channel binding (CBT): a token that ties a login to the specific TLS session it was made in, so a captured login cannot be replayed onto another connection.
Relay / replay attack: capturing a valid authentication and reusing it against a different server to impersonate the victim.
Man-in-the-middle (MITM): an attacker on the network path who can read or alter traffic between client and server.
Domain controller (DC): the server that holds the directory and answers authentication requests.
Event ID 2887 / 2889: Directory Service log events: 2887 counts unsigned/cleartext binds; 2889 names the client and account behind each one.

#ActiveDirectory #LDAP #WindowsServer2025 #BlueTeam #IdentitySecurity

Is Your Domain Controller Leaking Passwords? (Part 2 of 6)