LDAP for Security, Part I

The main server dæmon in OpenLDAP is called slapd, and configuring this program is the first step in getting OpenLDAP working once it's installed. Its configuration is determined primarily by the file /etc/openldap/slapd.conf. The “OpenLDAP 2.0 Administrator's Guide” at www.openldap.org/doc/admin20/guide.html has an excellent quick-start procedure for getting slapd up and running: it's in Section 2, starting at Step 8. That document also explains directory services and LDAP concepts in more depth than this article does, using tree/hierarchy diagrams.

Let's walk through this procedure to make sure you get off to a good start. The first thing to do is edit slapd.conf, an example of which is shown in Listing 1. As you can see, slapd.conf is a typical Linux configuration file: each line consists of a parameter name followed by a value.

Listing 1. Customized Part of /etc/openldap/slapd.conf

The first parameter shown in Listing 1, database, specifies what type of database back end to use. Usually, the best choice here is ldbm, which uses the fast dbm database format, but shell (for custom shell-script back ends) and passwd (to use /etc/passwd as the back end) also are valid choices. There may be multiple database definitions, each with its own set of applicable parameters; all the lines in Listing 1 comprise a single database definition.

The next parameter in Listing 1 is suffix, which determines what queries match this database definition. Here, the specified suffix is wiremonkeys.org, expressed in LDAP-speak as a series of domain component (dc) statements, which are parsed from left to right. In other words, if an LDAP client queries our example server for information about the distinguished name (dn) cn=bubba,dc=wiremonkeys,dc=org, our server matches that query against this database definition, as the dn ends with dc=wiremonkeys,dc=org. See the Sidebar “A Crash Course in X.500 Naming” for more information about distinguished names.

Sidebar: A Crash Course in X.500 Naming

The next two entries in Listing 1 have to do with LDAP database administration; rootdn and rootpw specify the user name and password, respectively, that must be supplied by remote or local commands that perform administrative actions on the LDAP database. Interestingly, this entry is used only for this purpose. It doesn't show up in regular LDAP database queries.

This addresses the paradox of how to authenticate the actions required to populate the authentication (LDAP) database. Later, after you've populated your LDAP database with real entity records, designate one of them as the administrative account, using slapd.conf access control lists (acls), and delete the rootdn and rootpw entries. I'll cover that step in a future column; for now, rootdn and rootpw suffice.

It's a very, very bad idea to store the value of rootpw as clear text. Instead, you should use the slappasswd command to generate a password hash, shown in Listing 2.

Listing 2. The slappasswd Command

As you can see, slappasswd prompts you for a password and prints that password hashed with the algorithm you specify with the -h option. Be sure to enclose this value in curly brackets—see the slappasswd(8C) man page for a list of valid choices. You can copy and paste slappasswd's output directly into slapd.conf, which is precisely what I did to create the rootpw value in Listing 1.

Getting back to Listing 1, the next parameter in this directory definition is directory. Obviously enough, this specifies in which directory on the local filesystem your LDAP directory should be created. Because /var is the customary place for growing files such as logs and databases, Listing 1 shows a value of /var/lib/ldap. This directory must already exist, and make sure it's owned by OpenLDAP's user and group, usually ldap and ldap. Its permissions should be set to 0700 (-rwx------).

Technically, that's enough to get started: you can try starting slapd with your ldap startup script, most likely /etc/init.d/ldap, though this may vary among distributions. I encourage you to start adding practice entries to your LDAP database using the ldapadd command—the quick-start procedure I mentioned earlier shows how.

Before you begin managing and querying your LDAP database over the network, however, you'll want to configure and enable TLS encryption. This is important, as the simple authentication method used by OpenLDAP sends authentication credentials over the network unencrypted. But I'm out of space for now, so we'll cover that next month. If you can't wait until then, Vincent Danen explains how in his on-line article “Using OpenLDAP for Authentication”, at www.mandrakesecure.net/en/docs/ldap-auth.php, though it is somewhat Mandrake-centric. I'll also discuss some considerations in determining the structure of your LDAP database and show how to build one. Until then, good luck!