How does LDAP authentication work and how do you secure it?

LDAP authentication verifies a user by sending a bind request to a directory server, such as Active Directory or OpenLDAP, with a name and credential. If the server accepts the bind, the user is authenticated. It must run over TLS, because a simple bind sends the password to the server as is.

What is a bind?

The Lightweight Directory Access Protocol is defined in RFC 4511. A bind operation is how a client identifies itself to the directory. After a successful bind, later requests on that connection, such as searches and updates, are evaluated against that identity.

A common application pattern has two steps. The application binds with a service account, searches for the user's entry by login name, then makes a second bind using that entry's distinguished name and the password the user typed. If the second bind succeeds, the password is right.

Which authentication methods exist?

RFC 4513 describes the authentication methods and security mechanisms. In short there are three.

Anonymous. No credentials. Fine for reading deliberately public data, never for login.

Simple. A name and a password. Without protection, the password crosses the network readable. RFC 4513 addresses this by pointing to transport protection, so simple binds belong inside TLS.

SASL. A framework for pluggable mechanisms, which can avoid sending the password directly. Support depends on the server and the client.

The same RFC warns about a subtle case: a simple bind with a name but an empty password may be treated as an unauthenticated bind. A careless application that checks only whether the bind returned success could accept a login with no password. Always reject empty passwords before sending the request.

What is LDAP injection?

If an application builds a search filter by pasting in user input, a person can supply characters that change the filter. The OWASP cheat sheet explains that LDAP injection results from inadequate input sanitisation and validation. The defences it lists are to escape all variables using the right LDAP encoding function for the context, to prefer frameworks that protect automatically, and to add least privilege, bind authentication and allow list input validation.

Filter escaping and distinguished name escaping differ, so use a library function for the right one instead of writing your own.

What about account lockout and logging?

A directory is a target for password guessing, because every bind is a test of a credential. Directory servers can lock accounts after repeated failures, but lockout can be abused to deny service to real users, so many teams combine modest lockout with rate limits at the application. Log the result of each bind with the source address and the account name, and keep those logs somewhere an attacker with directory access cannot edit.

A constructed example

A web application builds a login filter by inserting the typed username into a template. The application's service account can read the entire directory, including attributes it never uses. A tester enters a username containing filter metacharacters and gets a list of users back.

The repair is layered. Escape the username with the filter escaping routine, validate it against an allowed character set, and reject empty passwords. Then cut the service account down so it can read only the attributes needed to locate a user. Even if one layer fails, the others limit the result.

How to check or apply this

1. Confirm every LDAP connection uses LDAPS or StartTLS, and that clients verify the server certificate.
2. Disable anonymous binds for anything beyond intentionally public data.
3. Reject empty passwords in application code before calling bind.
4. Use a vetted escaping function for filters and for distinguished names.
5. Validate usernames against an allow list of characters and length.
6. Give the search account read access only to what login needs.
7. Rate limit and log failed binds, and alert on bursts.
8. Where possible, move web applications to a modern single sign on protocol and keep LDAP for the directory itself.

Quick check

Sources

• RFC 4511, LDAP: The Protocol
• RFC 4513, LDAP: Authentication Methods and Security Mechanisms
• OWASP, LDAP Injection Prevention Cheat Sheet

Last reviewed: 18 October 2026.