What is LDAP?

Definition

LDAP (Lightweight Directory Access Protocol) is the standard protocol for querying and modifying directory services. In Active Directory, LDAP is how applications, scripts, and tools read and write directory data — users, groups, computers, attributes, and ACLs.

LDAP runs on:

• TCP/UDP 389 — plaintext / StartTLS.
• TCP 636 — LDAPS (LDAP over SSL/TLS).
• TCP 3268 / 3269 — Global Catalog (LDAP / LDAPS).

In simple terms:

LDAP is how everything talks to your directory — including attackers doing reconnaissance.

---

Why LDAP Matters

• Almost every AD-integrated application uses LDAP.
• Default AD permissions allow any authenticated user to read most directory data.
• Weakly secured LDAP enables relay attacks that escalate to AD compromise.
• Reconnaissance via LDAP is the first step in nearly every AD attack.

---

How LDAP Works

Operations

• Bind — authenticate.
• Search — query objects.
• Add / Modify / Delete — change objects (with proper rights).
• Modify DN — rename / move objects.
• Compare — compare attribute values.
• Unbind — close the session.

Bind Methods

• Anonymous — usually disabled in AD.
• Simple — username + password (in plaintext over LDAP unless LDAPS or StartTLS).
• SASL — supports Kerberos, NTLM, and other mechanisms.

Search Filters

LDAP filters (e.g., (&(objectClass=user)(memberOf=CN=Domain Admins,...))) allow flexible queries against the directory.

---

What Attackers Do With LDAP

1. Reconnaissance

• Enumerate users, groups, computers, OUs.
• Find privileged groups (Domain Admins, Enterprise Admins).
• Identify Kerberoastable accounts (SPN-enabled).
• Identify AS-REP roastable accounts (preauth disabled).
• Read ACLs for shadow admin discovery.
• Map trusts and AD CS templates.

Tools: BloodHound, ADExplorer, ldapsearch, PowerShell ActiveDirectory module.

2. LDAP Relay

If LDAP signing or channel binding is not enforced, attackers can relay captured authentication to the DC's LDAP service to:

• Add themselves to privileged groups.
• Modify object attributes (e.g., enable RBCD via msDS-AllowedToActOnBehalfOfOtherIdentity).
• Make changes that lead to Tier 0.

3. Credential Harvesting

Plaintext LDAP simple binds expose passwords on the wire if not encrypted.

4. Anonymous / Authenticated User Reads

Default permissions expose extensive directory data even to low-privilege accounts.

---

Real-World Examples

1. BloodHound Recon

An attacker with any domain user account uses SharpHound (BloodHound's collector) to query LDAP and build a complete attack graph in minutes.

2. NTLM Relay → LDAP

An attacker captures NTLM authentication via LLMNR poisoning and relays it to LDAP without signing. They use the relayed session to add their account to Domain Admins.

3. Plaintext Bind in Legacy App

A legacy application uses LDAP simple bind with a service account. Sniffing the network reveals the service account password.

4. Shadow Admin Discovery

An attacker reads ACLs across AD via LDAP and discovers a help desk group has Reset Password on a Tier 0 OU — a path to Domain Admin.

---

LDAP Hardening Best Practices

1. Enforce LDAP signing. Set Domain controller: LDAP server signing requirements to Require signing.
2. Enforce LDAP channel binding for LDAPS.
3. Disable LDAP simple binds over plaintext LDAP. Require LDAPS or StartTLS.
4. Disable anonymous LDAP binds.
5. Use LDAPS / StartTLS for all LDAP traffic.
6. Restrict who can read sensitive attributes (e.g., LAPS password attributes — use Confidential Attributes).
7. Restrict who can read ACLs at scale where feasible.
8. Audit LDAP queries for reconnaissance patterns.
9. Use service accounts (gMSA) for LDAP-bound applications.
10. Apply Network segmentation so LDAP is not exposed beyond required hosts.
11. Patch known LDAP CVEs promptly.
12. Detect mass LDAP queries indicative of recon (BloodHound-style activity).

---

LDAP Security Checklist

• LDAP signing required on DCs?
• LDAP channel binding enforced?
• Plaintext simple binds disabled?
• Anonymous binds disabled?
• All app LDAP traffic over LDAPS / StartTLS?
• Sensitive attributes properly protected?
• LAPS attributes protected by Confidential Attributes?
• gMSA used for application LDAP binds?
• SIEM detections for LDAP reconnaissance patterns?
• Network segmentation limiting LDAP exposure?

---

How Forestall Helps

Forestall analyzes LDAP-readable data the way an attacker would, surfacing:

• Excessive read permissions on sensitive attributes.
• Shadow admin ACLs visible to authenticated users.
• Kerberoastable / AS-REP roastable accounts discoverable via LDAP.
• DC configurations missing signing / channel binding.
• Attack paths discoverable through default LDAP visibility.

---

Frequently Asked Questions

Is LDAPS the same as LDAP over StartTLS?

Both encrypt LDAP. LDAPS uses port 636 with TLS from the start; StartTLS upgrades a 389 connection to TLS. Operationally equivalent for security purposes.

Why are LDAP signing and channel binding important?

They prevent NTLM relay attacks against LDAP, which are a common path to Domain Admin.

Can I block all anonymous LDAP?

In AD, most anonymous reads are already disabled by default. Verify and enforce.

What's the most common LDAP-related attack?

LDAP-driven reconnaissance (BloodHound) followed by NTLM relay to LDAP without signing.

Will enforcing LDAP signing break anything?

It can break legacy applications using simple binds. Inventory first, then enforce in stages with monitoring.

---

Conclusion

LDAP is essential for directory operations and unavoidable in any AD environment — which makes it both ubiquitous and attractive to attackers. Enforcing signing and channel binding, requiring encrypted binds, restricting sensitive attribute reads, monitoring for recon patterns, and patching promptly turn LDAP from an attacker's roadmap into a hardened service. Treat LDAP as a Tier 0 surface, because in practice that's exactly what it is.