Central Register

Today's OpenLDAP server was created by Kurt Zeilenga in 1998 as a clone of source code for the LDAP (Lightweight Directory Access Protocol) server at the University of Michigan. Interestingly, the OpenLDAP project has never been dormant but has evolved constantly and is therefore still as progressive and groundbreaking as ever. However, strict enforcement of the numerous changes also puts off some users.

Usually, changes of elemental components in a version are marked as deprecated with an appropriate warning, indicating which functionality will no longer be available in the next version. Although this means ensuring progress for the project, for the administrator, it means always having to keep on your toes.

The OpenLDAP server has a long history in the Unix world. The beginnings of the project date back to 1998 when the issue of central user administration was only taken seriously in the enterprise environment. Small isolated solutions were then the basis for central user administration; directory servers were only available from major IT vendors. Older readers will perhaps smile when they think back to the beginnings of domain management on Windows NT, Novell Netware, or NIS.

A mature service was also available in the form of X.500, but it was not very widespread in practice. LDAP was originally designed as a protocol for X.500 services. This mutated into the LDAP directory servers that are seen in a variety of uses today.

What Is a Directory Server?

A directory server provides a container for information that can be queried via the LDAP protocol and matching clients. Some people compare this with a phone book, but the comparison is tenuous. Although an LDAP server can contain contact information for the company, it can also be enriched with additional information. Ultimately, however, the type of information is not specified, so the directory could accommodate a product catalog or an inventory list.

A directory server is always useful whenever information is to be stored in a tree-like structure with corresponding sub-branches. The tree structure is referred to as the DIT (Directory Information Tree). Each item of information stored within the tree can contain a set of attributes, some of which are mandatory and others optional. The schema determines which attributes are available. The OpenLDAP server provides its own configuration in a DIT, for example.

In this article, you will learn how to install and commission OpenLDAP server version 2.4.23 on CentOS 6.5. As an example, I will authenticate users of a web server, although the configuration can also be extended for operating systems or other services. At the end of the article, you will have a fully functional LDAP server for the enterprise that is easily extensible and reflects the current state of CentOS 6.5 and OpenLDAP 2.4, without having to piece together the configuration.

Installing the OpenLDAP Server

Installing OpenLDAP is easy. All required packages are found in the CentOS repositories and are thus available in any CentOS installation without further change. Using the Yum package manager, the install takes just a single command line:

$ sudo yum install openldap-serversopenldap-clients httpd ldapvi

The first two packages are self-explanatory and are required to install and manage the OpenLDAP server. The web server, httpd, is used in the course of the tutorial to demonstrate authentication and authorization of a web server location against the LDAP server. The ldapvi tool is a universal, command-line LDAP client ideal for smaller administrative tasks.

Configuration via OLC

OpenLDAP version 2.4, which is the one in the CentOS repository, changed to the dynamic configuration model known as OLC (On-Line Configuration). In the various bits of documentation for OpenLDAP, you will repeatedly see references to the cn = config method, which means the same thing.

The cn=config model stores the configuration data on the LDAP server which is processed by the LDAP client tools. In the old model, the OpenLDAP server was still managed via a central configuration file. The reasons for the change, which at first sight make everything more complicated, become apparent upon second inspection.

Changes can be made on the fly, without requiring a server restart. Especially for larger installations, however, restarting is relatively time-consuming and can take several minutes. Additionally, the LDAP server loses its cache, which resides in main memory, on a restart. Requests then take longer until the cache is repopulated.

The dynamic configuration model removes the need for reboots and ensures availability of the LDAP server. Once you understand the concept behind the new configuration model, it also feels more coherent. In the old model, the configuration files were stored in a directory tree below /etc/openldap/slapd.d; it took priority over an /etc/openldap/slapd.conf configuration file that you might happen to have. In this article, I focus exclusively on the new model.

After the installation, some steps are required before you can start the LDAP server daemon, slapd. First, you must decide on a data back end. OpenLDAP supports a variety of back ends, starting with Berkeley DB (BDB; the default), MySQL, Memory databases, or even Perl data structures. In the sample configuration here, the LDAP server uses BDB.

The following steps must be run with root privileges. Instead of working directly as the root user, all commands run with sudo. The OpenLDAP server includes a configuration template to help you create an initial database. Copy it to the data directory on the OpenLDAP server:

$ sudo cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

The template contains information about cache size and database logfiles. However, all these values can be modified later on, thanks to the dynamic configuration model. After copying the file, check to see that the OpenLDAP server is configured properly and then start it with:

$ sudo slaptest -u
$ sudo chkconfig slapd on
$ service slapd start

Voilà, the OpenLDAP server is ready for an initial configuration. Currently, even though the server is running, no one can connect.