Top Five Open Source Packages for System Administrators
Pages: 1, 2

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:

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:

• 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.