1.4Configuring an OpenLDAP Server

What the client commands from the previous section actually talk to is OpenLDAP (daemon name slapd), the most widely used LDAP server implementation on Linux. Separately from client-side operations, Exam 202 tests server-side administration (backup, import, access control, dynamic configuration) at weight 2, building on the directory's data model (DN, LDIF, objectClass).

1.4.1The directory data model

• An LDAP directory is a tree structure (the DIT, Directory Information Tree). The string that uniquely locates an entry is its DN (Distinguished Name, e.g. uid=suzuki,ou=people,dc=example,dc=com). A classic use case is a white pages (an internal corporate directory).
• The text exchange format for entries is LDIF (LDAP Data Interchange Format), used as input to ldapadd, ldapmodify, and slapadd.
• Which attributes an entry may have is determined by its objectClass (e.g., an entry with inetOrgPerson can have attributes like cn, sn, mail). objectClasses and attributes are identified in the LDAP schema by an object identifier (OID).

1.4.2slapd operational tools and access control

• The daemon itself is slapd. Database files are stored by default under /var/lib/ldap/ (the exact path can vary by distribution).
• Backup: slapcat (dumps the database contents as LDIF). Restore/initial import: slapadd (loads LDIF directly into the database—an offline tool used while slapd is stopped). Reindexing: slapindex (rebuilds indexes for search performance).
• The recommended configuration approach since OpenLDAP 2.x is slapd-config (configuration lives inside LDAP itself as the cn=config tree, so changes apply dynamically without stopping the server). It replaces the older, single-file slapd.conf approach.
• Access control (who can read/write which attributes) is defined via slapd.access (the olcAccess attribute / access to clauses). Read/write permission can be scoped tightly, down to a DN subtree or individual attribute.

Walk through routine operations end to end. For regular backups, run slapcat -n 1 -l backup.ldif (dumping the target database to LDIF) via cron while slapd stays running. Conversely, when migrating to another server or restoring from disaster—loading data into a blank instance—you must stop slapd first, then run slapadd -l backup.ldif (this preserves consistency, since it writes directly into a database file rather than going through a live server). After loading, rebuild indexes with slapindex for search performance. Configuration changes (e.g., adding a new schema, revising access control via slapd.access) used to require a service restart when editing the legacy slapd.conf file directly; with slapd-config (the cn=config tree), you instead rewrite config entries in place with ldapmodify, taking effect without stopping the service. For access control, something like "regular users may write only their own password attribute; everything else is read-only" is expressed in slapd.access as access to attrs=userPassword by self write by * read. Underlying all of this is a three-part data model: each entry in the DIT has a unique DN; its objectClass (e.g. inetOrgPerson) determines the set of usable attributes; and LDIF is the text format used to exchange them.

1.4.3Section summary

• Backup = slapcat (DB → LDIF) / restore = slapadd (LDIF → DB, while slapd is stopped) / reindex = slapindex
• Dynamic config = slapd-config (cn=config); access control = slapd.access; the data model is DN / LDIF / objectClass + attributes