ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Essential System Administration, 3rd Edition

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:

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.

In This Series

Number Five: Amanda
The countdown begins with Amanda, an enterprise backup utility.

Number Three: GRUB
The countdown continues with GRUB, the GRand Unified Bootloader.

Number Two: Nagios
The countdown continues with Nagios, a feature-rich network monitoring package.

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
 
Distinguished name (key field) and object classes for this directory entry.
sn: Frisch 
cn: Daphne Frisch
telephoneNumber: 555-1212 
userPassword: {crypt}meeoooowww 
description: Toy chaser and purrrring fuzz ball
 
Attributes from the person object class.
ou: Pets 
title: HRH 
street: 125 N. Main Street
postOfficeBox: 4224
st: CT 
postalCode: 06512 
facsimileTelephoneNumber: 888-555-1212
 
Attributes from the organizationalPerson object class.
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 
 
Attributes from the inetOrgPerson object class.

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.

Essential System Administration

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:

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:

Object Class Main Purpose OpenLDAP Schema File
posixAccount Unix user account data nis.schema
shadowAccount Unix password/aging data nis.schema
account Organizational unit and host attributes cosine.schema
person Basic personal data. core.schema
organizationalPerson Address, phone data core.schema
inetOrgPerson Employee related data inetorgperson.schema
ipHost and device Host-based login access control nis.schema
groupOfUniqueNames Host-based login access control core.schema

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:

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

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.


Return to ONLamp.com.

Copyright © 2009 O'Reilly Media, Inc.