LDAP (Lightweight Directory Access Protocol) is a protocol for querying and updating directory services — the systems that hold an organization’s user accounts, groups, and org structure. Active Directory, OpenLDAP, and most corporate identity servers speak it.
The directory itself is a hierarchical tree rather than a set of relational tables. Entries are identified by a distinguished name that reads from the specific to the general, like cn=jsmith,ou=Analytics,dc=example,dc=com, and each entry carries attributes: email, display name, department, group memberships.
Authentication and authorization
LDAP does two distinct jobs, and it’s worth keeping them separate in your head.
Authentication happens through a bind operation: an application passes the user’s credentials to the directory, and the directory answers yes or no. The application never stores the password, which is the point. When someone is deactivated in the directory, they lose access everywhere at once rather than in whatever order IT gets around to it.
Authorization comes from group membership. The same directory that says who a person is also says which groups they belong to, so applications can map an LDAP group onto their own permission model — everyone in ou=Finance lands in the finance group, gets the finance collections, and inherits whatever data access that implies.
That group mapping is what makes LDAP worth wiring up for analytics specifically. Access to sensitive tables tracks the org chart automatically, and a transfer or a departure updates permissions without anyone editing a list by hand.
LDAP, SSO, and SAML
LDAP predates the browser-based SSO protocols and works differently. With LDAP the application collects the password and checks it against the directory. With SAML or OIDC, the application redirects to an identity provider, the user authenticates there, and the app receives a signed assertion — it never sees the password at all.
In practice these coexist. Many organizations run LDAP as the underlying directory and a SAML identity provider in front of it for browser logins, with the directory still supplying group membership. If you’re choosing today for a new setup, SAML or OIDC is generally the better fit for anything web-facing; LDAP remains common where an established Active Directory is already the source of truth.
Operational notes
A few things that reliably cause trouble:
- Plain LDAP is unencrypted. Use LDAPS or StartTLS; otherwise credentials cross the network in the clear.
- The service account matters. Applications bind with a dedicated account to look users up. Give it read access to the subtree it needs and nothing more.
- Group sync direction. Decide whether the directory or the application owns group membership. Both owning it produces changes that quietly revert on the next sync.
- Watch the failed login rate. A spike usually means an expired service account or a misconfigured search base, not an attack — but it can be either, which is why the audit log is worth keeping.
Key article
Related terms
Put it to work
- Security analytics — Overview
- Identity and access analytics — Dashboard
- Failed login rate — Metric
