This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature

SysAdmin to SysAdmin: Linux as an LDAP client

By Brian Jones on March 24, 2004 (8:00:00 AM)

Share    Print    Comments   

LDAP software vendors seem to spend most of their efforts focusing on the functionality of the server. As a result, some client platforms leave a lot to be desired in terms of functionality and ease of use. Luckily, Linux doesn't suffer from many of the deficiencies of other operating systems where LDAP is concerned. In this article, we'll discuss how to make effective use of an LDAP server from your Linux desktop. 

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 ldapsearch and ldapmod.

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
base dc=linuxlaboratory,dc=org
pam_filter objectclass=posixAccount
pam_groupdn cn=admins,ou=Group,dc=linuxlaboratory,dc=org
pam_member_attribute memberuid
nss_base_passwd ou=People,dc=linuxlaboratory,dc=org?one
nss_base_shadow ou=People,dc=linuxlaboratory,dc=org?one
nss_base_group ou=Group,dc=linuxlaboratory,dc=org?one
nss_base_netgroup ou=Netgroup,dc=linuxlaboratory,dc=org?one
ssl start_tls
pam_password md5

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 pam_groupdn and ssl keys are really security measures. pam_groupdn 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 nss_base_* lines all tell the client to use a basedn that's different from the default for different types of searches. For example, the nss_base_passwd line 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...

 

Share    Print    Comments   

Comments

on SysAdmin to SysAdmin: Linux as an LDAP client

There are no comments attached to this item.

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya