LDAP basics for users

Administrating an LDAP server may be hard — using it doesn't have to be.

LDAP servers commonly provide auth services to web servers, mail servers, web apps, and so on. To do this, the LDAP database stores user and group membership information. The combination of these two datasets allows both authentication (is the user who they claim to be?) and authorization (is the user in a group that has permission to perform a specific action?). Thus, LDAP enables central management of user, group, and permission information for any number of services.

Concepts

So what does an LDAP database consist of?

  • An LDAP database contains a hierarchical data structure, similar to a directory tree.
  • Each tree node is called an entity.
    • LDAP doesn't distinguish between files and directories. Entities often contain both child entities — like a directory — as well as attributes, which are similar to a file's content.
  • Each entity has a distinguished name (DN), which is the entity's absolute pathname in LDAP tree. The elements of the pathname are called relative distinguished names (RDNs).
    These concepts are pretty similar to filesystem directory trees. The key differences are:
    • Directory separators: LDAP uses , instead of /
    • RDN format: RDNs are typically key-value-pairs, instead of simple strings: uid=ca instead of Desktop. Commonly used keys are dc, o, ou, uid.
    • Parent nodes are on the right: so it's dc=child,dc=parent instead of /parent/child
      Consequently, DNs usually look like this: uid=ca,ou=people,dc=caichinger,dc=com
  • Entities have attributes, which store the entity's data, similar to a file's contents. Each attribute has a type that describes the attribute's data structure, as well as one or more values containing the attribute's information. Additionally, each attribute can have options — a rarely used feature for distinguishing different versions (e.g. English, German) of the same attribute.
  • Entities also have associated object classes, which are conceptually similar to attribute types. But whereas types describe attributes, object classes describe which attributes must be found within the entity.
  • Both attribute types and entity object classes are metadata: they describe the database's schema. Each of these metadata objects has an OID. Aside from the schema definition, OIDs are also used for other database-specific metadata, such as identifying extended requests and responses. OIDs are denoted as dot-separated numbers, e.g. 1.2.840.1234567890, but often have human-readable names assigned as well.

What actions can be performed over the LDAP protocol?

  • Binding: authenticating to the LDAP server — essentially "logging in". Since most servers don't allow un-authenticated querying, this is required before performing any other actions. Many servers also support re-authentication as a different user over existing connections: this is known as re-binding.
  • Searching: querying the existing LDAP directory tree, and listing its information.
  • Add, modify, and delete: altering the LDAP directory tree.
  • Many others, often including custom commands.

Querying

Querying an LDAP server is straight-forward with the ldapsearch tool:

ldapsearch
  -h ldap.caichinger.com                       # LDAP server name
  -D "uid=ca,ou=people,dc=caichinger,dc=com"   # Authenticate as uid=caichinger
  -W                                           # Ask for password for uid=caichinger
  -b "ou=people,dc=caichinger,dc=com"          # Base search path
  (uid=caichinger)                             # Search expression

The -D and -W switches tell ldapsearch as which user to authenticate as. The -b switch defines the "base directory" where the search should start. The search expression is then applied to all entities under this directory tree.

The server response will then contain all matching users, as well as their associated attributes.

If you have any questions after this whirlwind-tour of LDAP, please leave a comment!