LDAP Series Part VI - Directory Service Modeling

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:


If you wanted to set up a department called accounting, your name space would look like this: 

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:

                            /   \
                           /     \
                          /       \
                         /         \
                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.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.


pastakare's picture

I admire the valuable information you offer in your articles. I will bookmark your blog and have my children check up here often. I am quite sure they will learn lots of new stuff here than anybody else!

I admire the valuable

pastakare's picture

I admire the valuable information you offer in your articles. I will bookmark your blog and have my children check up here often. I am quite sure they will learn lots of new stuff here than anybody else!

Very nice LDAP rundown

ed14's picture

Very nice LDAP summary. Dugg!

Ed | FUF Chairs

LDAP rocks, plus questions

Jesus Sahagun's picture

I've used LDAP on a server I've put on the office, but I've been having problems authenticating VSFTPD users with LDAP, can you direct me to a tutorial or some docs. I've searched google a lot and I couldn't find any "good" tutorials for CentOS.


LDAP DIT structures

PJ's picture

There's no rule to DIT structures in any LDAP implementation. Remember that LDAP is an access protocol and has nothing to do with the storing, managing or manipulating of the data. It's merely a method to access that data.

Storing data within your Directory Services (DS) model should be well thought-out. There's no one design-fits-all yet there's something that's quite near it for large enterprises or those companies looking to do identity management/provisioning etc. That's the hub-spoke design with an identity 'vault' at the center with connections (or federation) to disparate systems.

Never use OUs where attributes will do -- no need to divide your user accounts in differing sub-tree searches but rather write your applications to query one sub-tree searching for specific attributes (ie, instead of ou=acct,ou=example,o=org, try searching ou=users,o=org for a specific attribute like dept? why not extend the schema and include this information?

Virtual directories will also shape your thinking around how to design and setup directories as more and more applications will use virtual directory services (and/or federation) for access and control.

I could write a book . . . :)

DIT Structure and Enterprises

-jim's picture

The reality of Identity Management, certainly in LARGE organizations, is an collection of identity data-stores with a methodology of keeping them in sync.

Why? Because vendors do NOT cooperate. Almost every vendor, including the Identity Management providers do not allow "their" user data store and authentication authority to be outside their application. As in AD can not use an external LDAP source for authentication and IBM Notes, Oracle data bases will not allow it either.

This is also the case in the OpenSoruce community to a large extent.

Typically a central "Identity Vault" is synchronized to other data stores based on the authoritative source for the particular data element.

Usually rather than organize the DIT to match the structure of the organization, attributes are valued as to be able provide many views of the organization.

Views may typically represent physical locations or organizational structure.

GQ and google for Ldap utilities

Anonymous's picture

Don't think GQ quite fits the requirement. Google doesn't provide any hints to the kinds of tools needed as pointed out in the article.

Identity management is a growing field for enterprises to small to medium size businesses. OSS doesn't seem to have anything to meet the specifications of identity management.

This puts Linux in a bit of a disadvantage. I just don't think we have the development community any more to keep up.


OpenID, Kerberos and LDAP

Anonymous's picture

The open source community should merge openid, kerberos and ldap. In the end you get something like MS Active Directory

I think you have never used

Anonymous's picture

I think you have never used GQ. I do *all* what the article describes with it, no sweat.

yes I have

linux user's picture

I think you have never used GQ. I do *all* what the article describes with it, no sweat.

How would you know?

>> I think you have never

Anonymous's picture

>> I think you have never used GQ. I do *all* what the article describes with it, no sweat.

> How would you know?

I know because of your answer. With GQ I do *all* what the article says. If you say it is not possible, then the only conclusion I can have is that you do not use it. Period.

abstracted layer

Anonymous's picture

In response to this and previous article, we need low cost products to abstract out of the ldap the departments, resources and people, and then organize them the way we want. Its not easy to closely model the DIT to the organization and answer business requirements. Departments, resources, people are created and modified on the fly and so are their relationships and management. I look at LDAP as a place to store the data for departments, resources, and people in a fairly simple DIT. Then desire an application to organize that data in an abstract way, and consequently store its data in an LDAP as well.

"In response to this and

Sam Stainsby's picture

"In response to this and previous article, we need low cost products to abstract out of the ldap the departments, resources and people, and then organize them the way we want."

I'm working on it, if you're OK with Plone at least:


The ssIdManagement Plone product allows ordinary computer users to manage contacts, personnel, organisational structures and organisation-wide authentication using an intuitive Plone web interface.

This package is a generic tool where contacts could include staff, volunteers, donors, customers, contacts in other organisations ... just about anything. Similarly, organisational structures might include offices, committees, departments, branches, households, and so on.

Optionally, your identity data can be periodically exported to an LDAP server to provide enterprise-quality directory and authentication/authorisation services throughout your organisation. Such services might be used to manage membership and access to web sites, mailing lists, chat servers, computer accounts, and many other type of system through the standards-based LDAP protocol.


Graeme's picture

Just a little note about your project. I've been involved with IdM for quite some time and your project looks very promising and fills a significant gap in open-source, however I think it could be better if you integrate with some other software and concentrate only on the user interface. That is, it would be best if you drop the ldap support and instead use a DB for the backend. Then you can target the actual use as ssidm with something like penrose

to provide ldap and so much more. This would of course require docs on the integration and cooperation with the penrose team but it would save reinventing the wheel.

thank you for

sinau's picture

use any of the gui ldap clients around

Anonymous's picture

no need to mess around with ldif files unless you want to. I use gq (http://www.gq-project.org/), but there are lots of them. Google a bit and you will find them.