OpenLDAP Server

The Lightweight Directory Access Protocol, or LDAP, is a protocol for querying and modifying a X.500-based directory service running over TCP/IP. The current LDAP version is LDAPv3, as defined in RFC4510, and the implementation used in Ubuntu is OpenLDAP."

The LDAP protocol accesses directories. A common mistake is to call a directory an LDAP directory, or LDAP database, but it’s really so common, and we all know what we are talking about, that it’s ok. Here are some key concepts and terms:

  • A directory is a tree of data entries that is hierarchical in nature and is called the Directory Information Tree (DIT).

  • An entry consists of a set of attributes.

  • An attribute has a key (a name/description) and one or more values.

  • Every attribute must be defined in at least one objectClass.

  • Attributes and objectclasses are defined in schemas (an objectclass is actually considered as a special kind of attribute).

  • Each entry has a unique identifier: its Distinguished Name (DN or dn). This, in turn, consists of a Relative Distinguished Name (RDN) followed by the parent entry’s DN.

  • The entry’s DN is not an attribute. It is not considered part of the entry itself.


The terms object, container, and node have certain connotations but they all essentially mean the same thing as entry, the technically correct term.

For example, below we have a single entry consisting of 11 attributes where the following is true:

  • DN is “cn=John Doe,dc=example,dc=com”

  • RDN is “cn=John Doe”

  • parent DN is “dc=example,dc=com”

 dn: cn=John Doe,dc=example,dc=com
 cn: John Doe
 givenName: John
 sn: Doe
 telephoneNumber: +1 888 555 6789
 telephoneNumber: +1 888 555 1232
 manager: cn=Larry Smith,dc=example,dc=com
 objectClass: inetOrgPerson
 objectClass: organizationalPerson
 objectClass: person
 objectClass: top

The above entry is in LDIF format (LDAP Data Interchange Format). Any information that you feed into your DIT must also be in such a format. It is defined in RFC2849.

Such a directory accessed via LDAP is good for anything that involves a large number of access requests to a mostly-read, attribute-based (name:value) backend, and that can benefit from a hierarchical structure. Examples include an address book, company directory, a list of email addresses, and a mail server’s configuration.


The installation of slapd will create a minimal working configuration with a top level entry, and an administrator's DN. In particular, it will create a database instance that you can use to store your data. However, the suffix (or base DN) of this instance will be determined from the domain name of the host. If you want something different, you can change it right after the installation when you still don't have any useful data.


This guide will use a database suffix of dc=example,dc=com.

Proceed with the install of the server and the main command line utilities:

sudo apt install slapd ldap-utils

If you want to change your DIT suffix, now would be a good time, because changing it discards your existing one. To change the suffix, run the following command:

sudo dpkg-reconfigure slapd

To switch your DIT suffix to dc=example,dc=com, for example, so you can follow this guide more closely, answer when asked about the DNS domain name.

Throughout this guide we will issue many commands with the LDAP utilities. To save some typing, we can configure the OpenLDAP libraries with certain defaults in /etc/ldap/ldap.conf:

BASE dc=example,dc=com
URI ldap://
TLS_CACERT /etc/ssl/certs/ca-certificates.crt


Adjust for your server name and directory suffix

Post-install Inspection

The packaging of slapd is designed to be configured within the service itself by dedicating a separate DIT for that purpose. This allows one to dynamically configure slapd without the need to restart the service or edit config files. This configuration database consists of a collection of text-based LDIF files located under /etc/ldap/slapd.d, but these should never be edited directly. This way of working is known by several names: the slapd-config method, the RTC method (Real Time Configuration), or the cn=config method. You can still use the traditional flat-file method (slapd.conf) but it’s not going to be covered in this guide.

Right after installation, you will get two databases, or suffixes: one for your data, based on your host’s domain (dc=example,dc=com), and one for your configuration, with its root at cn=config. To change the data on each we need different credentials and access methods:

  • dc=example,dc=com: the administrative user for this suffix is cn=admin,dc=example,dc=com and its password is the one selected during the installation of the slapd package

  • cn=config: the configuration slapd itself is stored under this suffix. Changes to it can be made by the special DN gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth. This is how the local system’s root user (uid=0/gid=0) is seen by the directory when using SASL EXTERNAL authentication through the ldapi:/// transport via the /run/slapd/ldapi unix socket. Essentially what this means is that only the local root user can update the cn=config database. More details later.

  • This is what the slapd-config DIT looks like via the LDAP protocol (listing only the dns):

    $ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn
    dn: cn=config
    dn: cn=module{0},cn=config
    dn: cn=schema,cn=config
    dn: cn={0}core,cn=schema,cn=config
    dn: cn={1}cosine,cn=schema,cn=config
    dn: cn={2}nis,cn=schema,cn=config
    dn: cn={3}inetorgperson,cn=schema,cn=config
    dn: olcDatabase={-1}frontend,cn=config
    dn: olcDatabase={0}config,cn=config
    dn: olcDatabase={1}mdb,cn=config

    Explanation of entries:

    • cn=config: global settings

    • cn=module{0},cn=config: a dynamically loaded module

    • cn=schema,cn=config: contains hard-coded system-level schema

    • cn={0}core,cn=schema,cn=config: the hard-coded core schema

    • cn={1}cosine,cn=schema,cn=config: the cosine schema

    • cn={2}nis,cn=schema,cn=config: the nis schema

    • cn={3}inetorgperson,cn=schema,cn=config: the inetorgperson schema

    • olcDatabase={-1}frontend,cn=config: frontend database, default settings for other databases

    • olcDatabase={0}config,cn=config: slapd configuration database (cn=config)

    • olcDatabase={1}mdb,cn=config: your database instance (dc=example,dc=com)

  • This is what the dc=example,dc=com DIT looks like:

    $ ldapsearch -x -LLL -H ldap:/// -b dc=example,dc=com dn
    dn: dc=example,dc=com
    dn: cn=admin,dc=example,dc=com

    Explanation of entries:

    • dc=example,dc=com: base of the DIT

    • cn=admin,dc=example,dc=com: administrator (rootDN) for this DIT (set up during package install)

Notice how we used two different authentication mechanisms:

  • -x: this is called a simple bind, and is essentially a plain text authentication. Since no binddn was provided (via -D), this became an anonymous bind. Without -x, the default is to use a SASL bind.
  • -Y EXTERNAL: this is using a SASL bind (no -x was provided), and further specifying the EXTERNAL type. Together with -H ldapi:///, this uses a local unix socket connection

In both cases we only got the results that the server ACLs allowed us to see, based on who we are. A very handy tool to verify the authentication is ldapwhoami:

$ ldapwhoami -x

$ ldapwhoami -x -D cn=admin,dc=example,dc=com -W
Enter LDAP Password:

When you use simple bind (-x) and specify a binddn with -D as your authentication dn, the server will look for a userPassword attribute in that entry, and use that to verify the credentials. In this particular case above, we used the database rootDN entry, i.e., the actual administrator, and that is a special case whose password is set in the configuration when the package is installed.


A simple bind without some sort of transport security mechanism is clear text, meaning the credentials are transmitted in the clear. You should add TLS support to your OpenLDAP server as soon as possible.

Here are the SASL EXTERNAL examples:

$ ldapwhoami -Y EXTERNAL -H ldapi:/// -Q

$ sudo ldapwhoami -Y EXTERNAL -H ldapi:/// -Q

When using SASL EXTERNAL via the ldapi:/// transport, the binddn becomes a combination of the uid and gid of the connecting user, followed by the suffix cn=peercred,cn=external,cn=auth. The server ACLs know about this, and grant the local root user complete write access to cn=config via the SASL mechanism.

Modifying/Populating your Database

Let’s introduce some content to our database. We will add the following:

  • a node called People (to store users)

  • a node called Groups (to store groups)

  • a group called miners

  • a user called john

Create the following LDIF file and call it add_content.ldif:

dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People

dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups

dn: cn=miners,ou=Groups,dc=example,dc=com
objectClass: posixGroup
cn: miners
gidNumber: 5000

dn: uid=john,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: john
sn: Doe
givenName: John
cn: John Doe
displayName: John Doe
uidNumber: 10000
gidNumber: 5000
userPassword: {CRYPT}x
gecos: John Doe
loginShell: /bin/bash
homeDirectory: /home/john


It’s important that uid and gid values in your directory do not collide with local values. You can use high number ranges, such as starting at 5000 or even higher.

Add the content:

$ ldapadd -x -D cn=admin,dc=example,dc=com -W -f add_content.ldif
Enter LDAP Password: ********
adding new entry "ou=People,dc=example,dc=com"

adding new entry "ou=Groups,dc=example,dc=com"

adding new entry "cn=miners,ou=Groups,dc=example,dc=com"

adding new entry "uid=john,ou=People,dc=example,dc=com"

We can check that the information has been correctly added with the ldapsearch utility. For example, let’s search for the john entry, and request the cn and gidnumber attributes:

$ ldapsearch -x -LLL -b dc=example,dc=com '(uid=john)' cn gidNumber
dn: uid=john,ou=People,dc=example,dc=com
cn: John Doe
gidNumber: 5000

Here we used an LDAP “filter”: (uid=john). LDAP filters are very flexible and can become complex. For example, to list the group names of which john is a member, we could use the filter:


That is a logical AND between two attributes. Filters are very important in LDAP and mastering their syntax will help a long way. They are used for simple queries like this, but can also select what content is to be replicated to a secondary server, or even in complex ACLs. The full specification is defined in RFC 4515.

Notice we set the userPassword field for the john entry to the cryptic value {CRYPT}x. This essentially is an invalid password, because no hashing will produce just x. It’s a common pattern when adding a user entry without a default password. To change the password to something valid, you can now use ldappasswd:

$ ldappasswd -x -D cn=admin,dc=example,dc=com -W -S uid=john,ou=people,dc=example,dc=com
New password:
Re-enter new password:
Enter LDAP Password:


Remember that simple binds are insecure and you should add TLS support to your server!

Modifying the slapd Configuration Database

The slapd-config DIT can also be queried and modified. Here are some common operations.

Adding an index

Use ldapmodify to add an “Index” to your {1}mdb,cn=config database definition (for dc=example,dc=com). Create a file, call it uid_index.ldif, with the following contents:

dn: olcDatabase={1}mdb,cn=config
add: olcDbIndex
olcDbIndex: mail eq,sub

Then issue the command:

$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f uid_index.ldif
modifying entry "olcDatabase={1}mdb,cn=config"

You can confirm the change in this way:

$ sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \
cn=config '(olcDatabase={1}mdb)' olcDbIndex

dn: olcDatabase={1}mdb,cn=config
olcDbIndex: objectClass eq
olcDbIndex: cn,uid eq
olcDbIndex: uidNumber,gidNumber eq
olcDbIndex: member,memberUid eq
olcDbIndex: mail eq,sub

Change the rootDN password:

First, run slappasswd to get the hash for the new password you want:

$ slappasswd
New password:
Re-enter new password:

Now prepare a changerootpw.ldif file with this content:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW

Finally, run the ldapmodify command:

$ sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f changerootpw.ldif
modifying entry "olcDatabase={1}mdb,cn=config"

We still have the actual cn=admin,dc=example,dc=com dn in the dc=example,dc=com database, so let’s change it too. Since this is a regular entry in this database suffix, we can use ldappasswd:

$ ldappasswd -x -D cn=admin,dc=example,dc=com -W -S
New password:
Re-enter new password:
Enter LDAP Password:  <-- current password, about to be changed

Adding a schema

Schemas can only be added to cn=config if they are in LDIF format. If not, they will first have to be converted. You can find unconverted schemas in addition to converted ones in the /etc/ldap/schema directory.


It is not trivial to remove a schema from the slapd-config database. Practice adding schemas on a test system.

In the following example we’ll add the password policy (ppolicy) schema. This schema exists in both converted (.ldif) and native (.schema) formats, so we don’t have to convert it and can use ldapadd directly:

$ sudo ldapadd -Q -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/ppolicy.ldif
adding new entry "cn=ppolicy,cn=schema,cn=config"

If the schema you want to add does not exist in LDIF format, a nice conversion tool that can be used is provided in the schema2ldif package.


Activity logging for slapd is very useful when implementing an OpenLDAP-based solution yet it must be manually enabled after software installation. Otherwise, only rudimentary messages will appear in the logs. Logging, like any other such configuration, is enabled via the slapd-config database.

OpenLDAP comes with multiple logging levels with each one containing the lower one (additive). A good level to try is stats. The slapd-config man page has more to say on the different subsystems.

Create the file logging.ldif with the following contents:

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats

Implement the change:

sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f logging.ldif

This will produce a significant amount of logging and you will want to throttle back to a less verbose level once your system is in production. While in this verbose mode your host’s syslog engine (rsyslog) may have a hard time keeping up and may drop messages:

rsyslogd-2177: imuxsock lost 228 messages from pid 2547 due to rate-limiting

You may consider a change to rsyslog’s configuration. In /etc/rsyslog.conf, put:

# Disable rate limiting
# (default is 200 messages in 5 seconds; below we make the 5 become 0)
$SystemLogRateLimitInterval 0

And then restart the rsyslog daemon:

sudo systemctl restart syslog.service

Backup and Restore

Now we have ldap running just the way we want, it is time to ensure we can save all of our work and restore it as needed.

What we need is a way to backup the directory database(s), specifically the configuration backend (cn=config) and the DIT (dc=example,dc=com). If we are going to backup those databases into, say, /export/backup, we could use slapcat as shown in the following script, called /usr/local/bin/ldapbackup:


set -e


nice ${SLAPCAT} -b cn=config > ${BACKUP_PATH}/config.ldif
nice ${SLAPCAT} -b dc=example,dc=com > ${BACKUP_PATH}/
chown root:root ${BACKUP_PATH}/*
chmod 600 ${BACKUP_PATH}/*.ldif


These files are uncompressed text files containing everything in your directory including the tree layout, usernames, and every password. So, you might want to consider making /export/backup an encrypted partition and even having the script encrypt those files as it creates them. Ideally you should do both, but that depends on your security requirements.

Then, it is just a matter of having a cron script to run this program as often as you feel comfortable with. For many, once a day suffices. For others, more often is required. Here is an example of a cron script called /etc/cron.d/ldapbackup that is run every night at 22:45h:
45 22 * * *  root    /usr/local/bin/ldapbackup

Now the files are created, they should be copied to a backup server.

Assuming we did a fresh reinstall of ldap, the restore process could be something like this:


set -e


if [ -n "$(ls -l /var/lib/ldap/* 2>/dev/null)" -o -n "$(ls -l /etc/ldap/slapd.d/* 2>/dev/null)" ]; then
    echo Run the following to remove the existing db:
    echo sudo systemctl stop slapd.service
    echo sudo rm -rf /etc/ldap/slapd.d/* /var/lib/ldap/*
    exit 1
sudo systemctl stop slapd.service || :
sudo slapadd -F /etc/ldap/slapd.d -b cn=config -l /export/backup/config.ldif
sudo slapadd -F /etc/ldap/slapd.d -b dc=example,dc=com -l /export/backup/
sudo chown -R openldap:openldap /etc/ldap/slapd.d/
sudo chown -R openldap:openldap /var/lib/ldap/
sudo systemctl start slapd.service

This is a simplistic backup strategy, of course. It’s being shown here as a reference for the basic tooling you can use for backups and restores.


Last updated 1 year, 5 months ago. Help improve this document in the forum.