Configuring an OpenLDAP server (210.4)
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.
Key Knowledge Areas¶
Directory based configuration
Schemas and Whitepages
Object IDs, Attributes and Classes
Terms and Utilities¶
slapd which is the stand-alone LDAP daemon.
It listens for LDAP connections on any number of ports (389 by default),
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.
While the OpenLDAP directory gets filled the protection of data may become more critical. Some data might be protected by law or be confidential in any other way. Therefore access to the directory needs to be controlled. The default policy allows read access to all clients. Regardless of what access control policy is defined, the olcRootDN is always allowed full rights (i.e. auth, search, compare, read, and write) on everything.
slapd entries and attributes is controlled by the
olcAccess attribute, whose values are a sequence of access rules. They
begin with the access directive followed by a list of conditions:
1 2 3
1 2 3 4
This access specification is used to keep a user's password protected. It allows anonymous users an authentication comparison on a password for the purpose of of logging on. Additionally it grants a user permission to change his password. The bottom line denies everyone else any access to the password.
Alternatively we could grant users permission to update all their data with access speficifations like the following:
1 2 3 4 5 6
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.
1 2 3
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:
1 2 3 4 5 6
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:
OpenLDAP 2.3 and later have transitioned to using a dynamic runtime
slapd-config. The older style
is still supported, but its use is deprecated and support for it will be
withdrawn in a future OpenLDAP release.
Although the slapd-config system stores its configuration as
(text-based) LDIF files, you should never edit any of the LDIF files
directly. Configuration changes should be performed via LDAP operations,
Depending on the linux distribution the
slapd.d may be located in
An example might look like this:
1 2 3 4 5 6 7 8 9 10 11 12
slapd.d tree has a very specific structure. The root of the tree
cn=config and contains global configuration settings.
Additional settings are contained in separate child entries.
These may be the following:
Dynamically loaded modules in the
Schema definitations in the
cn=schemadirectory (more about the topic of schema's will follow below)
Backend-specific configuration in the
Database-specific configuration in the
The general layout of the LDIF (for more information on LDIF refer to the section below) that is used to create the configuration tree is as follows:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34
For the domain
example.com the configuration file might look like
1 2 3 4 5 6 7 8
It is more secure to generate a password hash using
of the plain text password secret as in the example above. In that case
olcRootPW line would be changed into something like the following:
olcLogLevel directive specifies at which debugging
level statements and operation statistics should be syslogged. Log
levels may be specified as integers or by keyword. Multiple log levels
may be used and the levels are additive.
Available levels are:
1 2 3 4 5 6 7 8 9 10 11 12 13 14
This will cause lots and lots of debugging information to be logged.
This will only log the connection and search filter processing.
Basic stats logging is configured by default. However, if no olcLogLevel is defined, no logging occurs (equivalent to a 0 level).
Note that the actual OpenLDAP database holding the user data is not
located in the
slapd.d configuration directory tree. Its location may
be changed with the olcDbDirectory directory (see the example above) but
by convention it is usually
Its contents typically looks like this:
1 2 3 4 5 6 7 8 9 10 11
All modifications to the OpenLDAP database are formatted in the LDIF
LDIF format. LDIF stands for LDAP Data Interchange Format. It is used by
OpenLDAP's tools like
slapadd in order to add data to the database.
An example of a LDIF file:
1 2 3 4 5 6 7 8
Multiple entries are separated using a blank line.
can be used to export information from the LDAP database in the LDIF
This will generate a file called
all.ldif which contains a full dump
of the LDAP database.
The generated output can be used by
slapadd to import the
data into an LDAP database.
Sometimes it may be necessary to regenerate LDAP's database indexes.
This can be done using the
slapindex It may also be
used to regenerate the index for a specific attribute like the UID:
slapd should not be running (at least, not in read-write
mode) when the command is run to ensure consistency of the database.
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-config LDIF using the include include
1 2 3
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.