Directory Tree Design

Michael Donnelly

At first glance, designing the directory topology of an LDAP server may seem like an daunting task. With a little forethought, though, the process can be relatively straightforward. In this article, we'll walk through each of the topics you'll need to consider:

This is the second in a series of articles for sendmail.net on the topic of LDAP. The series as a whole will walk you from "just looking into it" through the entire process of deploying an LDAP-based set of directory-enabled applications and services. An archive of other articles in this series can be found at http://www.ldapman.org/articles. You might also want to take a look at parts one and two of "An Introduction to LDAP," which can also be found on ldapman.org.

What Is a Directory Tree?

Simply put, a directory tree is nothing more than an organized way to provide containers for storing different types of information. Think of it as a filing system for your data.

LDAP directory servers store their information hierarchically, not unlike a UNIX file system. The hierarchy provides a method for logically grouping (and subgrouping) certain items together. These groupings can be useful in a number of ways:

Consider this example of a very simple directory tree. I'll leave off any LDAPisms for now so we can focus on the tree itself.

At the top we have the root, the starting point for every directory tree. Beneath the root are two categories, each with two subcategories. Note that in the case of Employees we're grouping by department, while for Customers we're grouping geographically. There's no restriction as to how a given group is subgrouped. Though I've shown just two groups per level here, your directory may have as many groupings of data as you need, at any level of the directory.

Choosing Your Directory's Base DN

Let me start by saying that there is no one correct way to set up a directory structure. The design you choose may look similar to others that you see, and then again it may not. You'll want to measure the design of your directory tree by one main criterion: Does it meet your current and projected needs efficiently? If so, you're doing the right thing.

The directory's top level, referred to above as the root of the directory tree, is also known as the base. The name of that base is the Base Distinguished Name, or base DN. In principle, it's up to you to choose the format for your base DN; I'm going to recommend a base DN that follows what's currently the most popular format. (You may want to take this opportunity to refresh your memory on alternate base DN formats.)

Back in 1998, RFC 2247 laid the foundation for encoding DNS domain names in LDAP (and X.500) distinguished names. Since then, more and more installations have made this format their choice. If you're planning to integrate with Microsoft's Active Directory, this is the only format you can use, so don't bother choosing - Redmond made the choice for you.

The format's very simple. Let's say your company's Internet presence is (or will be) foobar.com. RFC 2247 translates this DNS domain into the following DN:

dc=foobar, dc=com
The "dc" stands for "Domain Component." Note that each portion of the DNS name is represented in order.

So what should your base DN be? Assuming your company's Internet presence ends in .com, your best option is dc=com. If your Internet presence ends in .net, use a base DN of dc=net. Get the idea? If your company is not now and never ever will be on the Internet, you can use dc=local instead.

Beneath the base DN, you'll just have a single entry that corresponds to the rest of your DNS domain name. For example, the top levels of foobar.COM would look like this:

Let's say foobar.com is destined to merge with wocket.com and with gizmo.com. No problem! Thanks to your prescience, your directory structure is ready to accomodate this stunning shift in your company's fortunes. Simply add the dc=wocket and dc=gizmo entries under dc=com. The top levels of your directory tree will now look like this:

An Example of a Directory Tree

The better your initial directory structure, the less likely it is to need revamping later. In general, you'll want to design your directory so individual entries won't have to be moved from one tree to another. You'll probably find that a fairly shallow structure works best, one where each branch of the tree contains objects that are unlikely to move much, if at all. Consider the following, a directory tree for the fictional foobar.com. They've taken about a year rolling out their LDAP directory in stages, gradually basing more and more services on LDAP along the way.

Note that each branch is of the form ou=<name>. OU stands for Organizational Unit. Back in the X.500 days, OUs were used to represent organizations internal to your company. While you could still do that today, you'd have to reorganize your directory tree every time the company's departmental structure changed, and why give yourself extra work? Instead, foobar took the easy approach: they store who works for whom, departmental info, and similar data in each employee's LDAP entry. They're still storing the same data, but it's a lot less work.

ou=employees
All of foobar.com's employees are listed here. Foobar has suppressed the desire to break this into subgroups of any type, since the subgrouping schemes would inevitably change over time: people change positions, departments, and even move from continent to continent. Instead, the location, department, and company division information for each employee is stored in the employee's LDAP entry, along with email, public HR information, and NIS info.

ou=ITaccounts
When foobar.com consolidated NIS password and mail routing information into LDAP, there was a bit of a quandary. What do you do about accounts like "root", "nobody", "www", and so on? IT accounts like these share many of the same attributes as employee accounts (password, uid and gid information, email addresses, and so on) but are fundamentally different from people. (When was the last time you wanted to look up the phone number of "root"?) To keep this data distinct from employee information, they created a special-purpose OU just to hold accounts of this type. LDAP access controls were then added to keep non-IT personnel from reading the data in this location.

ou=customers
Foobar.com has chosen to push their customer contact information into the LDAP directory. This allows any employee to query the directory to find a customer's sales rep, address, support contact information, and so on. In this case, it's unlikely that a customer will move from one continent to another.

As the company grows, they may wish to set up replication of this information between regionally located servers. Because they've broken the customer contact information into subgroups, they'll be able to tailor the replication to the needs of salespeople at each site.

ou=locations
Ever wonder what the address of your New York office is? Or the phone number in the "Coffee Stain Conference Room"? Ever been told to meet at 10 am in the "Scenic View" meeting room, a room you had no idea how to find?

Well, that doesn't happen to the folks at foobar.com. They store information about all their offices, conference rooms, and similar things in their LDAP directory. The company's LDAP-based phone book can then pull up all this information quickly and easily.

ou=devices
Foobar has also decided to store information about their computers, printers, and other computing devices in LDAP. This lets their system administrators store host name, IP address, MAC address, primary user or group, asset tag, serial number, make and model, OS name and version, location, and description info for every device on their network in one place.

A custom Web GUI allows system administrators and the company's asset manager to enter, modify, and query this information. A set of custom scripts is used to generate DNS and NIS host maps directly from LDAP. Asset management tools are used to automatically update hardware information on a periodic basis, thus keeping this information up to date with a minimum of effort.

But why lump all the routers, switches, printers, PCs, Macs, and UNIX systems into one OU? Because they all share the same types of information. A UNIX server is vastly different from a printer, but the type of information stored for each is essentially the same. To facilitate a query like "Give me a list of all the Windows PCs," they simply query by OS Name.

OK, but how about "Give me a list of all the laptops"? Foobar.com has implemented a number of custom LDAP attributes to let them track a "Machine Class" and "Machine SubClass" attribute for each device, to provide the degree of granularity they require. "Machine Class" values include Netgear, Printer, Windows, Mac, UNIX. "Machine SubClass" values include router, switch, inkjet, laser, desktop, laptop, workstation, server. The combination of class and subclass information provides the flexibility and accuracy to track any networking device in a number of ways.

Planning Your Directory Topology

Now that we've looked at an example, you're probably wondering how to design your own directory. In the example listed above, foobar.com is using five broad categories, with ou=customers broken up into subgroups. (Remember, this is just an example; it certainly isn't the best design for every company.) In practice, you'd probably also want additional categories to handle NIS group information, mailing list information, and so on.

So which OUs are right for you? I leave the design process to you. After all, you're building your LDAP server to meet the specific needs of your own situation. The example above should help you get a feel for how you want to organize your data. Here's a list of broad guidelines to help you through the process:

Here are some broad categories of data objects you might consider storing in an LDAP directory. Depending on your needs, each might warrant a separate OU.
  • Employee information
  • Customer information, both for new leads and for established customers
  • Phone numbers and descriptions of local restaurants, taxi services, and so on
  • Conference rooms, office location information, and so on
  • LCD projectors, flip charts, and other portable "meeting room" gear
  • Computers: desktops, laptops, servers, printers, network gear
  • Mailing lists
  • NIS group map
  • NIS netgroup map
  • Seems easy, right? But don't get caught by items like these:
  • NIS password map. This map stores information that applies to individual employees. You can parse this file and store each user's login name, password, uid and gid numbers, login shell, and home directories as user-specific attributes of individual LDAP entries in ou=employees and ou=ITaccounts.
  • Organizational charts. Org charts essentially reflect each employee's job title, manager, department, and/or business unit. Simply parse through your org chart and assign the pertinent information to each employee's individual record. You can always derive the company's org chart from the chain of managers stored in the directory.
  • NIS aliases map. The aliases map contains many different types of information. Mail routing information and alternate email addresses for an individual should all be stored as part of each employee's LDAP entry. Mailing list information could be stored in its own OU, et cetera. I'll have an entire article devoted to storing email information in LDAP, so please be patient.
  • That's it for now. I hope you've found this article useful. If you have comments or questions, send email to donnelly@ldapman.org.

    michael donnelly
    9 may 2000