AD Security - LDAP Security and Directory Exposure

Why LDAP is so valuable to attackers

LDAP queries can expose users, groups, computers, service accounts, SPNs, delegation settings and trust relationships. With this information, attackers can map privilege paths, identify high-value targets and plan their next steps with precision rather than trial and error.

In environments where LDAP access is loosely controlled, this activity can be performed quietly and at scale. It blends in with legitimate directory usage and rarely raises suspicion.

The more insight an attacker gains through LDAP, the less noise and risk is required later in the attack chain.

LDAP signing and channel binding

A key LDAP control is signing and channel binding. LDAP signing ensures that LDAP traffic cannot be modified in transit. Channel binding ties authentication to the underlying secure channel, preventing certain types of relay and man-in-the-middle attacks.

Without LDAP signing, an attacker positioned on the network may be able to intercept or manipulate LDAP traffic. A common technique is NTLM relay: an attacker captures authentication attempts from other machines and relays them to a domain controller over an unsigned LDAP connection. Because the domain controller accepts the relayed authentication, the attacker can act on behalf of the captured account without ever knowing its password. Successful exploitation may allow an attacker to create or modify user accounts, alter group memberships or permissions, and ultimately achieve full domain compromise, for example by adding a new Domain Administrator or granting a user DCSync privileges.

From an attacker’s perspective, unsigned LDAP traffic is an opportunity. It opens the door to attacks that do not require compromising endpoints directly, but instead abuse trust in the network.

Microsoft has been clear for years that LDAP signing and channel binding should be enforced, especially on domain controllers. Yet many environments still allow unsigned LDAP binds for compatibility reasons.

Attack scenario

The following sequence illustrates how unsigned LDAP fits into a realistic attack chain, from initial network access to full domain compromise.

Demonstration: from unsigned LDAP to domain compromise

The following screenshots demonstrate a complete NTLM relay attack chain against a domain controller with unsigned LDAP. No credentials are required at any point. The attack moves from intercepting an authentication attempt to full domain compromise in three steps.

Step 1: Intercepting and relaying authentication

ntlmrelayx intercepts an incoming authentication attempt from ESSOS/VAGRANT and relays it over LDAP to the domain controller at 192.168.56.12. ESSOS/VAGRANT is an administrator account on the target, which makes it a valuable relay target. Because LDAP signing is not enforced, the domain controller accepts the relayed authentication. An interactive LDAP shell is opened in the context of the captured account.

Step 2: Creating a Domain Admin via the LDAP shell

Using the interactive LDAP shell, a new user account is created and immediately added to the Domain Admins group. This requires no knowledge of any existing password and takes only seconds. The account Rosalie is now a Domain Administrator.

Step 3: DCSync - dumping all domain hashes

With Domain Admin privileges, a DCSync attack is performed using the newly created account. All NTLM hashes are dumped from the domain controller, including Administrator accounts and others. The domain is fully compromised. The entire attack chain required zero valid credentials at the start.

Enforcing LDAP signing and channel binding

Both LDAP signing and channel binding are enforced through Group Policy on domain controllers.

The relevant settings are located in:

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options

To enforce LDAP signing, configure the policy “Domain controller: LDAP server signing requirements” to Require signing. This ensures that domain controllers only accept LDAP connections that are cryptographically signed by the client.

To enforce channel binding, configure the policy “Domain controller: LDAP server channel binding token requirements” to Always. This last point deserves emphasis: do not leave this setting at When supported. When configured as When supported, clients that do not support channel binding are still allowed to authenticate without it, leaving a window open for abuse. This is the configuration mistake most commonly seen in environments that believe they have enforced channel binding but have not.

Once enforced, LDAP communication becomes more predictable and more resilient against abuse.

Unauthenticated LDAP enumeration

Beyond signing and channel binding, another frequently overlooked LDAP weakness is unauthenticated or anonymous access. In some environments, LDAP allows anonymous binds or exposes directory information without enforcing proper authentication.

This means an attacker does not even need a domain account to start learning about the environment. Basic LDAP queries can already reveal usernames, group names, domain structure and sometimes additional attributes that help guide further attacks.

From an attacker’s perspective, this is extremely valuable. It enables targeted password spraying, focused phishing campaigns and rapid identification of privileged accounts, all before a single credential is compromised.

Even in environments where anonymous access is limited, weak LDAP configurations may still expose more information than intended.

Blocking unauthenticated LDAP enumeration

A further step in reducing LDAP exposure is ensuring that unauthenticated LDAP binds are not allowed. Anonymous LDAP access should be disabled unless there is a very clear and documented business requirement.

Blocking unauthenticated enumeration forces attackers to first obtain valid credentials before they can query directory information. While this does not eliminate all LDAP abuse entirely, it raises the bar and removes a powerful early reconnaissance capability.

This change should be validated carefully, as some legacy applications may rely on anonymous LDAP binds. Where such dependencies exist, they should be explicitly identified, reviewed and treated as exceptions rather than left unexamined.

Why LDAP hardening is often postponed

LDAP hardening is frequently delayed because of fear of breaking applications. LDAP is deeply integrated into many systems, and changes to its behavior are often seen as risky.

As a result, insecure defaults and legacy configurations remain in place long after the systems that required them are gone. Because LDAP abuse usually looks like normal directory activity, the risk stays hidden.

LDAP “just works”, until it is abused.

What needs to change

LDAP should be treated as an active part of the Active Directory attack surface, not as background infrastructure that can be left on default settings. LDAP-related configuration choices have direct security impact and should be made deliberately.

Unauthenticated LDAP access should be blocked wherever possible. LDAP signing and channel binding should be enforced consistently on domain controllers, without falling back to permissive compatibility settings. Any remaining exceptions should be clearly documented, regularly reviewed and kept to an absolute minimum.

Reducing directory exposure does not stop all attacks, but it removes one of the most effective reconnaissance tools attackers rely on in the early stages of compromise.

Closing thoughts

LDAP plays a central role in how Active Directory functions, but it also quietly shapes how attackers approach an environment. When directory access is too permissive or poorly protected, attackers gain both insight and opportunity long before any obvious signs of compromise appear.

Hardening LDAP is not about locking everything down or breaking existing systems. It is about being intentional. Knowing who can query the directory, under which conditions, and with which level of protection. Small configuration choices, such as enforcing signing or blocking anonymous access, have a large impact on how much freedom an attacker has early in the attack chain.

By reducing unnecessary exposure and removing legacy behavior, organizations make LDAP abuse noisier, riskier and far less predictable for attackers. That shift alone can be enough to disrupt common attack paths and buy valuable time for detection and response.

This step builds on the previous phases of the hardening roadmap. With credentials protected, privileged access controlled and Kerberos abuse reduced, securing LDAP closes another gap that attackers routinely exploit to understand and compromise Active Directory environments.