HP-UX Directory Server 8.1 deployment guide

The databases could be stored on a single server or multiple servers depending on resource
constraints.
4.2.2 Creating the directory tree structure
Decide whether to use a flat or a hierarchical tree structure. As a general rule, try to make the
directory tree as flat as possible. However, a certain amount of hierarchy can be important later
when information is partitioned across multiple databases, prepare replication, and set access
controls.
The structure of the tree involves the following steps and considerations:
• “Branching the directory”
• “Identifying branch points”
• “Replication considerations”
• “Access control considerations”
4.2.2.1 Branching the directory
Design the 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 the directory tree hierarchy:
• Branch the tree to represent only the largest organizational subdivisions in the 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 the divisions
used to branch the directory tree are stable; do not perform this kind of branching if the
enterprise reorganizes frequently.
• Use functional or generic names rather than actual organizational names for the branch
points.
Names change, and it is really bad to have to change the directory tree every time the
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 there are 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 there are multiple marketing organizations, each of which is responsible
for a specific product line, create a single ou=Marketing subtree. All marketing entries
then belong to that tree.
Branching in an enterprise environment Name changes can be avoided if the directory tree
structure is based on information that is not likely to change. For example, base the structure on
types of objects in the tree rather than organizations. This helps avoid shuffling an entry between
organizational units, which requires modifying the distinguished name (DN), which is an
expensive operation.
There are a handful of common objects that are good to use to define the structure:
• ou=people
• ou=groups
• ou=services
A directory tree organized using these objects might appear as shown below.
4.2 Designing the directory tree 41