OpenLDAP is an open source implementation of the Lightweight Directory Access Protocol. It includes libraries, clients, and a server. This page is about configuring and running the OpenLDAP Standalone LDAP Daemon slapd on Debian.

Contents

Initial Installation
Tools
Configuration
Schema Files
Database Backends
Permissions
Logging
Database Max Size
Indexes
Samba and OpenLDAP
TLS/SSL
1. Enabling TLS/SSL
2. Configuring TLS/SSL
Backup
Restoration
Replication
Further Reading

Initial Installation

The OpenLDAP server is provided by the slapd package and the tools for interacting with, querying and modifying entries in local or remote LDAP servers are provided by the ldap-utils package, so start by installing these:

# apt install slapd ldap-utils
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following additional packages will be installed:
[...]
Do you want to continue? [Y/n] Y
[...]
Configuring slapd
-----------------

Please enter the password for the admin entry in your LDAP directory.

Administrator password: SECRET

Please enter the admin password for your LDAP directory again to verify that you have typed it correctly.

Confirm password: SECRET
[...]

As can be seen from the above example, you will be prompted to provide a password for the database administrator as part of the installation (or, in case of a noninteractive installation, a random password will be set).

By default, an initial database is created using the system's DNS domain name. If your system is in the domain example.com, the database suffix (BaseDN) will be dc=example,dc=com. The domain name and other low-level details can be changed by running dpkg-reconfigure -plow slapd after installation.

To check the database suffix, once the server is running, use ldapsearch(1) to read the namingContexts attribute of the root DSE:

# ldapsearch -x -LLL -s base -b "" namingContexts
dn:
namingContexts: dc=example,dc=com

Tools

After the above installation, two groups of tools will be available on your system:

OpenLDAP specific

LDAP generic

The OpenLDAP specific tools are low-level, and meant to be executed directly on the systems where slapd has been installed (they can generally be executed while slapd isn't running as they access the underlying database(s) directly), while the generic tools can be used on servers as well as clients.

Configuration

Since version 2.3 (released in 2005), the actual configuration for OpenLDAP servers is managed within a special database (DIT), typically rooted at the cn=config entry. This configuration system is known as OpenLDAP online configuration, or OLC (and further described in slapd-config(5)).

After the initial installation, the config tree will typically look something like this:

# ldapsearch -LLLQ -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

The cn=config root entry contains global settings, cn=module{0},cn=config stores a list of dynamically loaded modules, cn=schema,cn=config contains the built-in system schema definitions with user schema as child entries and the olcDatabase={-1}frontend,cn=config entry contains further global settings (but ones which might affect or be affected by dynamically loadable modules). Finally, the remaining olcDatabase={id}type,cn=config entries contain per-database settings.

While editing a configuration using the various LDAP tools LDIF records may seem a bit unwieldy, such knowledge is anyway necessary for day-to-day interaction with the LDAP directory. Additionally, the advantage of online configuration is that configuration changes can be applied without having to restart the slapd server and, since the configuration is just another database, it is also replicated to other servers.

The old configuration scheme, using a plain slapd.conf(5) file is still supported, but its use is deprecated and support for it will be withdrawn in a future release. There is, however, still a lot of online documentation which refers to the old configuration scheme and which therefore needs to be adapted to the new configuration scheme.

The mapping between the old configuration options and the new style options can often be determined by consulting the slapd-config(5) man page (and, if necessary, by comparing with the slapd.conf(5) man page). It is also possible to introspect a running slapd instance to find the configuration classes/attributes which are actually available on that particular instance.

To do so, first find the name of the (sub)entry holding the controlling (sub)schema for the cn=config DIT:

# ldapsearch -Y EXTERNAL -H ldapi:/// -LLLQ -b "cn=config" -s base subschemaSubentry
dn: cn=config
subschemaSubentry: cn=Subschema

then read out a list of attributes from this entry:

# ldapsearch -x -LLL -b cn=Subschema -s base '(objectClass=subschema)' +

Note: this will generally produce a lot of output, you might want to grep for things like the objectClass definition of the olcGlobal class:

# ldapsearch -x -LLL -b cn=Subschema -s base -o ldif-wrap=no '(objectClass=subschema)' + | \
grep "^objectClasses:" | \
grep "NAME 'olcGlobal'"

Schema Files

One of the consequences of the change from the slapd.conf configuration system to the online configuration system is that the handling of LDAP Schema files is also different.

Traditionally, files ending in .schema, either installed in /etc/ldap/schema or, sometimes, somewhere under /usr/share/doc/<package>/ were included in the legacy slapd.conf file.

Under the new configuration system, files ending in .ldif can be imported into the configuration using ldapadd(1). This copies them into the configuration database and the source files are no longer used afterward.

The slapd package includes .ldif versions of schema files in /etc/ldap/ldif, but many other packages (and online articles on configuring OpenLDAP) only provide .schema files, which need to be converted to .ldif format before they can be used.

One tool for doing so is the schema2ldif utility provided by the schema2ldif package:

# apt install schema2ldif
[...]
# schema2ldif < /usr/share/doc/<package>/<xyz>.schema > /tmp/<xyz>.ldif
# ldapadd -Q -Y EXTERNAL -H ldapi:/// -f /tmp/<xyz>.ldif 
adding new entry "cn=<xyz>,cn=schema,cn=config"

Database Backends

OpenLDAP supports a number of different database backends, the default one being MDB and the alternatives slated for removal. Unless you have specific needs, like running a legacy installation, you should stick with the default.

It is, however, worth pointing out that the backend type is reflected in the configuration tree (see, for example, the olcDatabase={1}mdb,cn=config entry in the previous section), meaning that you might have to adapt configuration examples provided in various guides found on the Internet if they are based on other backends.

Permissions

Administrator Access

In Buster and earlier releases, an administrator entry is created under the BaseDN (e.g. cn=admin,dc=example,dc=com) as part of the initial database creation:

# ldapsearch -LLLQ -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.com
dc: example

dn: cn=admin,dc=example,dc=com
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator

While no such entry is present after installing slapd in later releases:

# ldapsearch -LLLQ -Y EXTERNAL -H ldapi:/// -b dc=example,dc=com
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
o: example.com
dc: example

The administrator is also defined separately in the OpenLDAP configuration, on a per-datbase basis, via the olcRootDN and olcRootPW attributes:

# ldapsearch -LLLQ -Y EXTERNAL -H ldapi:/// -b "olcDatabase={1}mdb,cn=config" olcRootDN OlcRootPW
dn: olcDatabase={1}mdb,cn=config
olcRootDN: cn=admin,dc=example,dc=com
olcRootPW: {SSHA}37s466RsEERQnkgsaj5IL6MfW8JwRhdq

Note that the olcRootDN does not have to refer to an actual entry in the database. Also, the user defined in olcRootDN is not subject to any access control list, ACL, checks or other checks, such as password policies defined by using the ppolicy overlay, which may be a positive or a negative, depending on your preferences.

This duplicate administrator definition can be addressed either by deleting the cn=admin,dc=example,dc=com entry (which would match the behavior of later Debian packages):

# ldapdelete -x -D "cn=admin,dc=example,dc=com" -W -H ldapi:/// cn=admin,dc=example,dc=com
Enter LDAP Password:

or by deleting the olcRootDN and olcRootPW attributes (in which case appropriate ACLs are necessary to give cn=admin,dc=example,dc=com sufficient rights):

# ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcRootPW
-
delete: olcRootDN

dn: olcDatabase={0}config,cn=config
changetype: modify
delete: olcRootDN
EOF
modifying entry "olcDatabase={1}mdb,cn=config"

modifying entry "olcDatabase={0}config,cn=config"

Access Control Lists

The current access control lists are stored as per-database olcAccess attributes in the cn=config database:

# ldapsearch -LLLQ -Y EXTERNAL -H ldapi:/// -b cn=config -s one olcAccess
dn: cn=module{0},cn=config

dn: cn=schema,cn=config

dn: olcBackend={0}mdb,cn=config

dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read

dn: olcDatabase={0}config,cn=config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break

dn: olcDatabase={1}mdb,cn=config
olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none
olcAccess: {1}to attrs=shadowLastChange by self write by * read
olcAccess: {2}to * by * read

The dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth entry is a rather prolix way of defining the system root user (uid and gid 0), connecting via SASL EXTERNAL authentication.

All in all, Debian's default access rules (shown above) allow only the system root user to change the configuration, by connecting with SASL EXTERNAL authentication (which is only possible over the ldapi:/// connection):

# ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config"

In addition, the default access rules allow anyone to search the directory without any authentication:

# ldapsearch -x -b "dc=example,dc=com"

Finally, the database administrator has unrestricted access (via the olcRootDN and OlcRootPW attributes discussed above). To connect as the database administrator, use simple authentication, and when prompted, enter the password configured during installation:

# ldapsearch -x -D "cn=admin,dc=example,dc=com" -W -b "dc=example,dc=com"

Access Control Example 1 - chsh and chfn

Here's an example of how to change the default ACLs so that 'chsh' and 'chfn' can work with LDAP by giving users write access to their own (and administrator access to everyone's) loginShell and gecos attributes:

# ldapmodify -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcAccess
olcAccess: {1}to attrs=loginShell,gecos
  by dn="cn=admin,dc=example,dc=com" write
  by self write
  by * read
EOF

Access Control Example 2 - Multiple LDAP Admins

If you choose to use LDAP for many functions, such as having a single server for DNS, Authentication, and networking flat file database replacement, you may wish to have LDAP administrative users for each subtree in addition to the global admin (dn="cn=admin, dc=example, dc=com). The following example is useful when using a separate authentication tree which includes Samba.

 # The manager dn has full write access to the auth subtree
 # Everyone else has read access to not otherwise protected fields and entries
 access to dn.sub="ou=auth,dc=example,dc=com"
         by dn="cn=Manager,ou=auth,dc=example,dc=com" write
         by * read

Logging

The server logs are sent to the system log (syslog and/or the journal). The default log level is none.

To enable basic request logging, change the log level to stats:

# ldapmodify -Q -H ldapi:/// -Y EXTERNAL <<EOF
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats
EOF
modifying entry "cn=config"

If you wish to disable request logging later, repeat the procedure and set the log level to none.

For more information, read about olcLogLevel in the slapd-config(5) man page.

Database Max Size

The default database uses the LMDB storage backend. This backend requires little configuration or tuning, but there is one important parameter: the max size.

The database is stored in a sparse file, /var/lib/ldap/data.mdb. It has a fixed maximum size, specified by the olcDbMaxSize parameter. The default database has its max size configured to 1 GiB upon installation. When the database reaches its max size, writes (even updates to existing entries) will fail.

Use du(1) to check the actual space used by the database:

du -h /var/lib/ldap/data.mdb

To check the current max size of database #1:

ldapsearch -H ldapi:/// -Y EXTERNAL -b "olcDatabase={1}mdb,cn=config" olcDbMaxSize

To set the max size of database #1 to 10 GiB (10737418240 bytes):

ldapmodify -H ldapi:/// -Y EXTERNAL << EOF
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcDbMaxSize
olcDbMaxSize: 10737418240

EOF

On 32-bit systems, the max size is constrained by address space limitations, and it may not be possible to grow the database larger than about 2 GiB. For larger databases, a 64-bit system is recommended.

For more information, read about maxsize in slapd-mdb(5).

= Changing the Administrator's Password ==

The password configured during installation is saved in two places. To change the password, both values must be updated. If only one is changed, the old password can still be used. This should be fixed in the next release; see Debian bug #821331.

Use slappasswd(8) to hash the new password, and then use ldapmodify(1) to update the hashed password in the olcRootPW attribute in the database configuration.

# slappasswd
New password: newpassword
Re-enter new password: newpassword
{SSHA}zYHmkowzdMxwX0KtEPNak5IbzfY8YmdQ
# ldapmodify -H ldapi:/// -Y EXTERNAL
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}zYHmkowzdMxwX0KtEPNak5IbzfY8YmdQ

modifying entry "olcDatabase={1}mdb,cn=config"

Next, use ldappasswd(1) to change the password the administrator's account in the directory.

# ldappasswd -x -D cn=admin,dc=example,dc=com -W -S
New password: newpassword
Re-enter new password: newpassword
Enter LDAP Password: oldpassword

Finally, test authenticating with the old and new passwords, and confirm that only the new password can be used.

# ldapwhoami -x -D cn=admin,dc=example,dc=com -W
Enter LDAP Password: oldpassword
ldap_bind: Invalid credentials (49)
# ldapwhoami -x -D cn=admin,dc=example,dc=com -W
Enter LDAP Password: newpassword
dn:cn=admin,dc=example,dc=com

Indexes

For better performance do more indexing than the default:

# ldapmodify -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: cn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: sn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: uid pres,sub,eq
-
add: olcDbIndex
olcDbIndex: displayName pres,sub,eq
-
add: olcDbIndex
olcDbIndex: default sub
-
add: olcDbIndex
olcDbIndex: uidNumber eq
-
add: olcDbIndex
olcDbIndex: gidNumber eq
-
add: olcDbIndex
olcDbIndex: mail,givenName eq,subinitial
-
add: olcDbIndex
olcDbIndex: dc eq
EOF

Note: use the correct database backend in the first line, as noted above, the default type is currently mdb.

Do not leave out the - (dash character) from the file, it is needed. After execution of the ldapmodify command, slapd will launch a internal task to create indexes. Don't stop slapd during indexing.

Samba and OpenLDAP

Since version 4, samba is able to act as an Active Directory Domain Controller, which essentially ties together LDAP, Kerberos, DNS and other services.

In order to do so, Samba includes internal implementations of the necessary services. Instructions for setting up Samba to act as an AD DC can be found in the Samba wiki.

TLS/SSL

FIXME: revise, update and merge these two

Enabling TLS/SSL

To enable TLS in slapd, you will need the server certificate and the associated private key, both in PEM format. You may also have an intermediate certificate. Clients will need the CA certificate which is the Issuer of the server or intermediate certificate.

The files must all be readable by the openldap user. It is recommended to ensure the private key is not readable by any user except openldap.

To configure the server certificate, private key, and intermediate certificate used by slapd:

ldapmodify -H ldapi:/// -Y EXTERNAL << EOF
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/server.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/server.key
-
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/intermediate.pem

EOF

If you do not have an intermediate certificate, the olcTLSCACertificate lines should be omitted. The root CA does not need to be configured in slapd.

If the modifications fail with ldap_modify: Other (e.g., implementation specific) error (80), check the file paths for typos, and ensure the files are readable by the openldap user.

After applying the configuration, test a secure connection using StartTLS:

LDAPTLS_CACERT=/etc/ssl/certs/ca.pem ldapwhoami -H ldap://ldap.example.com -ZZ -x

where ca.pem is the root CA certificate and ldap.example.com is the server's name, exactly matching the Common Name (CN) or Subject Alternative Name (SAN) in the server certificate.

If the secure connection is successful, ldapwhoami should just print anonymous. If it fails, append -d 1 to the command line to enable debug output, and look for lines beginning with TLS:.

By default, slapd supports StartTLS on the standard LDAP port 389. If you wish to enable the LDAPS protocol on port 636, then edit /etc/default/slapd, add ldaps:/// to the SLAPD_SERVICES line, and restart slapd.

vi /etc/default/slapd

...
SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"
...

service slapd restart

LDAPS can be tested the same way, using -H ldaps:// instead of -ZZ:

LDAPTLS_CACERT=/etc/ssl/certs/ca.pem ldapwhoami -H ldaps://ldap.example.com -x

Again, if successful, it should just print anonymous.

For more information, read about TLS Options in the slapd-config(5) man page, noting that the TLS implementation used in Debian is GnuTLS. The OpenLDAP Administrator's Guide also has a chapter about TLS.

Configuring TLS/SSL

By default, slapd runs as user/group openldap, so it can't read the key file. On Debian Lenny, the preferred solution to this dilemma seems to be to chown the key to root:ssl-cert, set permissions to 640 and add the user openldap to group ssl-cert:

usermod -a -G ssl-cert openldap

In Wheezy, not adding openldap to the ssl-cert group caused this in logs:

main: TLS init def ctx failed: -1

Enable LDAPS (if required)

StartTLS is the standard operation for initiating TLS/SSL on an LDAP connection. StartTLS operates on the standard LDAP port (389) and no alternative port is necessary.

Clients using OpenLDAP libldap can be configured to use StartTLS, if they use an LDAP URL for connection configuration, by including the StartTLS extension in the URL. For example:

ldap://ldap.example.com/dc=example,dc=com????!StartTLS

The ldapurl(1) tool is useful for constructing correct LDAP URLs.

Some legacy LDAP clients do not support the StartTLS operation, but are able to use LDAPS (LDAP over SSL) on port 636. To support such clients, add ldaps:/// to the SLAPD_SERVICES list in /etc/default/slapd.

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

Symptoms:

In slapd debug output:

[...] TLS: could not set cipher list HIGH:MEDIUM:-SSLv2.  (or similar)

In /var/log/syslog:

[...] main: TLS init def ctx failed: -1

Diagnosis:

If you try to install the OpenLDAP server (slapd) with Debian Lenny, it comes compiled against the GnuTLS library. It means you cannot use an OpenSSL style directive like TLSCipherSuite HIGH:MEDIUM:-SSLv2 in slapd.conf.

Cure:

In /etc/ldap/slapd.conf, either comment out TLSCipherSuite option to let gnutls choose rather sane default for you, or use something like:

TLSCipherSuite NORMAL

To get all the supported GnuTLS cipher suite names:

# aptitude install gnutls-bin
# man gnutls-cli

And skip to TLS/SSL control options section of man page.

To use only 256 bit cyphers, use this (paranoiac?) setting:

TLSCipherSuite SECURE256:!AES-128-CBC:!ARCFOUR-128:!CAMELLIA-128-CBC:!3DES-CBC:!CAMELLIA-128-CBC

Another useful tool to test server-supported TLS options is to use gnutls-cli-debug. First add ldaps:/// string to the SLAPD_SERVICES option in /etc/default/slapd, restart slapd and then run

gnutls-cli-debug -p 636 <fqdn_of_you_ldap_host>

That will show you cryptographic suits your LDAP server supports.

Symptoms (round 2)

If you are getting messages such as

slapd TLS: can't connect: A TLS packet with unexpected length was received..

Could not negotiate a supported cipher suite.

take a wander by this.

Diagnosis:

How did you generate your certificates? If you generated them using OpenSSL, you're going to run into problems. Debian switched over to using gnutls a while ago, and it doesn't play nice with OpenSSL certificates. So, to fix this, check out the next section.

NOTE: On Debian Squeeze openldap is linked with gnutls as well, but works just fine with certificate generated by openssl.

NOTE about the above note: I don't find it to be the case, except for the CA cert. I ended up having to generate a new key & csr to sign with gnutls's certtool and then signing it with my existing openssl created CA like so:

certtool --generate-privkey --outfile ldap.gnutls.key
certtool --generate-certificate --load-privkey ldap.gnutls.key --outfile ldap.gnutls.crt --load-ca-certificate ca.crt --load-ca-privkey ca.key

Again, this allows you to keep your existing OpenSSL CA. ldapsearch -x -LLL -s base -b ""

Procedure:

You're going to need the gnutls certificate generator: certtool available in gnutls-bin

Run these two commands to generate a new self-signed key (into the current working directory):

certtool --generate-privkey --outfile ca-key.pem
certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem

Then, update your certificate locations in /etc/ldap/slapd.conf (TLSCertificateFile points to ca-cert.pem and TLSCertificateKeyFile points to ca-key.pem), comment out TLSCACertificateFile, and change TLSVerifyClient to never.

In /etc/ldap/ldap.conf, comment out TLS_CACERT and change TLS_REQCERT to never.

Since the certificate is self-signed, we can't have gnutls trying to verify it (hence the never), otherwise it will never run.

Then restart your services, and you're good (assuming all your links point properly to ldaps://url/).

Backup

To backup your LDAP configuration and databases, you use the slapcat(8) command which outputs whole DITs in LDIF format and which can be executed while slapd is running:

# slapcat -n0 -l backup_config.ldif

The above command creates a backup of database 0 (which is the cn=config database) and writes it to backup_config.ldif. After the configuration has been backed up, you need to repeat the command for each of the data directories (in the default installation, you have one data directory, corresponding to e.g. dc=example,dc=com) by using the corresponding database number:

# slapcat -n1 -l backup_data.ldif

For a belt-and-braces approach, you might want to put each database into read-only mode before backing it up, e.g. by running:

# ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
changeType: modify
replace: olcReadOnly
olcReadOnly: TRUE
EOF
modifying entry "olcDatabase={1}mdb,cn=config"

After the backup is complete, you can disable the read-only mode as follows:

# ldapmodify -Q -Y EXTERNAL -H ldapi:/// <<EOF
dn: olcDatabase={1}mdb,cn=config
changeType: modify
replace: olcReadOnly
olcReadOnly: FALSE
EOF
modifying entry "olcDatabase={1}mdb,cn=config"

Note: do not put the configuration database (olcDatabase={0}config,cn=config) in read-only mode, since disabling read-only mode requires writing to the configuration database, you'll end up in a catch-22.

An example of a backup script which automates all of the above can be found here (courtesy of the DebOps project).

Restoration

To restore from a backup, first stop slapd:

# systemctl stop slapd

Then move any configuration directory out of the way:

# mv -i /etc/ldap/slapd.d /etc/ldap/slapd.d.old

Create new directories:

# mkdir /etc/ldap/slapd.d

Next, use slapadd(8) to restore the configuration directory (the parameters are the same as for slapcat, with the addition of -F which tells slapadd where the configuration should live):

# slapadd -n0 -l backup_config.ldif -F /etc/ldap/slapd.d

slapadd is blissfully unaware of file user/group ownership, so you need to correct them manually:

# chown -R openldap:openldap /etc/ldap/slapd.d

Finally, repeat the above steps for each data directory:

# mv -i /var/lib/ldap /var/lib/ldap.old
# mkdir /var/lib/ldap
# slapadd -n1 -l backup_data.ldif -F /etc/ldap/slapd.d
# chown -R openldap:openldap /var/lib/ldap

And start slapd again:

# systemctl start slapd

Note that if you are using any kind of replication, you need to add the -w flag to each slapadd invocation, e.g.:

# slapadd -n1 -l backup_data.ldif -F /etc/ldap/slapd.d -w

This adds additional information to the directory which allows other servers to determine that synchronization is necessary.

Replication

See http://www.openldap.org/doc/admin24/replication.html for a detailed explanation of OpenLDAP Replication. Several types of replication are possible, this section focuses on how to configure MirrorMode Replication (syncrepl), which can be achived by following the steps below.

1: Create a special user for the replication of the data.

This by default can't be done using the SASL/EXTERNAL authentication, since you will get a 'no write access to parent' error. Please use a basedn suited to your situation, in example change the "dc=nodomain" to the basedn for your server. Please see step 7 for the password chosen and use slappasswd command to format it.

$ ldapmodify -D "cn=admin,dc=nodomain" -W<<EOT
> dn: cn=mirrormode,dc=nodomain
> changetype: add
> objectClass: simpleSecurityObject
> objectClass: organizationalRole
> cn: mirrormode
> description: Syncrepl user for mirrormode operation
> userPassword: e1NTSEF9SktNQmpPV29zOEtPSCtaWmdDeTVUa056U3c5NWF5bis=
> EOT
Enter LDAP Password:
adding new entry "cn=mirrormode,dc=nodomain"

$

All the other steps can easily be done using the SASL/EXTERNAL authentication as explained in Missing slapd.conf. Just save the given information in a file and load it with: $ ldapmodify -Y EXTERNAL -H ldapi:/// -f <file.ldif>

2: Load the syncrepl module

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

3: Set up replicator privileges

Make sure the newly created replication user can read the data to be replicated:

dn: olcDatabase={1}hdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=nodomain" write by * none
-
add: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=nodomain" write by dn="cn=mirrormode,dc=nodomain" read by * none
-

4: Set up the provider slapd

dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
changeType: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 10
olcSpSessionLog: 100

5: Set up indexing for entryUUID

Note that using the session log requires searching on the entryUUID attribute. Setting an eq index on this attribute will greatly benefit the performance of the session log on the provider:

dn: olcDatabase={1}hdb,cn=config
changeType: modify
delete: olcDbIndex
olcDbIndex: objectClass eq
-
add: olcDbIndex
olcDbIndex: objectClass,entryCSN,entryUUID eq
-

6: Set the server ID.

Make sure you use different ID's for different servers, in example 0, 1, etc...:

dn: cn=config
changeType: modify
add: olcServerID
olcServerID: 0
-

7: Enable the replication.

Make sure you use the correct IP number for each ldap server and make sure they point to each other! Also, the credentials are just an example. Choose a password of your own of course:

dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcSyncrepl
olcSyncrepl: rid=001 provider=ldap://172.16.42.74:389 bindmethod=simple binddn="cn=mirrormode,dc=nodomain" credentials=_ei7N8o.gh=o44 searchbase="dc=nodomain" schemachecking=on type=refreshAndPersist retry="60 +"
-
add: olcMirrorMode
olcMirrorMode: TRUE
-

And you're up and running. Try adding something to one of the LDAP servers and see it appear automagically at the other. Well done my friend!

LDAPOpenLDAPSetup

Initial Installation

Tools

Configuration

Schema Files

Database Backends

Permissions

Administrator Access

Access Control Lists

Access Control Example 1 - chsh and chfn

Access Control Example 2 - Multiple LDAP Admins

Logging

Database Max Size

Indexes

Samba and OpenLDAP

TLS/SSL

Enabling TLS/SSL

Configuring TLS/SSL

Enable LDAPS (if required)

Symptoms:

Diagnosis:

Cure:

Symptoms (round 2)

Diagnosis:

Procedure:

Backup

Restoration

Replication

1: Create a special user for the replication of the data.

2: Load the syncrepl module

3: Set up replicator privileges

4: Set up the provider slapd

5: Set up indexing for entryUUID

6: Set the server ID.

7: Enable the replication.

Further Reading

LDAP
OpenLDAPSetup