Are You Hoping Your LDAP Is Secure – or Do You Know? (Part 6 of 6)

Enabling businesses to self-secure providing enterprise-grade security practices, regardless of size. Businesses shouldn’t REQUIRE massive IT security teams to keep their business safe.

Part 6 of 6 · Moving Past LDAP Simple Bind

This is the finale, but don’t worry if it’s your first stop – it stands on its own. The idea the whole series is built on: securing LDAP isn’t one task, it’s three – the connection, the login, and the account – and the trick is doing all three, in the right order. This part is where they come together.

This series has separated “securing LDAP” into three jobs – the connection (A), the login (B), and the account (C) – and shown that doing one is not doing the other two. The earlier parts took each in turn: the exposure and the 2025 changes (Part 2), then the connection (Part 3), the login (Part 4), and the account (Part 5). This final part puts the pieces in order, handles the one infrastructure question that always comes up (the F5), and documents the escape hatch for the legacy system that just will not move yet.

𝗔 𝗺𝗶𝗴𝗿𝗮𝘁𝗶𝗼𝗻 𝗽𝗮𝘁𝗵 𝘁𝗵𝗮𝘁 𝗿𝗲𝘀𝗽𝗲𝗰𝘁𝘀 𝗮𝗹𝗹 𝘁𝗵𝗿𝗲𝗲 𝗰𝗼𝗻𝗰𝗲𝗿𝗻𝘀

So where do you actually start? Not by flipping a setting – by looking. This sequence deliberately tackles all three concerns rather than just the one that is easiest to turn on:

1. 𝗗𝗶𝘀𝗰𝗼𝘃𝗲𝗿 – turn on LDAP Interface Events (level 2); collect Event IDs 2887/2889 across all DCs to inventory every cleartext or unsigned bind (Concerns A and B in plain sight). This is the Part 2 audit.

2. 𝗣𝗿𝗶𝗼𝗿𝗶𝘁𝗶𝘇𝗲 – map each finding to an owner and a target: move to Kerberos/SASL (B), wrap in LDAPS/StartTLS (A), move to a gMSA/dMSA and trim rights (C), or retire it.

3. 𝗕𝘂𝗶𝗹𝗱 𝘁𝗵𝗲 𝗰𝗵𝗮𝗻𝗻𝗲𝗹 (𝗔) – confirm AD CS issues DC certificates, clients trust the chain, and 636/3269 are open; then verify TLS version and ciphers.

4. 𝗙𝗶𝘅 𝘁𝗵𝗲 𝗯𝗶𝗻𝗱 (𝗕) – convert clients to SASL/Kerberos where supported; otherwise LDAPS/StartTLS with channel binding.

5. 𝗙𝗶𝘅 𝘁𝗵𝗲 𝗮𝗰𝗰𝗼𝘂𝗻𝘁 (𝗖) – replace static service accounts with gMSA/dMSA and least privilege.

6. 𝗘𝗻𝗳𝗼𝗿𝗰𝗲 – set signing to Require and channel binding to Always via GPO, one at a time; for F5-fronted services use pass-through or bridging, never cleartext offload (see below).

7. 𝗩𝗲𝗿𝗶𝗳𝘆 – confirm 2889 events reach zero, validate each remediated client, then promote or upgrade to 2025 DCs with confidence.

all three concerns, closed in the right order

𝗢𝗿𝗱𝗲𝗿 𝗼𝗳 𝗽𝗿𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲, 𝗶𝗻 𝗼𝗻𝗲 𝗹𝗶𝗻𝗲: SASL/Kerberos (B) inside LDAPS (A), on a gMSA/dMSA with least privilege (C). That is all three concerns covered on purpose. “We enabled LDAPS” is a good start on one of the three – not a finish line.

𝗣𝘂𝗯𝗹𝗶𝘀𝗵𝗶𝗻𝗴 𝘀𝗲𝗰𝘂𝗿𝗲 𝗟𝗗𝗔𝗣 𝗯𝗲𝗵𝗶𝗻𝗱 𝗮𝗻 𝗙𝟱 𝗕𝗜𝗚-𝗜𝗣

An F5 BIG-IP virtual server fronts a pool of DCs to give clients one resilient endpoint. It delivers Concern A at scale, but it does not change the bind type or the account – and done wrong it can quietly undo the transit protection. The only security-critical decision is what it does with TLS.

The F5 is a smart receptionist in front of several identical DCs. The question that matters is what it does with the sealed envelope:

• Pass-through hands it on still sealed – safest, and it keeps channel binding intact. Preferred.

• Bridging opens and immediately reseals it (re-encrypt) – still safe, use it only if you need layer-7 features.

• Offload opens it and forwards the contents in the open – which recreates the original cleartext problem and must never be used for directory logins.

never offload – it recreates the cleartext problem

𝗛𝗼𝘄 𝘁𝗼 𝗰𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗲, 𝗯𝗿𝗶𝗲𝗳𝗹𝘆:

• Create a pool of the DCs with an LDAPS health monitor (a TLS check on 636, or a test-bind monitor).

• Preferred: a TCP (layer-4) virtual server on 636 with no SSL profiles – pure pass-through – so client TLS and channel binding terminate on the DC.

• If you need layer-7 features, use bridging: a client-SSL profile (VIP cert) and a server-SSL profile that trusts the DC CA.

• Set persistence so a client’s multi-step session stays on one DC, and restrict the VIP to authorized client subnets.

• Disable any plain-389 VIP.

𝗧𝘄𝗼 𝘁𝗿𝗮𝗱𝗲-𝗼𝗳𝗳𝘀 𝘁𝗼 𝗽𝗹𝗮𝗻 𝗳𝗼𝗿.

• First, putting LDAPS behind a VIP costs you client source-IP visibility on the DC (Event ID 2889 will show the balancer, not the real client) so lean on application-side logging where that matters, and prefer pass-through.

• Second, terminating TLS on the F5 changes the session the channel-binding token binds to; if you enforce channel binding to “Always,” prefer pass-through so the client TLS reaches the DC intact.

𝗧𝗵𝗲 𝗰𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗱 𝗶𝗻𝘁𝗲𝗿𝗶𝗺 𝗲𝘅𝗰𝗲𝗽𝘁𝗶𝗼𝗻 – 𝘁𝗲𝗺𝗽𝗼𝗿𝗮𝗿𝗶𝗹𝘆 𝗮𝗹𝗹𝗼𝘄𝗶𝗻𝗴 𝘀𝗶𝗺𝗽𝗹𝗲 𝗯𝗶𝗻𝗱

Sometimes a legacy system genuinely cannot move before the deadline. There is a documented way to keep it working – as a last resort, not a permanent state. Every step here weakens a protection that 2025 turns on for good reason. Treat it as a time-boxed exception with an owner, a ticket, and a hard expiry date, scoped to the fewest possible DCs.

Think of the 2025 defaults as locks the building now ships locked. This is the documented way to prop one door open – on a couple of side entrances, with a guard watching, and a firm date to lock it again. A temporary, logged exception for one tenant who hasn’t replaced their old key – not turning off the alarm for the whole building.

a time-boxed exception with a hard expiry date

𝗙𝗶𝗿𝘀𝘁, 𝗮𝘀𝗸 𝘁𝗵𝗲 𝗵𝗼𝗻𝗲𝘀𝘁 𝗾𝘂𝗲𝘀𝘁𝗶𝗼𝗻. Even with signing required, a simple bind already works inside TLS. What 2025 blocks by default is the unsigned, cleartext simple bind on port 389. So: can the legacy client really not use LDAPS, StartTLS, or Kerberos? If there is any path to one of those, take it – each is far safer than what follows.

𝗧𝗵𝗲 𝘀𝗲𝘁𝘁𝗶𝗻𝗴 𝗰𝗼𝗺𝗯𝗶𝗻𝗮𝘁𝗶𝗼𝗻 (𝘀𝗰𝗼𝗽𝗲𝗱 𝘁𝗼 𝗲𝘅𝗰𝗲𝗽𝘁𝗶𝗼𝗻 𝗗𝗖𝘀 𝗼𝗻𝗹𝘆):

• LDAP server signing requirements ENFORCEMENT → Disabled. Turns off the 2025 default that forces signing; overrides the classic policy.

• LDAP server signing requirements (classic) → None. Writes LDAPServerIntegrity = 1 (negotiate, do not require). Should be None, not Require.

• LDAP server channel binding token requirements → Never (or When supported). LdapEnforceChannelBinding = 0 or 1. Avoid Always for the window.

• Network security: LDAP client signing requirements → Negotiate signing. Leave clients able to negotiate; do not set Require on affected clients.

Registry, scoped to exception DCs only:

– reg add “HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters” /v LDAPServerIntegrity /t REG_DWORD /d 1 /f (1 = None/negotiate; 2 = Require)

– reg add “HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters” /v LdapEnforceChannelBinding /t REG_DWORD /d 0 /f

(The 2025 ‘enforcement’ policy is set to Disabled via GPO, not a single reg value.)

𝗦𝗰𝗼𝗽𝗲 𝗶𝘁 𝗽𝗿𝗼𝗽𝗲𝗿𝗹𝘆 – 𝗱𝗼 𝗻𝗼𝘁 𝗲𝗱𝗶𝘁 𝘁𝗵𝗲 𝗱𝗲𝗳𝗮𝘂𝗹𝘁 𝗽𝗼𝗹𝗶𝗰𝘆. All DCs sit in the Domain Controllers OU, and the Default Domain Controllers Policy hits every one; editing it would re-expose the entire domain. Instead, create a dedicated, security-filtered GPO:

• Create a new GPO (e.g. LDAP-Simple-Bind-Exception-TEMP) and link it to the Domain Controllers OU.

• Raise its link order above the Default Domain Controllers Policy (lower number wins).

• Add a security group (e.g. GRP-DC-LDAP-Exception) containing only the exception DCs’ computer accounts. On the GPO Scope tab, remove Authenticated Users from Apply and add this group with Read + Apply – so it lands only on those DCs.

• Optionally add a WMI filter on host name as a second guard.

• Record the DC list, the requesting system, the owner, the ticket, and a hard expiry date in the GPO description.

• Run gpupdate /force on the targets and verify; no reboot needed for these settings.

𝗧𝗵𝗲𝗻 𝗲𝘅𝗽𝗶𝗿𝗲 𝗶𝘁. Pin the legacy client to those DC names or IPs, keep LDAP Interface Events at level 2 on the exception DCs, and watch Event ID 2889 to track exactly which client and account still bind in cleartext. Drive that to zero, remove the exception GPO, restore the 2025 defaults, and close the ticket. The exit criterion is simple: the legacy client moves to LDAPS, StartTLS, or Kerberos and its 2889 events read zero. Do not let the exception outlive its expiry date.

𝗪𝗵𝗲𝗿𝗲 𝘁𝗵𝗲 𝘀𝗲𝗿𝗶𝗲𝘀 𝗹𝗲𝗮𝘃𝗲𝘀 𝘆𝗼𝘂

Three jobs, done on purpose: a SASL/Kerberos bind, inside an LDAPS tunnel on strong TLS, on a gMSA or dMSA with least privilege – discovered through the 2887/2889 audit, rolled out one setting at a time, with any exception scoped and time-boxed. That is what “secured LDAP” actually means. Not a switch you flip, but three gaps you close deliberately, knowing which is which.

not a switch you flip – three gaps closed on purpose

𝗧𝗵𝗶𝘀 𝗶𝘀 𝗣𝗮𝗿𝘁 𝟲 𝗼𝗳 𝟲 – 𝘁𝗵𝗲 𝗳𝗶𝗻𝗮𝗹𝗲 𝗼𝗳 𝘁𝗵𝗲 𝘀𝗲𝗿𝗶𝗲𝘀.

Previously – Part 5: When Did That Service Account Last Rotate?

New to the series? Start at Part 1: Did You Really Secure LDAP – or Just One-Third of It? The three-jobs framing everything builds on.

Full series:

• Part 1 – Did You Really Secure LDAP – or Just One-Third of It?

• Part 2 – Is Your Domain Controller Leaking Passwords?

• 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? (this article)

Which of the three jobs had your environment quietly skipped? For most teams it’s B or C.

That’s the series. If it moved you from “hoping” to “knowing” on even one of the three gaps, repost the whole series for your team — and start with the discovery audit, not a setting. Follow if you want more like this; new readers can start at Part 1.

If you read all six – thank you, genuinely. Tell me in the comments which of the three jobs your environment had quietly skipped (for most teams it’s B or C), and repost the series for someone who’s still on “we turned on LDAPS.”

𝗥𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀:

• Manage LDAP signing using Group Policy

• Configure certificates for LDAP over SSL (LDAPS)

• Manage Transport Layer Security (TLS) in Windows Server

• F5 BIG-IP LTM – SSL profiles, SSL bridging vs offload, and LDAPS health monitors (F5 product documentation)

𝗚𝗹𝗼𝘀𝘀𝗮𝗿𝘆

• F5 BIG-IP: a load balancer that fronts a pool of domain controllers to give clients one resilient endpoint.

• VIP: virtual server / virtual IP; the single endpoint on the load balancer that clients connect to.

• Pass-through: F5 mode that forwards traffic still encrypted to the DC (preferred; keeps channel binding intact).

• Bridging: F5 mode that decrypts and immediately re-encrypts (safe; used for layer-7 features).

• Offload: F5 mode that decrypts and forwards in cleartext; never use for directory logins.

• GPO: Group Policy Object; the mechanism Windows uses to apply settings consistently across a domain.

• OU: Organizational Unit; a container in Active Directory used to group objects so policy can be targeted at them.

• Default Domain Controllers Policy: the built-in GPO that applies to every DC in the domain by default.

• WMI filter: a Group Policy condition that restricts which machines a GPO applies to, based on system attributes.

• Event ID 2889: the Directory Service log event that names the client and account behind each unsigned or cleartext bind.

• Channel binding: the control that ties a login to its exact TLS session; affected by where TLS terminates on the F5.

• LDAPS / StartTLS / Kerberos: the secure paths a legacy client should move to before any exception expires.

#ActiveDirectory #LDAP #WindowsServer2025 #IdentitySecurity #CyberSecurity