Previous     Contents     Index     DocHome     Next     
iPlanet Directory Server Deployment Guide



Chapter 4   Designing the Directory Tree


Your directory tree provides a way to refer to the data stored by your directory. The types of information you store in your directory, the physical nature of your enterprise, the applications you use with your directory, and the types of replication you use shape the design of your directory tree.

This chapter outlines the steps for designing your own directory tree. It includes the following sections:



Introduction to the Directory Tree

Your directory tree provides a means for your directory data to be named and referred to by client applications. Your directory tree interacts closely with other design decisions, including the choices available to you when you decide on how to distribute, replicate, or control access to your directory data. Taking the time to design your directory tree well before deployment saves headaches later if you find it inadequate after you have launched your directory.

A well-designed directory tree provides the following:

  • Simplified directory data maintenance

  • Flexibility in creating replication policies and access controls

  • Support for the applications using your directory

  • Simplified directory navigation for directory users

The structure of your directory tree follows the hierarchical LDAP model. Your directory tree provides a way to organize your data, for example, by group, by people, or by place. It also determines how you partition data across multiple servers. For example, each database needs data to be partitioned at the suffix level. Without the proper directory tree structure, you may not be able to spread your data across multiple servers as you would like.

In addition, replication is constrained by what sort of directory tree structure you use. You must carefully define partitions for replication to work. If you want to replicate only portions of your directory tree, you need to take that into account during the design process. If you plan to use access controls on branch points, that is also a consideration in your directory tree design.



Designing Your Directory Tree


This section guides you through the major decisions you make during the directory tree design process. The directory tree design process involves the following steps:

  • Choosing a suffix to contain your data

  • Determining the hierarchical relationship among data entries

  • Naming the entries in your directory tree hierarchy

The following sections describe the directory tree design process in more detail.


Choosing a Suffix

The suffix is the name of the entry at the root of your tree, below which you store your directory data. Your directory can contain more than one suffix. You may choose to use multiple suffixes if you have two or more directory trees of information that do not have a natural common root.

By default, the standard iPlanet Directory Server deployment contains multiple suffixes, one for storing data and the others for data needed by internal directory operations (such as configuration information and your directory schema). For more information on these standard directory suffixes, see the iPlanet Directory Server Administrator's Guide.


Suffix Naming Conventions

All entries in your directory should be located below a common base entry, the root suffix. Consider the following recommendations for naming the root directory suffix:

  • Globally unique

  • Static, so it rarely changes, if ever

  • Short, so that entries beneath it are easier to read on screen

  • Easy for a person to type and remember

In a single enterprise environment, choose a directory suffix that aligns with a DNS name or Internet domain name of your enterprise. For example, if your enterprise owns the domain name of siroe.com, then you should use a directory suffix of:

dc=siroe,dc=com

The dc (domainComponent) attribute represents your suffix by breaking your domain name into its component parts.

Normally, you can use any attribute that you like to name your root suffix. However, for a hosting organization, we recommend that the root suffix contain only the following attributes:

  • c (countryName)

    Contains the two-digit code representing the country name, as defined by ISO.

  • l (localityName)

    Identifies the county, city, or other geographical area where the entry is located or which is associated with the entry.

  • st

    Identifies the state or province where the entry resides.

  • o (organizationName)

    Identifies the name of the organization to which the entry belongs.

The presence of these attributes allows for interoperability with subscriber applications. For example, a hosting organization might use these attributes to create the following root suffix for one of its clients, Company22:

o=Company222,st=Washington,c=US

Using an organization name followed by a country designation is typical of the X.500 naming convention for suffixes.


Naming Multiple Suffixes

Each suffix that you use with your directory is a unique directory tree. There are several ways that you can include multiple trees in your directory. The first is to create multiple directory trees stored in separate databases served by Directory Server. For example, you could create separate suffixes for the Company22 and the Company44 and store them in separate databases as follows:



The databases could be stored on a single server or multiple servers depending upon resource constraints.


Creating Your Directory Tree Structure

You need to decide whether you use a flat or hierarchical tree structure. As a general rule, strive to make your directory tree as flat as possible. However, a certain amount of hierarchy can be important later when you partition data across multiple databases, prepare replication, and set access controls.

The structure of your tree involves the following steps and considerations:


Branching Your Directory

Design your hierarchy to avoid problematic name changes. The flatter a namespace is, the less likely the names are to change. The likelihood of a name changing is roughly proportional to the number of components in the name that can potentially change. The more hierarchical the directory tree, the more components in the names, and the more likely the names are to change.

Following are some guidelines for designing your directory tree hierarchy:

  • Branch your tree to represent only the largest organizational subdivisions in your enterprise.

    Any such branch points should be limited to divisions (Corporate Information Services, Customer Support, Sales and Professional Services, and so forth). Make sure that divisions you use to branch your directory tree are stable; do not perform this kind of branching if your enterprise reorganizes frequently.

  • Use functional or generic names rather than actual organizational names for your branch points.

    Names change and you do not want to have to change your directory tree every time your enterprise renames its divisions. Instead, use generic names that represent the function of the organization (for example, use Engineering instead of Widget Research and Development).

  • If you have multiple organizations that perform similar functions, try creating a single branch point for that function instead of branching based along divisional lines.

    For example, even if you have multiple marketing organizations, each of which is responsible for a specific product line, create a single Marketing subtree. All marketing entries then belong to that tree.

Following are specific guidelines for the enterprise and hosting environment.


Branching in an Enterprise Environment
Name changes can be avoided if you base your directory tree structure on information that is not likely to change. For example, base the structure on types of objects in the tree rather than organizations. Some of the objects you might use to define your structure are:

  • ou=people

  • ou=groups

  • ou=contracts

  • ou=employees

  • ou=services

A directory tree organized using these objects might appear as follows:




Branching in a Hosting Environment
For a hosting environment, create a tree that contains two entries of the object class organization(o) and one entry of the organizationalUnit(ou) object class beneath the root suffix. For example, the ISP I-Zed branches their directory as follows:




Identifying Branch Points

As you decide how to branch your directory tree, you will need to decide what attributes you will use to identify the branch points. Remember that a DN is a unique string composed of attribute-data pairs. For example, the DN of an entry for Barbara Jensen, an employee of Siroe Corporation, appears as follows:

cn=Barbara Jensen,ou=people,dc=siroe,dc=com

Each attribute-data pair represents a branch point in your directory tree. For example, the directory tree for the enterprise Siroe Corporation appears as follows:



The directory tree for I-Zed, an internet host, appears as follows:



Beneath the root suffix entry, o=i-zed,c=US, the tree is split into three branches. The ISP branch contains customer data and internal information for I-Zed. The internet branch is the domain tree. The groups branch contains information about the administrative groups.

There are some points to consider when choosing attributes for your branch points:

  • Be consistent.

    Some LDAP client applications may be confused if the distinguished name (DN) format is inconsistent across your directory tree. That is, if l is subordinate to o in one part of your directory tree, then make sure l is subordinate to o in all other parts of your directory.

  • Try to use only the traditional attributes (shown in Table 4-1).

    Using traditional attributes increases the likelihood of retaining compatibility with third-party LDAP client applications. Using the traditional attributes also means that they will be known to the default directory schema, which makes it easier to build entries for the branch DN.


    Table 4-1    Traditional DN Branch Point Attributes 

    Attribute Name

    Definition

    c  

    A country name.  

    o  

    An organization name. This attribute is typically used to represent a large divisional branching such as a corporate division, academic discipline (the humanities, the sciences), subsidiary, or other major branching within the enterprise. You should also use this attribute to represent a domain name as discussed in "Suffix Naming Conventions".  

    ou  

    An organizational unit. This attribute is typically used to represent a smaller divisional branching of your enterprise than an organization. Organizational units are generally subordinate to the preceding organization.  

    st  

    A state or province name.  

    l  

    A locality, such as a city, country, office, or facility name.  

    dc  

    A domain component as discussed in "Suffix Naming Conventions".  


    Note A common mistake is to assume that you search your directory based on the attributes used in the distinguished name. However, the distinguished name is only a unique identifier for the directory entry and cannot be searched against.

    Instead, search for entries based on the attribute-data pairs stored on the entry itself. Thus, if the distinguished name of an entry is cn=Babs Jensen,ou=People,dc=siroe,dc=com, then a search for dc=siroe will not match that entry unless you have explicitly put dc: sun as an attribute in that entry.



Replication Considerations

During directory tree design, consider which entries you are replicating. A natural way to describe a set of entries to be replicated is to specify the distinguished name (DN) at the top of a subtree and replicate all entries below it. This subtree also corresponds to a database, a directory partition containing a portion of the directory data.

For example, in an enterprise environment you can organize your directory tree so that it corresponds to the network names in your enterprise. Network names tend to not change, so the directory tree structure will be stable. Further, using network names to create the top level branches of your directory tree is useful when you use replication to tie together different directory servers.

For example, Siroe Corporation has three primary networks known as flightdeck.siroe.com, tickets.siroe.com, and hanger.siroe.com. They initially branch their directory tree as follows:



After creating the initial structure of the tree, they create additional branches as follows:



As another example, the ISP i-zed.com branches their directory as follows:



After creating the initial structure of their directory tree, they create additional branches as follows:



Both the enterprise and the hosting organization design their data hierarchies based on information that is not likely to change often.


Access Control Considerations

Introducing hierarchy into your directory tree can be used to enable certain types of access control. As with replication, it is easier to group together similar entries and then administer them from a single branch.

You can also enable the distribution of administration through a hierarchical directory tree. For example, if you want give an administrator from the marketing department access to the marketing entries and an administrator from the sales department access to the sales entries, you can do so through your directory tree design.

You can set access controls based on the directory content rather than the directory tree. The ACI filtered target mechanism lets you define a single access control rule stating that a directory entry has access to all entries containing a particular attribute value. For example, you could set an ACI filter that gives the sales administrator access to all the entries containing the attribute ou=Sales.

However, ACI filters can be difficult to manage. You must decide which method of access control is best suited to your directory: organizational branching in your directory tree hierarchy, ACI filters, or a combination of the two.


Naming Entries

After designing the hierarchy of your directory tree, you need to decide which attributes to use when naming the entries within the structure. Generally, names are created by choosing one or more of the attribute values to form a relative distinguished name (RDN). The RDN is the left-most DN attribute value. The attributes you use depend on the type of entry you are naming.

Your entry names should adhere to the following rules:

  • The attribute you select for naming should be unlikely to change.

  • The name must be unique across your directory.

    A unique name ensures that a DN can refer to at most one entry in your directory.

When creating entries, define the RDN within the entry. By defining at least the RDN within the entry, you can locate the entry more easily. This is because searches are not performed against the actual DN but rather the attribute values stored in the entry itself.

Attribute names have a meaning, so try to use the attribute name that matches the type of entry it represents. For example, do not use l (locality) to represent an organization, or c (country) to represent an organizational unit.

The following sections provide tips on naming entries:


Naming Person Entries

The person entry's name, the DN, must be unique. Traditionally, distinguished names use the commonName, or cn, attribute to name their person entries. That is, an entry for a person named Babs Jensen might have the distinguished name of:

cn=Babs Jensen,dc=siroe,dc=com

While allowing you to instantly recognize the person associated with the entry, it might not be unique in an include people with identical names. This quickly leads to a problem known as DN name collisions, multiple entries with the same distinguished name.

You can avoid common name collisions by adding a unique identifier to the common name. For example:

cn=Babs Jensen+employeeNumber=23,dc=siroe,dc=com

However, this can lead to awkward common names for large directories and can be difficult to maintain.

A better method is to identify your person entries with some attribute other than cn. Consider using one of the following attributes:

  • uid

    Use the uid (userID) attribute to specify some unique value of the person. Possibilities include a user login ID or an employee number. A subscriber in a hosting environment should be identified by the uid attribute.

  • mail

    Use the mail attribute to contain the value for the person's email address. This option can lead to awkward DNs that include duplicate attribute values (for example: mail=bjensen@siroe.com, dc=siroe,dc=com), so you should use this option only if you cannot find some unique value that you can use with the uid attribute. For example, you would use the mail attribute instead of the uid attribute if your enterprise does not assign employee numbers or user IDs for temporary or contract employees.

  • employeeNumber

    For employees of the inetOrgPerson object class, consider using an employer assigned attribute value such as employeeNumber.

Whatever you decide to use for an attribute-data pair for person entry RDNs, you should make sure that they are unique, permanent values. Person entry RDNs should also be readable. For example, uid=bjensen, dc=siroe,dc=com is preferable to uid=b12r56A, dc=siroe,dc=com because recognizable DNs simplify some directory tasks, such as changing directory entries based on their distinguished names. Also, some directory client applications assume that the uid and cn attributes use human-readable names.


Considerations for Person Entries in a Hosted Environment
If a person is a subscriber to a service, the entry should be of object class inetUser and the entry should contain the uid attribute. The attribute must be unique within a customer subtree.

If a person is part of the hosting organization, represent them as an inetOrgPerson with the nsManagedPerson object class.


Placing Person Entries in the DIT
Here are some guidelines for placing people entries in your directory tree:

  • People in an enterprise should be located in the directory tree below the organization's entry.

  • Subscribers to a hosting organization need to be below the ou=people branch for the hosted organization.


Naming Group Entries

There are four main ways to represent a group:

  • A static group

    The entry for this type of group uses the groupOfNames or groupOfUniqueNames object class, which contains values naming the members of the group. Static groups are suitable for groups with few members, such as the group of directory administrators. Static groups are not suitable for groups with thousands of members.

    Static group entries must contain a uniqueMember attribute value, because uniqueMember is a mandatory attribute of the groupOfUniqueNames object. This object class requires the cn attribute, which can be used to form the DN of the group entry.

  • A member-based group

    This type of group uses a memberOf attribute in the entry of each group member.

  • A dynamic group

    This type of group uses an entry representing the group with a search filter and subtree. Entries matching the filter are members of the group.

  • A Directory Server role

    Roles are a new feature of Directory Server that unify the static and dynamic group concept. Refer to "About Roles" for more information.

In a deployment containing hosted organizations, we recommend using the groupOfUniqueNames object class to contain the values naming the members of groups used in directory administration. In a hosted organization, we also recommend that group entries used for directory administration are located under the ou=Groups branch.


Naming Organization Entries

The organization entry name, like other entry names, must be unique. Using the legal name of the organization along with other attribute values helps ensure the name is unique. For example, you might name an organization entry as follows:

o=Company22+st=Washington,o=ISP,c=US

You can also use trademarks, however they are not guaranteed to be unique.

In a hosting environment, you need to include the following attributes in the organization's entry:

  • o (organizationName)

  • objectClass with values of top, organization, and nsManagedDomain


Naming Other Kinds of Entries

Your directory will contain entries that represent many things, such as localities, states, countries, devices, servers, network information, and other kinds of data.

For these types of entries, use the commonName (cn) attribute in the RDN if possible. Therefore, if you are naming a group entry, name it as follows:

cn=administrators,dc=siroe,dc=com

However, sometimes you need to name an entry whose object class does not support the commonName attribute. Instead, use an attribute that is supported by the entry's object class.

There does not have to be any correspondence between the attributes used for the entry's DN and the attributes actually used in the entry. However, a correspondence between the DN attributes and attributes used by the entry simplifies administration of your directory tree.



Grouping Directory Entries


Once you have created entries, you can group them for ease of administration. The Directory Server supports several methods for grouping entries and sharing attributes between entries:

  • Using roles

  • Using class of service

The following sections describe each of these mechanisms in more detail.


About Roles

Roles are a new entry grouping mechanism. Your directory tree organizes information hierarchically. This hierarchy is a grouping mechanism, though it is not suited for short-lived, changing organizations. Roles provide another grouping mechanism for more temporary organizational structures.

Roles unify static and dynamic groups. You use static groups to create a group entry that contains a list of members. Dynamic groups allow you to filter entries that contain a particular attribute and include them in a single group.

Each entry assigned to a role contains the nsRole attribute, a computed attribute that specifies all of the roles an entry belongs to. A client application can check role membership by searching the nsRole attribute, which is computed by the directory and therefore always up-to-date.

Roles are designed to be more efficient and easier to use for applications. For example, applications can locate the roles of an entry, rather than select a group and browse the members list.

You can use roles to do the following:

  • Enumerate the members of the role.

    Having an enumerated list of role members can be useful for resolving queries for group members quickly.

  • Determine whether a given entry possesses a particular role.

    Knowing the roles possessed by an entry can help you determine whether the entry possesses the target role.

  • Enumerate all the roles possessed by a given entry.

  • Assign a particular role to a given entry.

  • Remove a particular role from a given entry.

Each role has members, entries that possess the role. You can specify members either explicitly (meaning each entry contains an attribute associating it with a role) or dynamically (by creating a filter that assigns entries to roles depending upon an attribute contained by the entry). How you specify role membership depends upon the type of role you are using. There are three types of roles:

  • Managed roles.

    A managed role allows you to create an explicit enumerated list of members. Managed roles are added to entries using the nsRoleDN attribute.

  • Filtered roles.

    A filtered role allows you to assign entries to the role depending upon the attribute contained by each entry. You do this by specifying an LDAP filter. Entries that match the filter are said to possess the role.

  • Nested roles.

    A nested role allows you to create roles that contain other roles. You specify the roles nested within it using the nsRoleDN attribute.


Deciding Between Roles and Groups

Both methods of grouping entries have advantages and disadvantages. Roles reduce client-side complexity at the cost of increased server complexity. With roles, the client application can check role membership by searching the nsRole attribute. From the client application point of view, the method for checking membership is uniform and is performed on the server side.

Dynamic groups, from an application point of view, offer no support from the server to provide a list of group members. Instead, the application retrieves the group definitions and then runs the filter. For static groups, the application must make sure the user is part of a particular UniqueMember attribute value. The method for determining group membership is not uniform.

You can use managed roles to do everything you would normally do with static groups. You can filter group members using filtered roles as you used to do with dynamic groups.

While roles are easier to use, more flexible, and reduce client complexity, they do so at the cost of increased server complexity. Determining role membership is more resource intensive because the server does the work for the client application.


About Class of Service

A class of service (CoS) allows you to share attributes between entries in a way that is invisible to applications. With CoS, some attribute values may not be stored with the entry itself. Instead, they are generated by class of service logic as the entry is sent to the client application.

For example, your directory contains thousands of entries that all share the common attribute facsimileTelephoneNumber. Traditionally, to change the fax number, you would need to update each entry individually, a large job for administrators that runs the risk of not updating all entries. With CoS, you can generate the attribute dynamically. The facsimileTelephoneNumber attribute is stored in one place, and each entry points to that place to give a value to their fax number attribute. For the application, these attributes appear just like all other attributes, despite that they are not actually stored on the entries themselves.

Each CoS is comprised of the following entries in your directory:

  • CoS Definition Entry.

    The CoS definition entry identifies the type of CoS you are using. It is stored as an LDAP subentry below the branch it affects.

  • Template Entry.

    The template entry contains a list of the shared attribute values. Changes to the template entry attribute values are automatically applied to all the entries sharing the attribute.

The CoS definition entry and the template entry interact to provide attribute values to their target entries, the entries within their scope. The value they provide depends upon the following:

  • The entry's DN (different portions of the directory tree might contain different CoS).

  • A service class attribute value stored with the entry.

    The absence of a service class attribute can imply a specific default CoS.

  • The attribute value stored in the CoS template entry.

    Each CoS template entry supplies the attribute value for a particular CoS.

  • The object class of the entry.

    CoS attribute values are generated only when an entry contains an object class allowing the attribute when schema checking is turned on, otherwise all attribute values are generated.

  • The attribute stored in some particular entry in the directory tree.

You can use different types of CoS depending upon how you want the value of your dynamic attributes to be generated. There are three types of CoS:

  • Pointer CoS.

    A pointer CoS identifies the template entry using the template DN only. There may be only one template DN for each pointer CoS. A pointer CoS applies to all entries within the scope of the template entry.

  • Indirect CoS.

    An indirect CoS identifies the template entry using the value of one of the target entry's attributes. The target entry's attribute must contain the DN of an existing entry.

  • Classic CoS.

    A classic CoS identifies the template entry by both its DN and the value of one of the target entry's attributes. Classic Cos can have multiple template entries, including a default CoS template to be applied to those entries that do not belong to any other CoS template.

Roles and the Classic CoS can be used together to provide role-based attributes. These attributes appear on an entry because it possesses a particular role with an associated class of service template. For example, you could use a role-based attribute to set the server look through limit on an role-by-role basis.



Directory Tree Design Examples


The following sections provide examples of directory trees designed to support a flat hierarchy as well as several examples of more complicated hierarchies.


Directory Tree for an International Enterprise

To support an international enterprise, root your directory tree in your Internet domain name and then branch your tree for each country where your enterprise has operations immediately below that root point. In "Suffix Naming Conventions", you are advised to avoid rooting your directory tree in a country designator. This is especially true if your enterprise is international in scope.

Because LDAP places no restrictions on the order of the attributes in your DNs, you can use the c (countryName) attribute to represent each country branch as follows:



However, some administrators feel that this is stylistically awkward, so instead you could use the l (locality) attribute to represent different countries:




Directory Tree for an ISP

Internet service providers (ISPs) may support multiple enterprises with their directories. If you are an ISP, consider each of your customers as a unique enterprise and design their directory trees accordingly. For security reasons, each account should be provided a unique directory tree with a unique suffix and an independent security policy.

You can assign each customer a separate database, and store these databases on separate servers. Placing each directory tree in its own database allows you to back up and restore data for each directory tree without affecting your other customers.

In addition, partitioning helps reduce performance problems caused by disk contention, and reduces the number of accounts potentially affected by a disk outage.

For example, the directory tree for I-Zed, an ISP, appears as follows:





Other Directory Tree Resources


Take a look at the following links for more information about designing your directory tree:


Previous     Contents     Index     DocHome     Next     
Copyright © 2001 Sun Microsystems, Inc. Some preexisting portions Copyright © 2001 Netscape Communications Corp. All rights reserved.

Last Updated March 15, 2001