Author: Brian Jones
daemon (slapd), a replication daemon (slurpd) and a small collection of command line client tools, like
ldapsearch and ldapadd, among others. In this article, we’ll set up and populate a small but functional LDAP server using the slapd daemon, and start to make use of it with a Linux client.
Obtaining and installing OpenLDAP
You can download OpenLDAP from the OpenLDAP
website. While it is certainly possible to obtain precompiled binary
distributions of OpenLDAP in RPM, deb, and other package formats, these tend to be somewhat older releases. There are many useful customizations you can make during an OpenLDAP compile, and I’ve never had much trouble compiling OpenLDAP from source, so this is the method I’m advocating.
This is not to say that there are absolutely no dependencies to satisfy. There are two major dependencies, both of which are very easy to handle:
Berkeley DB
The OpenLDAP team strongly recommends using Sleepycat Software’s Berkeley DB as the data storage mechanism for an OpenLDAP deployment. As we mentioned in Part One of the series, LDAP is not a database, but a protocol for accessing and managing data. But the data has to live somewhere, and Berkeley DB is easy to deal with, even for newbie admins. If you’re among those who have nightmares about databases, take heart in knowing that OpenLDAP does a superb job at hiding the fact that you’re even dealing with one. Download the Berkeley DB source from the user-friendly Sleepycat download page. For my test build, I used Berkeley DB 4.1.25 without strong encryption support.
Building Berkeley DB couldn’t be easier. Unpack the tarball, cd to the
build_unix directory, and type ../dist/configure, followed by make and
make install (the last as root). This will create a directory called
/usr/local/BerkeleyDB.4.1, which contains all of the pertinent parts we need for our OpenLDAP installation.
OpenSSL
If you’re using Redhat, Fedora, Mandrake, SuSE, or any number of other recent
distributions, OpenSSL is probably already installed. If it
isn’t, and you wish to enable secure connections to your LDAP server, you
need to install it. Luckily, this is a breeze. Grab a source tarball from the
OpenSSL Download Page. Untar it, cd to the resulting directory, and run the standard configure and make
commands. I also recommend that you run make test, and then (as root, of course) make install. This puts everything you need in the /usr/local/ssl directory by default. For this article, I’m using openssl 0.9.7c.
Last but not least, OpenLDAP
Finally, with all of the other prerequisites installed, we can build our
OpenLDAP server. Since I’m assuming no prior knowledge of using OpenLDAP, we’re going to start out with a simple but still very usable build. We’ll enable TLS, use the Berkeley DB backend, and add support for replication. I’ll also include support for syslog and crypt passwords. I generally also change the --sysconfdir to /etc so that configuration files fall under /etc/openldap, but this is just a personal preference.
Given that we’ve installed our dependencies into their own directories under
/usr/local, we need to let the openldap build know where these things are.
The way that I’ve always done this comes straight out of the Build and Install
Section of the OpenLDAP Administrator’s Guide. Here’s what my configure line looks like:
env CPPFLAGS="-I/usr/local/BerkeleyDB.4.1/include -I/usr/local/ssl/include/openssl"
LDFLAGS="-L/usr/local/BerkeleyDB.4.1/lib -L/usr/local/ssl/lib"
./configure --with-tls --enable-slurpd --enable-crypt --enable-syslog
--sysconfdir=/etc
If you’ve followed along to the letter, this should complete without error.
Next run make depend, followed by make. Once make completes successfully you should run make test, which puts your build through its paces before you run make install.
Before going further, I strongly recommend you create a user for
your LDAP server to run under. Don’t use root or nobody to run your LDAP server. I usually create an “ldap” user and group; if you’re on a system that has OpenLDAP installed from the distribution CDs, you may already have the user on your system. If not, here are the steps to get everything set up:
[root@livid /]# groupadd ldap
[root@livid /]# useradd -g ldap -d /var/lib/ldap -s /bin/false ldap
[root@livid /]# chown -R ldap.ldap /var/lib/ldap
Notice that we gave the ldap user a home directory of /var/lib/ldap. This is
the directory where OpenLDAP stores its database files, so it’s important that the ldap user have permission to read and write in that
directory.
Configuring slapd for startup
Once you’ve completed the build, your slapd and slurpd daemons are located
in /usr/local/libexec, your config files are in /etc/openldap, and you’re ready to start up the main server daemon, slapd. Before we can start slapd, we need to edit /etc/openldap/slapd.conf to tell it where to store its data and who is allowed access to the data. Since this article’s focus is more “proof of concept” than production deployment, we’ll start simple and add as we go.
Here’s a quick and dirty slapd.conf that gets the daemon up and running and allows an administrative user to manipulate data:
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
This first section is material for another discussion, really. Schema files define objects and attributes. When the slapd daemon starts, it includes whichever schema files we tell it to here, and that determines the types of objects and attributes supported by that slapd daemon. So, for example, if we did not include the nis.schema file, we would not be able to add typical Unix accounts using only the other schema files we’ve included. Schema files are human-readable, and you could even create your own schema files if you needed some wacky object-types that aren’t already defined.
allow bind_v2
pidfile /var/run/slapd.pid
In newer versions of OpenLDAP, only LDAPv3 binds are allowed by default, which has caused many a mailing list crisis, since there are applications that don’t support making a version 3 bind to a directory server. In the event we come across any in our travels, we’ve allowed LDAPv2 binds for our proof-of-concept, as you can see here:
database bdb
suffix "dc=linuxlaboratory,dc=org"
rootdn "cn=Manager,dc=linuxlaboratory,dc=org"
rootpw {SSHA}c5PemO1KWqz0254r4rnFVmxKA/evs4Hu
directory /var/lib/ldap
Our database backend is the Berkeley database, which OpenLDAP knows as “bdb.” The slapd.conf man page can tell you other possible values for the database directive. Our suffix uses what’s known as the “domain component” model. This model just takes the parts of a domain and references each part of the domain name as a separate domain component (dc). We’ll talk more about this in a future article.
The rootdn and rootpw values define the administrative username and password for performing on the directory or its data operations that require administrative priveleges. The username is defined using a common name (cn), and the object entry for that user is stored directly under our top-level entry — hence the trailing domain components. The password is generated using the slappasswd command, which simply prompts you for a password and generates output which can be cut and pasted into the slapd.conf file, as I’ve done here.
directory tells the slapd daemon where to store the data files for this particular database definition. There can be several database sections in a slapd.conf file. Here, we’re telling slapd to use its home directory as its data storage directory, which is why the ldap user must be able to write there.
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
Defining indexes at this early stage won’t make a great amount of difference. However, as the directory grows and more demands are placed upon it, indexes can mean the difference between users who don’t notice that things that used to be handle by, say, NIS are now handled by something else, and a completely unusable directory server.
Fire it up!
It’s time to light this candle! When starting the slapd daemon, I generally use extra caution to make sure that if anything goes wrong, it’s not due to something silly like reading the wrong config file or trying to run as someone other than the ldap user I spend so much time creating. Here’s the syntax I use to start the slapd daemon:
[root@livid libexec]# ./slapd -f /etc/openldap/slapd.conf -u ldap
[root@livid libexec]# ps -ef |grep slap
ldap 7595 1 0 15:25 ? 00:00:00 ./slapd -f /etc/openldap/slapd.conf -u ldap
root 7598 7550 0 15:25 pts/0 00:00:00 grep slap
Running nmap localhost should turn up port 389, which is the standard LDAP port. Port 636 is the LDAP over SSL port, but we’ll be using TLS in the future, which allows us to make either encrypted or cleartext connections over a single port (389).
[root@livid libexec]# nmap localhost
Starting nmap 3.48 ( http://www.insecure.org/nmap/ ) at 2004-02-29 15:36 EST
Interesting ports on livid (127.0.0.1):
(The 1655 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE
22/tcp open ssh
389/tcp open ldap
Nmap run completed -- 1 IP address (1 host up) scanned in 3.161 seconds
Stay tuned
At this point, we’ve installed all of the dependencies needed to deploy an OpenLDAP server, we’ve built OpenLDAP itself, and we’ve insured that it is operational. In our next installment, we’ll go over LDIF, the LDAP Data Interchange format, we’ll dive deeper into LDAP’s data model, and we’ll start actually adding entries into the directory.
