The directory problem
Find an identity without hard-coding every service.
A directory stores structured information about objects such as people, groups, computers, and service accounts. A client can search the directory using attributes instead of knowing the exact record location in advance.
LDAP is an application protocol. It does not replace DNS, SMTP, Kerberos, or a database in every deployment. It provides a standard way to connect to and query a directory service.
Build the model
Entries form a named directory tree.
Entry
A directory object identified by a distinguished name (DN), such as uid=ada,ou=People,dc=example,dc=com.
Attribute
A named value such as cn, mail, uid, or memberOf. One entry can have several values for an attribute.
Filter
A search condition such as (uid=ada) or (memberOf=cn=Engineering) that selects matching entries.
Bind
An operation that establishes the identity and authorization context used by a client connection.
Follow a search
A service searches before it makes a decision.
An application may bind to the directory, search a base DN with a filter, receive attributes, and then apply its own policy. The directory returns data; the application decides what that data means.
LDAP commonly uses TCP 389, while LDAPS commonly uses TCP 636. LDAP can also be protected with StartTLS on the LDAP connection. Encryption and authentication policy must be evaluated separately.
Mini investigation
Inspect the directory question
Choose the evidence and identify what it tells you.
The filter defines which entries should match; it does not itself prove that the client is authorized to read them.
Knowledge check
Test your LDAP model
Answer six questions.