It’s common for organisations to have a number of authentication databases scattered around the network. You might, for instance, have a user database on your Windows server, then another on your Linux mail server. Add to this the internal user list in your firewall that does authentication for VPN users, and maybe some extra stuff for the networked anti-virus software’s remote control system, and you have a collection of separate databases that have to be maintained separately – so when a password is changed in one world, the change isn’t reflected in others.
A directory service is designed to bring all your identification and authentication information into a single, easy-to-control entity. The name pretty well describes what it does – it acts as a general “directory” that networked components can use to look up information about people and other stuff that are using the network.
The common way for networked devices to access the directory service is using the Lightweight Directory Access Protocol (LDAP). LDAP is a standard, relatively simple mechanism that enables client devices to interrogate a directory service, and any device that is able to integrate to an external user database is more than likely to use LDAP to do so.
Now, if you’re a biggish organisation that uses some kind of proprietary directory service already (Microsoft Active Directory is the obvious one if you have Windows 2000 Server or WS2003) then you’ll usually be able to talk to these services through LDAP as they’re able to communicate that way. If you’re not using a directory service, though, you’re not stuck: you can simply implement a central service using OpenLDAP, an open source LDAP directory service.
About OpenLDAP OpenLDAP is happy to run on most modern Unixes and Linux. In fact, before you think about downloading it, check to see that it’s not already installed on your system, or is included on the installer CD but wasn’t among the things you selected at install time.
Although the package is supplied as a bunch of source files, and you have to compile it yourself, this isn’t something to be too frightened of – to get a basic implementation up and running you just follow the installation instructions through step-by-step and it all just builds itself.
Once you’ve downloaded and unzipped the software to your server of choice, you run the configuration script. This looks around your machine and figures out what type of Unix you have, setting itself up appropriately:
Once the configuration process has run, you tell it to run through and set up the various source code directories with the options that were figured out by the configure command:
This takes just a few seconds to run. Next, the biggie – you’re telling it to go and compile the code. There’s a lot of it, so it’ll take a while (about 10 minutes on our PIII server):
Once the build has finished, there’s a suite of test programs that you can run to make sure everything is as it should be. The whole process is automated, and as there are 40-odd different tests to run through, it’s an opportunity to make the tea or take the dog for a walk:
Finally, if the tests all worked OK (and it’s unusual if they don’t), you can install the software (make sure you’re the “root” user, as it needs to write to system directories that aren’t writable by normal login IDs):
Configuring OpenLDAP Once the product has installed, it’s time to configure it appropriately. In our simple example, we’re going to set OpenLDAP up to be a basic server of user identities and information (the kind of thing that you’d typically use for networked devices such as VPN servers or dial-in modem server to use for ID authentication).
The first thing to comprehend is the concept of a schema. A schema is, in simple terms, a description of the type of data you’ll be holding. Now, if you’ve used any kind of directory service before, you may have come across cryptic-looking things like dc=techworld,dc=com or sn=Bloggs – in fact when you’ve been creating user IDs in, say, a Windows server, you may have seen these generated by the server without you needing to know what’s going on.
By default, OpenLDAP uses only the “core schema”. This is the basic set of data that is used by pretty much any directory service, and in fact you’ll see it defined in RFC2256, “A Summary of the X.500(96) User Schema for use with LDAPv3”, available from http://www.ietf.org/rfc/rfc2256.txt. The data items you’ll see in LDAP directories are inherited from the specification of the X.500 directory system; the latter is big, scary and complex when used in full, but its naming schema is pretty comprehensive and so LDAP adopted it instead of reinventing the wheel and creating its own version of the same thing.
There are about 50 or so data items in the core schema, from simple stuff like sn (surname) and street (the street component of an address) to certificateRevocationList (used to store lists of SSL certificates which are known to have been revoked by their issuing authorities).
The basic OpenLDAP configuration
To get running with OpenLDAP, we need to know only a handful of key things:
• The domain name the directory will serve
• The password we want to use for the super-user
• The name we want to use for the super-user
• Where the various OpenLDAP files live on the server
Before we start, we need to generate an encrypted super-user password. We need to do this because the password is pasted into the config file – so you don’t want it to be sitting there as a plain-text string! We therefore use the slappasswd command:
[root@localhost ~]# slappasswd
Re-enter new password:
You’ll see that we were prompted for the password, and then for a re-type, and were then given a cryptic-looking string in response. This is basically telling us that slappasswd chose to use a seeded version of the SHA-1 hashing function and that the result was the string 70u1ktNLJSC7tCatm1cAhVX58wnfv4BP.
Now, back to the configuration process. The installation process will have created a configuration file called slapd.conf somewhere on the server disk. slapd, by the way, is the name of the program that actually provides the directory service. Our config file was dropped into /usr/local/etc/openldap/slapd.conf by the installer.
You should find that the setup routine put some essential lines into the config file to tell the system where its key directories are:
First job is to set your domain in the config file; in our installation this was /usr/local/etc/openldap/slapd.conf (slapd is the program that provides the LDAP service).
This suffix defines the top level of the domain we’re working within – so you’ll only be able to define items within this domain unless you add others to the config file. Here we’ve configured it for the techworld.com domain – basically you have a dc, or domain component, entry for each bit of your domain name.
Next, we need to tell the system the name of the super-user; we’ll use username ldapadmin within the techworld.com domain:
Notice anything familiar? The rootpw, or super-user password, is the string we got back from slappasswd earlier. It’s a whole lot more secure than putting the plain-text password in the config file.
Finally, we need to tell the server what fields in the directory it should index:
index objectClass eq
index cn,sn,uid pres,eq,approx,sub
MORE IN HERE
And that’s it for now – all we need to do is fire up the server:
Managing the directory Once you have the directory service up and running, you can manage it from the command line on your Unix/Linux system if you’re feeling that way inclined. For example, we could add the top-level domain information and the specification for the ldapadmin user to the directory (something we need to do even though it’s specified in the config file) by bashing the appropriate lines into a text file:
# Organisation record for Techworld
description: The Techworld Directory
# Organisational Role for ldapadmin user
description: LDAP administrator
… and importing it into the directory (in this case we’ve called the file techworld.ldif) with the ldapadd command:
ldapadd -f techworld.ldif -x -D "cn=ldapadmin,dc=techworld,dc=com" -w techworld
Most sensible mortals will, however, decide that some kind of GUI tool is the order of the day. That nice Mr. Google will find plenty for you, and you can take your pick; we chose to try out LDAP Administrator 3.4 from Softerra (a commercial offering that cost US$175.00).
Next steps Although you can use your LDAP world for basic user authentication, you can of course explore more complex uses for it. For those of you who use SAMBA to provide Windows filesharing from Unix/Linux servers, for instance, you’re able to point SAMBA at an LDAP directory instead of letting it use its own private password files. And what’s to stop you if you have, say, Linux servers or desktops, from integrating them into the LDAP directory too? And of course, to integrate networked devices into the directory is simply a case of bashing the server’s address into the devices’ configuration screens.
Naturally, if you’re intending to run a production-class directory service, you’ll use more than one server and allow the LDAP instances to replicate between themselves. That’s beyond the scope of this article, but it’s not a big leap from a stand-alone server, and the documentation covers how to do it.