Active Directory and LDAP integration security

Why this area matters

Active Directory is often the identity backbone of a company, so the service accounts and queries applications use against it are high-value. LDAP injection (CWE-90) can bypass login checks or expose directory data, and a service-account password committed to a repository (CWE-798) is a direct path into the domain.

Generic scanners see an LDAP call but not whether its filter is escaped or whether the connection is LDAPS. The directory review agent checks the filter construction, the transport and where the bind credentials come from.

What goes wrong in real applications

• LDAP filter injection

  User input placed into an LDAP filter without escaping can change the query's logic, bypassing authentication checks or returning objects the user shouldn't see.

• Cleartext binds

  Binding over ldap:// without StartTLS sends credentials across the network readable by anyone on the path.

• Hard-coded service-account credentials

  Bind passwords in source or config files end up in every clone, fork and backup of the repository, and in its git history even after deletion.

• Over-privileged service accounts

  Applications binding as a domain admin or highly privileged account turn any application bug into a directory-wide compromise.

Sample: the risky pattern and the fix

from ldap3 import Server, Connection

server = Server("ldap://dc01.corp.example")
conn = Connection(server, user="[email protected]",
                  password="••••••••", auto_bind=True)

def find_user(username):
    flt = f"(&(objectClass=user)(sAMAccountName={username}))"
    conn.search("dc=corp,dc=example", flt, attributes=["mail"])
    return conn.entries

import os
from ldap3 import Server, Connection
from ldap3.utils.conv import escape_filter_chars

server = Server("ldaps://dc01.corp.example", use_ssl=True)
conn = Connection(server, user=os.environ["LDAP_BIND_USER"],
                  password=os.environ["LDAP_BIND_PASSWORD"], auto_bind=True)

def find_user(username):
    safe = escape_filter_chars(username)
    flt = f"(&(objectClass=user)(sAMAccountName={safe}))"
    conn.search("dc=corp,dc=example", flt, attributes=["mail"])
    return conn.entries

The original binds over cleartext LDAP with a password committed to the repository, and pastes the username into the filter unescaped, so special characters change the query. The fix uses LDAPS, loads the bind credentials from the environment (backed by a secrets manager), and escapes filter input.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• LDAP filters and DNs built from request input without escaping
• ldap:// connections without StartTLS, and disabled certificate validation
• Bind DNs and passwords in source, config files and git history (Gitleaks plus agent review)
• PowerShell, GPO and provisioning scripts committed to the repo that embed credentials

Scope and limits

• It never connects to domain controllers, enumerates your directory or tests Kerberos — it reviews the code and scripts in your repository that integrate with it.
• Directory permissions and group memberships live in AD itself, so whether a service account is over-privileged can only be judged from how the code uses it.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Directory & LDAP integration — Reviews Active Directory and LDAP code for injection, cleartext binds and hard-coded credentials.
• Secrets & data exposure — Judges whether a flagged value is really a secret and whether sensitive data leaks through logs or errors.
• Authentication & JWT — Checks that identity, tokens and sessions are actually verified and hardened.