Configuring an OpenLDAP server (210.4)

Candidates should be able to configure a basic OpenLDAP server including knowledge of LDIF format and essential access controls. An understanding of the role of SSSD in authentication and identity management is included.

Key Knowledge Areas


Access Control

Distinguished Names

Changetype Operations

Schemas and Whitepages


Object IDs, Attributes and Classes

Awareness of System Security Services Daemon (SSSD)

Terms and Utilities

  • slapd

  • slapd.conf

  • LDIF

  • slapadd

  • slapcat

  • slapindex

  • /var/lib/ldap/*

  • loglevel

Resources: the man pages for the various commands.


OpenLDAP uses slapd which is the stand-alone LDAP daemon. It listens for LDAP connections on any number of ports (default 389), responding to the LDAP operations it receives over these connections. OpenLDAP is typically started at boot time.

It can be installed either from source obtaining it from OpenLDAP software but most linux distributions deliver it through their packagemanagement system like yum or apt.

In Openldap, directory entries are arranged in a hierarchical tree-like structure. Traditionally, this structure reflected the geographic and/or organizational boundaries. Entries representing countries appear at the top of the tree. Below them are entries representing states and national organizations. Below them might be entries representing organizational units, people, printers, documents, or just about anything else.

Access Control

While the OpenLDAP directory gets filled the data becomes more critical. Some data might be protected by law or be confidential in an other way. Therefore access to the directory needs to be controlled. The default policy allows read access to all clients. Access to slapd entries and attributes is controlled by the olcAccess attribute, whose values are a sequence of access directives.

Distinguished Names

A distinguished name (DN) is the name (set of attributes) which uniquely identifies an entry in the OpenLDAP directory and corresponds to the path which has to be traversed to reach that entry. A DN contains an attribute and value pair separated by commas.

For example:

	cn=John Doe,ou=editing,o=Paris,c=F
	cn=Jane Doe,ou=editing,o=London,c=UK
	cn=Tom Jones,ou=reporting,o=Amsterdam,c=NL

Any of the attributes defined in the directory schema may be used to make up a DN. The order of the component attribute value pairs is important. The DN contains one component for each level of the directory hierarchy from the root down to the level where the entry resides. LDAP DNs begin with the most specific attribute and continue with progressively broader attributes. The first component of the DN is referred to as the Relative Distinguished Name (RDN). It identifies an entry distinctly from any other entries that have the same parent.

An example to create an entry for a person:

	dn: cn=John Doe,o=bmi,c=us
	objectclass: top
	objectclass: person 
	cn: John Doe 
	sn: Doe
	telephonenumber: 555-111-5555

Some characters have special meaning in a DN. For example, = (equals) separates an attribute name and value and comma separates attribute=value pairs. The special characters are: comma, equals, plus,less than, greater than, number sign, semicolon, backslash, quotation mark.

A special character can be escaped in an attribute value to remove the special meaning. To escape these special characters or other characters in an attribute value in a DN string, use the following methods:

If a character to be escaped is one of the special characters, precede it by a backslash (\ ASCII 92). This example shows a method of escaping a comma in an organization name:

	CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB


This file contains the configuration for OpenLDAP's slapd daemon. Depending on the linux distribution used it can be located in /etc/openldap or /usr/local/etc/openldap. For general needs, the slapd.conf file used by OpenLDAP can be broken into two sections. The first section contains parameters that affect the overall behavior of the OpenLDAP server (for example, the level of information sent to log files). The second section is composed of parameters that relate to a particular database back end used by the slapd daemon. It is possible to define some default settings for these in the global section of slapd.conf. However, any value specified in the database section will override default settings. After installing OpenLDAP the slapd.conf file needs minimal configuration to start. For example if we use the domain the configuration file might look like:

	database bdb 
	suffix "dc=example,dc=com" 
	rootdn "cn=Manager,dc=example,dc=com" 
	rootpw secret 
	directory /var/lib/openldap

It is more secure if the user uses slappasswd to generate a password hash instead of the plain text password secret as in the example above. Then the rootpw line is changed into something like:

	rootpw {SSHA}R6zJBEcX1ltYDwbWkqYZ8GrrUFQZbKyN


All modifications to the OpenLDAP database are formatted in the LDIF format. LDIF stands for LDAP Data Interchange Format. It is used by the OpenLDAP's tools like slapadd to add entries. An example of a LDIF file:

	cat adduser.ldif

	# John Doe's Entry
	dn: cn=John Doe,dc=example,dc=com
	cn: John Doe
	cn: Johnnie Doe
	objectClass: person
	sn: Doe

NB: Multiple entries are separated using a blank line. Using slapcat you can export information from the LDAP database into the LDIF format.

For example:

	slapcat -l all.ldif

This will generate a file called all.ldif which contain a full dump of the LDAP database. The generated output can be used for slapadd.

For example:

	slapadd -l all.ldif

Sometimes, after altering the slapd.conf configurationfile, it can be necessary to regenerate LDAP's database indexes. This can be done using the slapindex tool. Also slapindex can be used to regenerate the index for a specific attribute, in this example the UID:

	slapindex uid  


A directory can be contrived of as an hierarchically organized collection of data. The best known example probably is the telephone directory, but the file system directory is another one. Generally speaking a directory is a database that is optimized for reading, browsing and searching. OpenLDAP directories contain descriptive, attribute-based information. They do not support the roll-back mechanisms or complicated transactions that are found in Relational Data Base Management Systems (RDBMS's). Updates are typically simple all-or-nothing changes, if allowed at all. This type of directories are designed to give quick responses to high-volume lookup or search operations. OpenLDAP directories can be replicated to increase availability and reliability. Replicated databases can be temporarily out-of-sync but will be synchronized eventually.

Schemas and Whitepages

Schemas are the standard way of describing the structure of objects that may be stored inside a directory. A whitepages schema is a data model for organizing the data contained in entries in a directory service such as an address book or LDAP. In a whitepages directory, each entry typically represents an individual that makes use of network resources, such as by receiving email of having an account to log in to a system. LDAP schemas are used to formally define attributes, object classes, and various rules for structuring the directory information tree. Usually schemas are configured in slapd.conf using the include directive. For example:

	include   /etc/openldap/schema/core.schema
	include   /etc/openldap/schema/cosine.schema
	include   /etc/openldap/schema/inetorgperson.schema

The first line imports the core schema, which contains the schemas of attributes and object classes necessary for standard LDAP use. The cosine.schema imports a number of commonly used object classes and attributes, including those used for storing document information and DNS records. The third provides the inetOrgPerson object class definition and its associated attribute definitions. Other schemas are available with OpenLDAP (in /etc/openldap/schema); refer to the OpenLDAP Software 2.4 Administrator's guide for more information.


SSSD is the System Security Services Daemon. Its primary function is to provide access to identity and authentication remote resources - like OpenLDAP - through a common framework that can provide caching and offline support to the system. SSSD provides Name Service Switch (NSS) and Pluggable Authentication Modules (PAM) services. With it is possible to use multiple different account sources for instance in order to combine OpenLDAP with Kerberos.


Copyright Snow B.V. The Netherlands