How Missing LDAP Signing Enables Active Directory Attack Chains (Real Examples)

LDAP signing is often overlooked and one of those controls that rarely gets attention unless something breaks. It’s usually configured as “negotiate,” which sounds perfectly reasonable.

During internal penetration tests, missing or unenforced LDAP signing is one of the most reliable ways we gain a foothold in Active Directory, kick off an attack chain that leads to domain compromise, or obtain direct domain compromise in minutes without 0-day exploits or fancy attacks.

This post focuses on how unsigned LDAP traffic is actually abused in real environments, and why it so often becomes a critical link in broader attack chains.

Negotiated LDAP Signing Leaves the Door Open

LDAP signing can be configured as:

• Supported
• Negotiated
• Not required

From a configuration standpoint, this looks like a compromise between security and compatibility, though the setting is often left unconfigured due to oversight, trusting defaults, or a lack of knowledge about the implications.

When LDAP signing is not required, domain controllers will accept unsigned LDAP connections or authentication attempts. This behavior allows attackers to relay valid authentication to the LDAP service on a domain controller and interact with Active Directory as the relayed user or computer account.

If you’re looking for the mechanics of LDAP signing and how to enforce it correctly, we cover that in detail here: → How to Enforce LDAP Signing in Active Directory (And Why It Matters)

How LDAP Signing Gets Abused in Practice

In real internal networks, LDAP relaying is usually chained with other weaknesses that already exist in the environment.

An example path could look like:

• LDAP signing is not enforced on domain controllers; we can check this quickly using a tool such as NetExec:

$ netexec ldap 192.168.100.1 -u jsmith -p '<REDACTED>'  -M ldap-checker

SMB         192.168.100.1     445    HQDC           [*] Windows 10 / Server 2019 Build 17763 x64 (name:HQDC) (domain:corp.prysm.int) (signing:True) (SMBv1:False)
LDAP        192.168.100.1     389    HQDC           [+]corp.prysm.int \jsmith:<REDACTED>
LDAP-CHE... 192.168.100.1     389    HQDC           LDAP Signing NOT Enforced!
LDAP-CHE... 192.168.100.1     389    HQDC           LDAPS Channel Binding is set to "NEVER"

• An authentication attempt is captured or coerced on the network
• That authentication is relayed to LDAP
• Active Directory accepts the bind as a legitimate user or computer

At that point, the attacker is using LDAP exactly as designed, just not in an intended manner.

Depending on the privileges of the relayed account, this can enable:

• Authenticated domain enumeration
• Creation of new computer objects
• Modification of directory attributes
• Privilege escalation via delegation or Active Directory Certificate Services (AD CS) abuse

None of these attacks requires cracked (clear-text) credentials or sophisticated malware.

Leveraging this for an Attack Chain

The real risk with leaving LDAP signing unenforced is how easily it combines with other common AD misconfigurations. On its own, we typically flag it as a medium-risk finding in reports.

Some examples include:

Machine Account Abuse

If the ms-DS-MachineAccountQuota is not set to zero, authentication relayed to LDAP can be used to create attacker-controlled computer objects in the domain. This not only provides a foothold for further enumeration but can also be used to perform certain attacks directly and as a precursor to other attacks.

Delegation Abuse

Relayed LDAP access is often used to configure Resource-Based Constrained Delegation (RBCD), allowing attackers to impersonate users to target systems.

Certificate Services Escalation

In environments with misconfigured Active Directory Certificate Services, LDAP relay can be used to request or modify certificates in ways that directly lead to elevated privileges and domain compromise.

Privilege Escalation

When privileged accounts authenticate over the network, missing LDAP signing can turn a routine authentication attempt into a path toward Domain Admin.

Individually, each of these issues might be classified as low- or medium-risk, but when chained together, they frequently result in full-domain compromise.

Why It's Easy to Miss

One reason LDAP signing issues persist is that the activity doesn’t appear malicious unless you're explicitly looking for it, which many environments aren't.

From a logging perspective, it typically looks like successful authentication, normal LDAP queries, and changes made by valid identities, or not alerted on. Unless you are explicitly monitoring for unsigned LDAP binds or enforcing signing everywhere, this behavior blends in with everyday directory traffic.

This is also why environments with strong endpoint protection and monitoring still fall victim to these attack chains. The weakness exists at the protocol and configuration level, not in executable code.

How We Handle This During Assessments

During internal penetration tests, missing LDAP signing is always flagged as a security issue.

On its own, it may be categorized as low- or medium-risk. But when it enables a foothold, privilege escalation, or domain compromise, the risk rating escalates quickly.

In many real-world assessments, a significant portion of the attack chain leading to elevated access depends on LDAP signing not being enforced. Once it is required, entire classes of relay-based attacks simply stop working.

A Note on LDAP Channel Binding

Similar to LDAP signing, when LDAPS is in use, then channel binding must be set to fully mitigate the risk of successful relaying attacks. Sometimes we do encounter environments with LDAP signing enforced, but are still able to relay to LDAPS because channel binding was left unset.

Final Thoughts

Missing or unenforced LDAP signing is not an edge case; it’s one of the most consistently exploitable conditions we encounter during internal assessments. Like SMB signing, missing LDAP signing consistently appears on our annual list of the most common internal penetration test findings, affecting environments both big and small and everything in between.

LDAP signing has been available since Windows Server 2003, and as of Windows Server 2025, Microsoft enforces the setting by default on new domain controllers; however, many organizations that we test have not yet moved to Server 2025, so it will take some time for this setting to be widely set by default.

Until then, the issue persists because the default configuration appears reasonable, the "failure" is often quiet, and the impact may go unnoticed.

Our Active Directory Security Hardening & Hygiene Checklist covers the most common issues we see during internal assessments and how to properly address them.

Unsure if LDAP signing is enforced properly in your environment?

Vilkas Cybersecurity helps organizations uncover and fix real-world exposures, not just theoretical ones.

Have a question about this article or a security challenge of your own? Fill out the form and we’ll get back to you shortly.