Top Five Open Source Packages for System Administrators by Æleen Frisch, author of Essential System Administration, 3rd Edition 10/17/2002

This is the second installment of a five-part series in which I introduce my current list of the most useful and widely applicable open source administrative tools. These tools can make your job easier no matter what Unix operating system your computers run.

#4: LDAP

LDAP has been a hot new topic in system administration for several years now. LDAP provides a directory service which can be used for storing and querying information about the individuals in an organization (e.g., employees). The range of information that can be made available in this way is quite broad: traditional telephone or other institutional directory data (office location, phone numbers, and the like), Unix user account data, more personal data such as home telephone numbers and photographs, along with any other site-specific data that may be appropriate. In this installment, we'll look at the services that LDAP can provide.

LDAP, as its fully expanded name, Lightweight Directory Access Protocol, indicates, is a protocol that supports a directory service. A directory service functions somewhat like a database, but it differs from traditional relational databases in several ways:

• It is optimized for reading; adding and updating entries may be expensive.

• It provides advanced searching features.

• Its fundamental data structures, collectively known as the schema, can be extended according to local needs.

• It adheres to published standards to ensure interoperability among vendor implementations, specifically, a series of RFCs.

• It takes advantage of distributed storage and data replication techniques, allowing it to scale efficiently.

Because of these advantages and others, LDAP is replacing NIS as the enterprise user account and authentication of choice.

In order to emphasize these differences with respect to standard relational databases, different terminology is used to name a directory service's data structures: records are referred to as entries, and each field within a record is known as an attribute.

Note: Although the term LDAP is used very loosely in common practice, it actually refers only to the protocol by which data stored in the directory is accessed (implemented in a daemon). The actual database capabilities are provided by a separate back-end program or package.

LDAP was first implemented at the University of Michigan in the early 1990's. There are many commercial LDAP servers available. In addition, OpenLDAP is an open source implementation of LDAP based on the work done at Michigan. OpenLDAP is used by default on Linux and BSD operating systems, and it can be used on most Unix systems. At some points, we will be using it as an example.

About Schema

LDAP objects are standardized in order to provide interoperability with a variety of directory services servers. An LDAP schema defines the list of possible entry types, known as object classes,along with the attributes associated with each one. Schema definitions are stored in files. For OpenLDAP, the schema files are located in the /etc/openldap/schema subdirectory.

The attributes themselves are defined in terms of their data type and format, comparison method, and the like. Within an object class, attributes can be required or optional. The same attribute can be part of more than one object class.

Object classes are arranged hierarchically, with the top object class at the root of the tree. First level object classes are children of this class, and lower level object classes are their descendants. Child classes automatically contain all the attributes of the parent class.

A directory entry can be in multiple object classes, as in the following example record for Daphne Frisch:

dn: cn=Daphne Frisch,ou=Pets,dc=ahania,dc=com 
objectClass: top 
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson

sn: Frisch 
cn: Daphne Frisch
telephoneNumber: 555-1212 
userPassword: {crypt}meeoooowww 
description: Toy chaser and purrrring fuzz ball

ou: Pets 
title: HRH 
street: 125 N. Main Street
postOfficeBox: 4224
st: CT 
postalCode: 06512 
facsimileTelephoneNumber: 888-555-1212

departmentNumber: 14 
employeeType: permanent 
givenName: Daphne 
initials: DF 
jpegPhoto: daphne.jpg 
audio: daphne.wav 
homePhone: 555-2121 
pager: Opening the toy cabinet 
preferredLanguage: Fenglish 
userCertificate: certs/df_cert.pem 

The data format in the example record is known as LDIF (LDAP Data Interchange Format). It is organized as a series of attribute and value pairs (colon-separated). For example, the attribute telephoneNumber has the value 555-2121. The various attributes are colored to indicate which object class they come from.

The Ldap Schema Viewer provides a very convenient interface for exploring standard LDAP schema objects. One of the most flexible features of LDAP is that the schema is extensible. Sites can add object classes and attributes are desired to fulfill their unique needs.

Related Reading Essential System Administration Tools and Techniques for Linux and Unix Administration By Æleen Frisch

LDAP Directory Structure

LDAP directories are logically tree structures, and are typically rooted at a construct corresponding to the site's domain name, expressed in a format like this one:

dc=ahania,dc=com

Each component of the domain name becomes the value for a dc (domain component) attribute, and all of them are collected into a comma separated list. This is known as the directory's base, corresponding in this case to ahania.com.

Such a list of attribute=value pairs is the method for referring to any location (entry) with the directory. (Note that spaces are not significant between items.)

Let's look again the first line of Daphne's directory entry:

dn: cn=Daphne Frisch,ou=Pets,dc=ahania,dc=com

This line specifies this entry's distinguished name (dn). This attribute functions as its unique key within the directory's database. It is constructed as a comma-separated list of attribute-value pairs. In this case, the entry is for common name "Daphne Frisch," organizational unit "Pets" in the example directory for ahania.com.

The first component of the dn is known as the entry's relative distinguished name (rdn). In our example, that would be cn=Daphne Frisch. It corresponds to the location within the ou=Pets,dc=ahania,dc=com subtree where this entry resides. An rdn must be unique within its subtree just as the dn is unique within the entire directory.

Here is a simple representation of the directory tree in which successive (deeper) levels are indicated by indentation:

dc=ahania,dc=com
    ou=Humans,dc=ahania,dc=com 
        cn=Jerry Carter,ou=MyList,dc=ahania,dc=com 
        cn=Rachel Chavez,ou=MyList,dc=ahania,dc=com 
        more people ...
    ou=Pets,dc=ahania,dc=com  
        cn=Daphne Frisch,ou=Pets,dc=ahania,dc=com
        cn=Lyta Frisch,ou=Pets,dc=ahania,dc=com
        cn=Susan Frisch,ou=Pets,dc=ahania,dc=com
        cn=Talia Frisch,ou=Pets,dc=ahania,dc=com

The directory is divided into two organization units, each of which has a number of entries under it.

Using LDAP for User Accounts

If you want to use LDAP for user account data and user authentication, you'll need to:

• Incorporate user account and related configuration information into the directory service schema.
• Migrate the current user account data from the standard files (or the NIS facility).
• Configure the PAM user authentication facility to consult the LDAP directory.

Object classes for User Accounts

In the case of the first point, you can use the standard objects already defined for this purpose. These are the object classes you might choose to use for user account directory entries:

The object classes in the orange rows will be used by virtually all sites. One or more of those in the yellow rows may also be used for user account entries, depending on local needs. The classes in the pink rows are used when host-based login access control is desired, i.e., specifying which users are allowed to login to each host.

Migrating Existing Account Data

Moving existing user account data into an LDAP directory is very easy if you take advantage of the open source migration tools provided by PADL software. These are a series of Perl scripts which extract the required data from its current location and create corresponding directory entries. The scripts can be configured to automatically insert the appropriate entries into the LDAP directory or to create text files in LDIF format which can be examine, potentially modified, and eventually imported manually.

Configuring User Authentication

Using directory entries as the source for user authentication data requires two additional open source modules developed by PADL software: nss_ldap and pam_ldap.

The nss_ldap module provides an interface to the standard name service switch file, /etc/nsswitch. It allows LDAP to be an option specified in the entries in this file. For example, these two nsswitch entries tell the operating system to look in the conventional configuration file first for user account information and then to consult the OpenLDAP server:

passwd: files ldap
shadow: files ldap

The ldap keyword is what is used to refer to the OpenLDAP server. The distinguished name of the organizational unit containing the user accounts is specified in the LDAP server's configuration file.

The pam_ldap module is used by the PAM facility to use LDAP as the source of user authentication data and other user account controls. It can be placed in a PAM stack in the normal way, as in this example:

auth      required    /lib/security/pam_securetty.so
auth      required    /lib/security/pam_nologin.so
auth      sufficient  /lib/security/pam_ldap.so
auth      required    /lib/security/pam_unix.so
account   sufficient  /lib/security/pam_ldap.so
account   required    /lib/security/pam_unix.so
password  sufficient  /lib/security/pam_ldap.so
password  required    /lib/security/pam_unix.so  strict=false
session   required    /lib/security/pam_unix.so  debug 

In general, the pam_ldap module is simply inserted into the stack above the normal authentication module (here, pam_unix). This module also allows you to restrict a user to a specified list of hosts and/or to restrict access to an individual host to a specific list of users.

Other LDAP Features

In the space available, we've only touched the surface of LDAP's capabilities. These are among the most important of its other features:

• Complex querying abilities, including via graphical open source tools (e.g., GQ)

• Very fine grained data access control (down to an individual attribute basis)

• Secure authentication to the LDAP server

For more information about LDAP and OpenLDAP, consult the following:

• Chapter 6 of Essential System Administration, 3rd Edition.
• My three-part column in Linux Magazine (January-March, 2002): Part I, Part II, Part III.
• OpenLDAP project website
• PADL open source software
• Web schema browser
• Thesis Comparing LDAP Implementations

That's all for now. I'll be posting the next item in the list in two weeks.

Æleen Frisch has been a system administrator for over 20 years, tending a plethora of VMS, Unix, Macintosh, and Windows systems. If you liked this article and would like to receive the free ESA3 newsletter, you can sign up at http://www.aeleen.com/esa3_news.htm.

O'Reilly & Associates recently released (August 2002) Essential System Administration, 3rd Edition.

• Sample Chapter 11, Backup and Restore, is available free online.

• You can also look at the Table of Contents, the Index, and the Full Description of the book.

• For more information, or to order the book, click here.

Return to ONLamp.com.

Copyright © 2009 O'Reilly Media, Inc.