LDAP services exist in a TCP/IP context. It's an Internet service that uses daemons, requires an administrator, configuration files and structure. In some ways LDAP resembles a Linux file system with a root, limbs instead of directories, etc. Unlike the directory configuration of an operating system, LDAP is flexible in its structuring. That flexibility translates into a design makeup you can simply create. We call the hierarchical model a Directory Information Tree (DIT). Whoever designs the DIT needs to know something about how to model data.

After this, you may find the subject floating over your head, but stay with me for a while. I have compared a typical information model of LDAP to an organizational chart of an enterprise. For example, the limbs of a DIT often correspond to departments referred to in LDAP terms as an organizational unit (ou). The head or root of the tree corresponds to an organization's Internet domain name. We call that a domain component (dc).

If you have had the pleasure of constructing your own directory server, then you know we start with a root that looked like this:

dc=examle,dc=org. 

If you wanted to set up a department called accounting, your name space would look like this: 
ou=accounting,ou=people,dc=example,dc=org. 

That seems a cumbersome, odd and confusing way to name entries in your directory. So, now you know. LDAP as a subject in the open source space requires familiarity and even mastery of a significant body of knowledge. Novell and Microsoft have simplified the design and management of LDAP using eDirectory and Active Directory.

Like many subjects in the various areas of Linux administration you will run into jargon and terminology unique to the application. Rather than attempt to explain every concept and nuance of LDAP's terms, let’s use a chart that you can reference as you begin to see DITs in practice.

The originators of LDAP Tim Howes, Steve Kille and Wengyik Yeong set up a data model arranged hierarchically. At the top of their DIT they depicted their directory root identified by server name. You can see an early model used in the explanation of LDAP:

                              |
                         dc=servername, 
                         dc=yourdc, 
                         dc=com
                              |
                              |
                            /   \
                           /     \
                          /       \
                         /         \
                ou=Department   ou=Corporate
                       /             \
                      /               \
               cn=Jeff Skilling        cn=Ken Lay

In this simplified example, the root of the DIT contains domain components. Below the root you can see the organizational units then the people that populate each ou. In this case, Jeff and Ken (no relation) are the users. They use the notation of cn for their name space. CN stands for common name.

What if you wanted to build a simple white page directory for people in an organization that had several departments such as executives, human resources, accounting, IT, sales, shipping, etc. You would typically create an organizational unit for each department and then put users in each department. You could also create a DIT based on geographic components like New York, Seattle, Hong Kong, Paris, etc. The geographic DIT could also have organizational units under other organizational units.

We might want to call each geographical unit a site and build departments within each site. So, you could have a site called New York and a department called accounting with an organizational unit below that called payroll or accounts payable.

Now, you need to populate the directory. Using OpenLDAP, for example, you need to create a text file called a Lightweight Directory Interchange Format (LDIF) file to create entries in your directory. You also will use commands to add the entries to your directory. Let’s peak at this some of this.

First, here’s the format of the file you would use to create an ou:

dn: ou=people,dc=example,dc=org
ou: people
description: All employees
objectClass: organizationalUnit

dn: ou=auth,dc=example,dc=org
ou: auth
description: services
objectClass: organizationalUnit

On the first line you have what we call a distinguished name (dn). In this case the people organizational unit’s name space is

dn: ou=people,dc=example,dc=org

You would use this notation to create any ou.

To put this data model into the directory, you would use a command line expression such as:

># ldapadd -x -D "cn=people,dc=ldap,dc=example,dc=org" -W -f ou.ldif
Enter LDAP Password:
adding new entry "uid=People,ou=people,dc=example,dc=org"
>#

Now, someone may attempt to convince you that using ldif files and complex command line statements is cool. But, I’m not buying it. If you want to add a user, for example, your LDIF file might look like this:

dn: ou=it,ou=people,dc=example,dc=org
ou: it
description: Information Technology
mail: it@example.org
maildrop: adelstein@example.org
objectClass: CourierMailAlias
objectClass: organizationalUnit

dn: ou=staff,ou=people,dc=example,dc=org
ou: staff
description: Knowledge Workers
mail: staff@example.org
maildrop: staff@example.org
objectClass: CourierMailAlias
objectClass: organizationalUnit

dn: ou=marketing,ou=people,dc=example,dc=org
ou: marketing
description: Sales
mail: marketing@example.org
maildrop: marketing@example.org
objectClass: CourierMailAlias
objectClass: organizationalUnit

If you only had to model your directory one time, you might consider using complex data objects as a necessary evil. But, that’s not the case. Anytime you need to add, change or delete users or move them from one department to another, you have to use this somewhat archaic method.

I can understand the necessity of using the methods above eight or ten years ago, but not today. Tools exist to help you and in a commercial context, you might find the simplicity of modeling a directory surprising.

In the next installment, we’ll stay with the command line model and build a SMB directory. You’ll find this useful, especially if you would like to create a samba infrastructure.

Until then, you might look around again at the documentation for LDAP on the web.