LDAP — Part III (Advanced Topics)

This month, we conclude our look at OpenLDAP. In our previous two columns, we considered the basics steps involved with setting up an LDAP-based directory service as well as ways of using one for user authentication.

This month, we conclude our look at OpenLDAP. In our previous two columns, we considered the basics steps involved with setting up an LDAP-based directory service as well as ways of using one for user authentication.

In this column, we will consider directory entry access control (introduced last month), discuss the various ways of authenticating to the LDAP server and protecting data transmitted over the network, and finish with a look at some issues and techniques relevant to large directories and/or large numbers of clients.

Access Control

As we noted last month, access control entries are defined in the /etc/
configuration file. They serve to specify who should be permitted to view or modify entries as well as attributes within a directory. An access control entry has the following general form:

access to data
by whom access-level
[by ... ]

where data is an expression for the entries and possibly attributes to which this directive applies, whom specifies who this directive applies to, and access-level is the level of access they are granted. There can be multiple by clauses. Both literal values and regular expressions can be used when specifying values for data and whom. Remember that the first expression which matches the by clause is the one that will be used.

The various access levels are listed below:

  • none: no access

  • auth: should be used for authentication purposes only

  • compare: values are accessible to comparison operations

  • search: values are accessible to search filters

  • read: data can be viewed

  • write: data can be both viewed and modified

The values of whom include dn and the keywords self (the owner of the entry), domain (which takes an expression for a domain as its argument), and anonymous (access by users who haven’t been authenticated). A single asterisk can be used to signify access by anyone.

Let’s look at some examples. The configuration file directive in Figure One allows everyone to have read access to the entire specified directory and also allows each entry’s owner to modify it.

Figure One: Sample Directive A

access to dn=”.*,dc=ahania,dc=com”
by self write
by * read

Figure Two shows a directive that allows each entry’s owner to read the entire entry but modify only a few attributes.

Figure Two: Sample Directive B

access to dn=”.*,dc=ahania,dc=com” attrs=”cn,sn,description,gecos”
by self write
access to dn=”.*,dc=ahania,dc=com”
by self read

Figure Three shows how you can allow the uid root (in any top-level organizational unit) to modify any password attribute in the directory. Note that we are assuming that ou names contain only letters.

Figure Three: Sample Directive C

access to dn=”.*,dc=ahania,dc=com” attrs=”password”
by dn=”uid=root,ou=[A-Za-z]+,dc=ahania,dc=com” write

Finally, the directive shown in Figure Four is used to control access to the entries under the specified ou, limiting read access to members of the local domain.

Figure Four: Sample Directive D

access to dn=”.*,ou=People,dc=ahania,dc=com”
by domain=.*\.ahania\.com read
by anonymous auth

Non-authenticated users can use the data in this subtree only for LDAP authentication purposes.

You can reference the OpenLDAP
Administrator’s Guide
at http://www.openldap.org/doc/admin for complete details about using access control directives.


In all the examples to this point, we have considered only the simplest method of presenting authentication credentials to the LDAP server — supplying a password associated with a specific distinguished name’s password attribute. This method is known as simple authentication and is the easiest way to bind to the LDAP server. However, since the passwords are sent to the server in the clear, there are obviously significant security problems with this approach.

OpenLDAP supports the following authentication schemes: simple authentication using passwords, Kerberos-based authentication, and using the authentication services provided by the Simple Authentication and Security Layer (SASL).

The first two of these are selected by the -x and -k options to the various LDAP client commands, and the absence of either of them implies SASL should be used. The Kerberos authentication method is deprecated, however, since superior Kerberos functionality is provided by SASL.

SASL was designed to add additional authentication mechanisms to connection-oriented network protocols like LDAP. Linux systems use the Cyrus SASL library, which provides the following authentication methods:

  • ANONYMOUS and PLAIN: used for anonymous, standard, and simple plain-text password-based binds

  • DIGEST-MD5: used for MD5 encoded passwords

  • KERBEROS_V4 and GSSAPI: used to provide Kerberos-based authentication for Kerberos 4 and Kerberos 5 (respectively)

  • EXTERNAL: used for site-specific authentication modules

Installing and configuring SASL is somewhat complex, and we don’t have space to consider it here. Be sure to check the SASL Web site (http://asg. web.cmu.edu/sasl) for more information about it.

OpenLDAP also provides a way to secure the simple authentication scheme. This is done via an interface to the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) networking functions. SSL provides encrypted authentication and data transfer via port 636 (assigned to the ldaps service), while TLS provides this via the standard LDAP port of 389. The advantage of the latter is that both encrypted and non-encrypted clients can use the same standard port. However, it is usually best to enable both of them, since client support is varied and unpredictable.

In order to use SSL and TLS, you will need to create a certificate for the LDAP server using a process like the one in Figure Five. First, we change to the SSL certificates directory; then, we run the command that creates the certificate and key files. This process requires you to enter a pass phrase for the private key and to provide many items of information used in creating the certificate. When this process completes, the certification is located in the file slapd_cert. pem, and the key is stored in slapd_key. pem.

Figure Five: Creating a Certificate for the LDAP Server

# cd /usr/ssl/cert
# openssl req -newkey rsa:1024 -x509 -days 365 \
keyout slapd_key.pem -out slapd_cert.pem
Using configuration from /usr/ssl/openssl.cnf
Generating a 1024 bit RSA private key
writing new private key to ‘newreq.pem’
Enter PEM pass phrase:
Verifying password – Enter PEM pass phrase:
You are about to be asked to enter information that
will be incorporated into your certificate request.
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Connecticut

The next steps consist of removing the pass phrase from the key file (otherwise, you’ll need to enter it every time you start slapd) and then setting appropriate ownership and protections for the files:

# openssl rsa
-in slapd_key.pem
-out slapd_key.pem
# chown slapd-user.slapd-group
# chmod 600 sl*.pem

After certificate files are created, add entries to slapd.conf pointing to them (see Figure Six, ). Finally, we might be sure to modify the boot script that controls slapd so that the startup command lists both normal and secure ldap as supported protocols:

Figure Six: Specifying a Certificate for the LDAP Server

TLSCertificateFile /usr/ssl/certs/slapd_cert.pem
TLSCertificateKeyFile usr/ssl/certs/slapd_key.pem
# Specify ciphers to use –
# this is a reasonable default

# slapd -h
“ldap:/// ldaps:///”

After you restart the server, you can verify that things are working in several ways. An easy approach is to simply run a search command and watch the associated network traffic as it runs. I use the ngrep utility to watch the two ldap ports and look for the string bbb, which is the password I am going to use for binding to the server:

# ngrep ‘bbb’ port 636 or
port 389

Then, in another window, I run an ldapsearch command, which binds to a test entry in the directory (uid= a2), specifying the password with -w and using ldaps:

# ldapsearch -H
-w bbb -x -D

Guru (tls Client)
Figure Seven: Enabling TLS support in the gq client.

The search command should return some entries, and the ngrep command will not find any matching packets since the password is encrypted.

Alternatively, you can use a client that supports one or both of these facilities. Figure Seven illustrates the gq utilities server properties dialog. You can check the appropriate box to use TLS and then run a test similar to the preceding.

If you have problems binding to the server, make sure the password you are using is the correct one for that entry and that the access level for your test entry is sufficient for the operation to succeed. Finally, make certain that you have restarted the slapd process and that it has not generated any error messages.

Distributed Directories

So far, we have considered only scenarios in which the entire directory is located on a single server. For many contexts, this is an entirely reasonable scenario. However, problems can arise when either the amount of data or the resource requirements of a large number of clients happens to exceed what a single server can support.

In the first case, the solution is to split the directory data among more than one server. Each chunk of data is known as a directory partition or simply a partition, and partitions are also sometimes referred to as naming contexts. When the data is partitioned, each server holds a subset of the data, and the entire directory tree is stitched together using a mechanism known as referrals. In this way, clients do not need to know or care where any particular entry actually resides.

There are two types of referrals. Subordinate referrals occur when another server holds a subtree that logically fits under a local directory entry. This type of referral is specified by an entry in the directory. Figure Eight contains an example.

Figure Eight: Defining a Subordinate Referral

dn: ou=RD,dc=ahania,dc=com
objectClass: organizationalUnit
objectClass: referral
ou: RD
ref: ldap://server2.ahania.com/ou=RD,dc=ahania,dc=com

This entry indicates that any request for entries in the RD ou should be referred to host server2, and that those entries reside relative to the specified dn in its directory. Any time that this entry is encountered, the corresponding operation will be referred to host server2.

In order to create or modify such entries, the ldap client commands need to include the -M option, which says not to follow any referrals that may be encountered.

Superior referrals are ones used for entries that are outside the naming context of the local server. They are set up via an entry in slapd.conf, which is shown below:

referral ldap://server1.

This directive tells the local server to refer any requests for which it does not hold the entry to server1.

Replication is the method used to address the other resource concern — more clients than a single server can handle. This method involves multiple copies of the same directory being made available by different servers so client requests can be split among them.

The replication method is also a useful technique when you find yourself with LDAP users on both sides of a slow network connection; you can use it to place a server in each site to which local clients can connect. In this way, you succeed in limiting WAN traffic to updates.

Replication involves one or more slave servers that are subordinate to a master server. The master holds the authoritative copy of the directory, and a daemon on the master (slurpd) sends directory changes to the slave servers. Modification operations attempted on a slave server are forwarded to the master, where they are actually executed (and then propagated back to the slave).

The following steps show you how to set up replication:

  • On the master server, add entries to slapd.conf specifying slave servers:

replica host=slave.ahania.com
# Entry used to bind to
this slave
dc=ahania, dc=com”
# Log file for updates

  • On the slave server, edit slapd.conf to point to the master:

updatedn cn=Update,dc=ahania,
updateref ldap://master.

You will also need to create the entry that is specified in the first line within the directory.

  • Shutdown the slapd server on the master and then copy the database files to the slave server.

  • Restart the slapd processes on all of the servers.

  • Start slurpd on the master, specifying the update log file with -f:

slurpd -f /var/log/slurpd/

You can define multiple master servers (with distinct sets of slave servers) or a hierarchy of masters and slaves, as appropriate for your site.


We will conclude our look at OpenLDAP by considering directory backup options. Basically, there are four main strategies that can be followed for backing up a directory:

  • Use disk mirroring for real-time fault tolerance.

  • Use the replication method as an implicit mechanism, promoting a slave to master should the master fail.

  • Read entries from the directory using a command like ldapsearch and save them in LDIF format. This process can be quite lengthy, but it is viable for directories where the data is nearly static.

  • Backup the database file periodically. It is best to do so when slapd is not running. Alternatively, you can use a snapshot mechanism to effectively checkpoint the current directory state, which can then be backed up even though the directory remains in use. This feature is provided by some commercial backup programs and is also available if you use the Logical Volume Manager.

I hope you have enjoyed this overview of OpenLDAP and have learned about some of its capabilities. Have fun experimenting with it and implementing it in your own environment.

AEleen Frisch is the author of Essential System Administration. She can be reached at aefrisch@lorentzian.com.

Comments are closed.