LDAP Signing Not Enforced in Active Directory? How to Fix It (and Why It Leads to Attacks)

Background

Lightweight Directory Access Protocol (LDAP) is the backbone for querying and managing Active Directory (AD) objects. Domain-joined systems, applications, and services use it to authenticate users and access directory data. The protocol is open-source and works for authentication across various platforms. It is essentially how users and hosts communicate with domain controllers in AD to perform authentication requests and query the directory for information, such as information on AD computers, users, and groups.

While LDAP is optimized for retrieving information from a directory service (read activities), it can also be used to make changes in AD, such as adding a user or group or modifying permissions. When LDAP signing is not enabled, an attacker can perform an NTLM relaying attack to replay captured credentials to the LDAP service on a domain controller to query the directory, obtain a foothold, or elevate privileges. One example is abusing the ms-DS-MachineAccountQuota attribute to add a malicious computer object to the domain.

What is LDAP Signing?

LDAP communication is often unencrypted and unsigned by default, even in modern, hardened environments, leaving your domain traffic vulnerable to:

• Man-in-the-Middle (MitM) attacks
• Credential interception
• Credential replay attacks

The example attacks above require additional remediation strategies, but LDAP Signing helps to mitigate the risk by ensuring that:

• Communications between clients and Domain Controllers are digitally signed
• Message integrity is protected
• Preventing unauthorized modification of packets

Why it's Dangerous to Leave LDAP Unsigned

When LDAP is left unsigned in an AD environment, this allows attackers with network access to:

• Intercept credentials during plaintext binds
• Perform authenticated enumeration of the domain via credential replay attacks via tools such as ntlmrelayx.py
• Add an attacker-controlled machine account if the ms-DS-MachineAccountQuota attribute is not set to 0
• Perform attacks such as Kerberos Resource-Based Constrained Delegation (RBCD)
• Replay privileged credentials to escalate privileges from unauthenticated network access to Domain Admin, sometimes by running only two tools/commands

Missing LDAP signing is often a critical factor in attack chains that result in footholds or domain compromise. We outline the most common LDAP signing-related attack chains observed during internal penetration tests here: Common Attack Chains Enabled by Missing LDAP Signing.

A lack of LDAP Signing is widespread during Vilkas' Internal Penetration Tests against our client's environments. More often than not, a significant portion of our attack chain leading to domain compromise was made possible due to LDAP Signing not being enabled or properly enforced. When we find this issue during assessments, we always flag it as at least a low-risk finding. However, when the lack of LDAP Signing facilitates a foothold or domain compromise, it gets elevated to high or critical risk, depending on the circumstances.

How to Check if LDAP Signing is Enforced

Checking if LDAP signing is enforced can be done via Group Policy or PowerShell.

Option 1: Via Group Policy

1. Open the Group Policy Management console
2. Expand the domain, then Domain Controllers OU, right-click on the Default Domain Controllers Policy and select Edit.

3. Navigate to:
   Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Domain Controller: LDAP server signing requirements.
4. Open the setting, select Define this policy setting, and select Require signing from the dropdown.

Once applied, either run a gpupdate via command line or wait for the next Group Policy refresh cycle for the setting to take effect.

Option 2: Via PowerShell

Check the current LDAP Signing requirements on the Domain Controller, based on the following possible configurations:

• 0 - None = No signing required
• 1 - Negotiate signing = Supported but not enforced
• 2 - Require signing = Only signed LDAP communications are allowed

PS C:\> Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' -Name 'LDAPServerIntegrity'

ldapserverintegrity : 1
PSPath              : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
PSParentPath        : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS
PSChildName         : Parameters
PSDrive             : HKLM
PSProvider          : Microsoft.PowerShell.Core\Registry

In the example above, we see the default configuration of 1, meaning that LDAP Signing is supported but not enforced. We can next use a bit of PowerShell to enable the setting.

$regPath = "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters"
$regName = "LDAPServerIntegrity"

New-Item -Path $regPath -Force | Out-Null
Set-ItemProperty -Path $regPath -Name $regName -Value 2

While this can be remediated via the Registry and may be fine in smaller environments with only 1-2 Domain Controllers, remediating via Group Policy is recommended to ensure that the setting is applied across all Domain Controllers and consistently enforced.

Additional Considerations

As with any change in Active Directory, it is critical to thoroughly test the impact of enabling LDAP Signing. If in use, it could break communications with legacy applications and network devices or cause issues with Microsoft Exchange, SCCM, or third-party identity services.

What Could Break?

If you're not sure whether your environment can safely support this setting, you can monitor for Event ID 2889 to check for any clients trying to make unsigned LDAP binds per this guide from Microsoft. If critical systems appear that would not be operable with LDAP Signing enforced, then mitigations can be implemented to prevent attacks that capitalize on a lack of LDAP Signing.

Final Thoughts

Enforcing LDAP Signing is a low-effort, high-impact way to reduce risk in Active Directory environments. It's a common finding during internal penetration tests (in the top 5 for 2025 at the time of writing) and an easy win for defenders once implemented.

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

Want to test your environment for risks like this?

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.