- About Us
Linux is probably the easiest operating system to configure for authentication against an LDAP server, thanks in large part to the good folks over at PADL Software, Ltd., who distribute the open source tools necessary to get Linux (and other Unix variants) to use LDAP in a relatively seamless manner. The relevant tools available from PADL are nss_ldap and pam_ldap.
The nss_ldap module adds LDAP support to the NSS (Name Service Switch) subsystem. NSS abstracts tasks involving information retrieval from various sources like NIS, LDAP, or even local files, so that application developers don't have to write their own routines to do this (thereby causing massive duplication of code). Another benefit, of course, is that administrators centralize the configuration of said information retrieval into a single file: the nsswitch.conf file.
The pam_ldap module adds LDAP support to the PAM subsystem, so that various rules can be enforced by checking validity against an LDAP directory. PAM stands for Pluggable Authentication Modules, and provides an abstraction layer that, through the use of different PAM modules, can enforce various sorts of security measures. Like the NSS system, this allows for centralized administration, and less code-writing for developers who choose to use it.
If you had the option of installing LDAP client tools during your
distribution's installation routine, the PADL nss_ldap and pam_ldap libraries
should already be in place. One good way to tell if you have the PADL tools is
to check for the existence of an /etc/ldap.conf or /etc/nssldap.conf file.
Don't confuse this with /etc/openldap/ldap.conf -- this file is used only by
the OpenLDAP command line tools, like
If you don't have the PADL components installed and want to build from source, the PADL documentation explains how. Either way, from here on, I'll assume that you have both components installed. I'll also assume you have an /etc/ldap.conf file, which is supplied by the nss_ldap tool. Note that on Red Hat/Fedora systems, the pam_ldap and nss_ldap components are both supplied in one RPM: nss_ldap.
Every Linux system I've ever seen uses an /etc/nsswitch.conf file that
tells the system the services to be used for things like uidnumber-to-name
mappings and mount map entry lookups. However, just putting a line like
passwd: files nis ldap into your nsswitch.conf file, which tells
your system to check for (in this case) passwd information using files, NIS, and
LDAP sources, in that order, isn't enough. In fact, it's pretty meaningless unless you
have libraries in place to support talking to these services.
On your Linux system, running the command
locate libnss_ should
return a good number of libraries representing the different services available
to the system. To illustrate how these libraries are used, you might consider
running a command like
strace -o traceout ls -l ~/.bashrc on a
Linux system and perusing the output file. What you'll see, if your head
doesn't explode trying to parse strace output, is that for each service in
nsswitch.conf, there is a corresponding library that gets invoked to carry out
the lookup. In the case where you have
passwd: files ldap,
libnss_files gets called, a lookup takes place on the /etc/passwd file, and if
that doesn't return the data necessary to complete the operation, libnss_ldap
gets called to lookup the same information via LDAP.
The ldap.conf file
Once you have these tools installed, getting a Linux machine to authenticate against an LDAP server is pretty straightforward. If you're using an RPM-based distribution, take heart in knowing that these packages have very few dependencies. If you have OpenSSL and OpenLDAP client libraries installed, a simple
rpm -ivh package will suffice on most machines. If you're building from source, your job is really no harder. These are well-behaved packages that, on Linux systems, put things in the proper place
without any fuss.
You must know only your LDAP server's hostname and the basedn of the directory -- information which is stored in the /etc/ldap.conf file. Of course, the more information you know about how your directory is configured and how the data is laid out, the more you can do to optimize how lookups are performed by the client. The default ldap.conf as distributed by the PADL folks is chock full of useful commentary on all the changes you can make to the file.
Here's an example ldap.conf file (with comments removed) very similar to one found on some of my test machines:
host ldap.linuxlaboratory.org ldap2.linuxlaboratory.org
This ldap.conf file is fairly thorough. On a simple test machine, in early
stages of testing, the only lines required are the host and basedn lines. The
rest of the lines in this file either implement a security constraint or
optimize performance. Actually, only the
ssl keys are really security measures.
checks to insure that anyone logging into the system using a service that does
LDAP lookups belongs to the
admins group on the server. The
ssl line tells the client to use the start_tls() function call to
bind using TLS to port 389 on the LDAP server. The
lines all tell the client to use a basedn that's different from the default for
different types of searches. For example, the
says that instead of starting at the default basedn (dc=linuxlaboratory,dc=org)
and searching down through the subtrees to find a particular user's entry, just
start searching under the People subtree, which we know ahead of time contains
the user entries. You'll notice
?one tagged on to the end of these
lines. This says to only search one level. That means if I later add subtrees
under "ou=People," they won't be searched for passwd entries.
More on page 2...