LDAP
Lightweight Directory Access ProtocolLDAP is the read-mostly database an organisation keeps of itself. Users, groups, printers and servers live in a hierarchical tree of entries with attributes, and applications bind to it, search it, and read what they are allowed to — one directory that everything else asks about identity.
LDAP holds the organisation’s directory as a tree — bind to authenticate, search to find, and everything else reads from it.
How it works
Read right to left it is a path down from the base: dc=com → dc=example → ou=Engineering → the entry itself.
A search takes a base DN, a scope and a filter like (&(objectClass=user)(memberOf=cn=admins,…)) — which is how an application asks “is this person in that group?” without holding the answer itself.
What LDAP does, step by step
A simple bind sends a DN and password; SASL binds use Kerberos or a certificate instead.
Give a base DN, a scope — base, one level or subtree — and a filter naming what you want.
Entries come back as attribute/value pairs; ask only for the ones you need.
ADD, MODIFY and DELETE change the tree, subject to the directory’s own access controls.
In cybersecurity
LDAP holds the map of who everyone is, which makes it both a prize for reconnaissance and a place where one injection flaw can bypass a login.
A simple bind sends the password in clear text — use LDAPS on 636 or STARTTLS, always.
Unescaped input in a filter can turn a login check into a query that always matches.
If enabled, anyone can enumerate every user, group and machine in the organisation.
Bind accounts with read-everything rights end up in config files across the estate.
Unsigned LDAP is relayable — the mitigation for a long-standing class of AD attacks.
Group membership and descriptions map an organisation’s privilege structure precisely.