Putting OpenLDAP to Work

Information inside an LDAP directory is stored in "entries". Each entry is a collection of attributes that have a globally unique Distinguished Name (DN), which contain a type and one or more values. An example of a type would be "mail", the value of which is an e-mail address. On the LDAP server, this information is arranged in a tree-like fashion from top to bottom. Typically, at the top of this tree you define the country (c=US) or domain (dc=com). Below this, we might have an organization (o=Acme) and organizational units (ou=People). An organizational unit can contain all your Human Resource employees, printers in a building or any other kind of category. In turn, each attribute contained under the organizational unit is controlled by an objectClass. The value of each objectClass attribute obeys a schema or set of rules that add attribute capabilities to your directory. For example, the inetorgPerson objectClass requires the sn (surname) and cn (common name) attributes but also allows optional entries like mail, telephoneNumber and localityName (see example below).

Designing the directory structure is one of the most important aspects of LDAP. We are going to use a simple example, which we will access with Netscape Address Book. Suppose there is a company called Acme (o=Acme), which is located in several states throughout the US (c=US). Acme wants to implement a small address book server for all its employees. We start out with a simple organizational DN.

        dn: o=Acme, c=US

All of Acme's organizations and attributes will be stored under this DN, which is unique to the directory stored on the server. Acme wants to organize its employees under two departments, Managers (ou=Managers) and Employees (ou=Employees). The resulting relative distinguished names (RDN), meaning relative to the top DN, are

        dn: ou=Managers, o=Acme, c=US
        dn: ou=Employees, o=Acme, c=US

Below you will see the hierarchical structure forming, with US at the top, down to our Management organizational unit and, thus, each individual employee. Acme is just starting out, so let's begin by constructing one manager and two employee entries.

        dn: cn=Jason H. Smith, ou=Managers, o=Acme, c=US
        dn: cn=Ray D. Jones, ou=Employees, o=Acme, c=US
        dn: cn=Eric S. Woods, ou=Employees, o=Acme, c=US

To reference the common name entry Jason H. Smith, LDAP starts by taking the RDN cn=Jason H. Smith, and concatenating the previous parent entries till it reaches the top level DN.

   cn=Jason H. Smith
        + ou=Managers
                + o=Acme
                        + c=US
                                -> cn=Jason H. Smith, ou=Managers, o=Acme, c=US

Now that we have the basic structure for our directory, importing the data is next. We will place all this information into an LDIF file. LDIF is the default file format for importing directory information. You can easily write Perl scripts to automate the creation of LDIF data files from system files such as /etc/passwd, NIS or you can grab the excellent migration scripts from the resource sidebar below.

The listing shows our test data, save the information as testdata.ldif. More information on this file format can be found in the LDIF man pages, sections five and eight.

Acme DN, which must exist in the directory before we can add any organizational units

dn: o=Acme, c=US
objectClass: organization

The o attribute is required here

o: Acme

Manager organization unit DN. This entry must exist in the directory before we can add any managers.

dn: ou=Managers, o=Acme, c=US
objectClass: organizationalUnit

The ou attribute is required here

ou: Managers

The first manager DN

dn: cn=Jason H. Smith, ou=Managers, o=Acme, c=US
objectClass: inetOrgPerson

Both cn and sn are required attributes

cn: Jason H. Smith
sn: Smith

But these are optional attributes

telephoneNumber: 111-222-9999
mail: headhauncho@acme.com
localityName: Houston

We can define another organizational unit

dn: ou=Employees, o=Acme, c=US
objectClass: organizationalUnit
ou: Employees

And add employees below

dn: cn=Ray D. Jones, ou=Employees, o=Acme, c=US
objectClass: inetOrgPerson
cn: Ray D. Jones
sn: Jones
telephoneNumber: 444-555-6767
mail: jonesrd@acme.com
localityName: Houston
dn: cn=Eric S. Woods, ou=Employees, o=Acme, c=US
objectClass: inetOrgPerson
cn: Eric S. Woods
sn: Woods
telephoneNumber: 444-555-6768
mail: woodses@acme.com
localityName: Houston