Organizing Objects into a Logical Hierarchy

Keeping your Directory tree structure as shallow as possible (three to five levels) benefits both small and large Directory trees. Nevertheless, NDS supports any degree of subordination you need to best support your organization's infrastructure.

Your Directory tree can model any or all of the following structures:

Organizational chart structure
You can begin with your organizational chart, and modify it according to network access requirements and other factors.
Geographic structure
You can use geographic locations as Organizational Units. Then, you could use your organizational chart for each location to organize those divisions.
Functional structure
If users or groups in your department or organization perform similar functions, consider organizing your Directory tree by function. Such users are likely to share servers and other resources, so it makes sense to group them together.
This is especially useful for groups of bindery services users.
Bindery services structure
The portions of the Directory used by bindery services users should use a combination of all three of the previously mentioned structures.
Bindery services users should be grouped within bindery contexts defined by workgroups, shared resources, and information usage and exchange.
Placing similar users in the same container object makes it easier to give bindery services users access to the resources they need.

Planning the Directory Tree Levels

You create container objects to form the top level of the Directory tree for both departmental and organizational strategies. These container objects help you manage and organize the network by relating groups of other container objects and leaf objects.

It is important to remember that the top level is the most important level of the Directory tree. All other levels of the tree branch off the top level. If you organize the top level well, you can organize your entire Directory tree more efficiently.

Consider the following when planning Directory tree levels:

The name of the Directory tree must be unique on the physical wire or backbone of the actual network hardware connection.
The depth of the Directory tree should be no longer than 256 characters for the Distinguished Name, which is the full context of the tree.
Remember that each level you add to the tree can increase the length of a user's context. The shorter you can keep users' contexts, the less problem they will have remembering them.
Partitions or replicas should be placed close to the end user.
For example, if there are departments in two cities that access the same resources in the Directory tree, such as printers or servers, then place a replica in both cities to accommodate both departments.
Rights should be granted by exception. That is, you should grant rights at the container level, then at the group level, and then at an individual object level if necessary.
For example, if you have a group of users that will generally require the same rights assignment, plan to place them in the same container and assign the rights to the container. Then, if there is a small subset of these users that should not have one of the rights assigned to everyone else, plan to mask the right for those User objects or add those objects to a group that has the right masked.

Placing Container Objects in the Directory Tree

Container objects and their contents should be defined by workgroups, shared resources, and information usage. Use Organization objects and Organizational Unit objects to build the Directory tree structure.

Country and Organization Objects

The Country object, which can be placed only between the [Root] object and your Organization objects, is useful when your network spans more than a single country or when you plan to access information on the global internetwork.

Because the Country object adds another level of complexity to your Directory tree, it is optional and should only be used in the cases previously indicated. See Appendix D, "NDS Object Classes and Properties" for more information.

Organization objects must be placed either directly below the [Root] object or any Country objects you choose to place in your Directory tree. At least one Organization object must be placed in your tree. However, you can create as many sibling Organization objects as you need, and as many Organizational Units underneath the Organization objects as you need, to best structure your Directory tree.

However, because Organization objects must be directory below the [Root] object or a Country object, do not depend on them to fully organize your tree. Use Organizational Unit objects to develop the structure of your tree.

The following figure shows an example tree with a Country object, one Organization object, and multiple Organizational Units.

Figure 7-2 Directory Tree with an Organization Object and Multiple Organizational Unit Objects

Organizational Unit Objects

You can designate geographic locations, projects, products, etc., as Organizational Units (OU). An advantage to using a geographic structure for your Directory tree is that you can see where objects are physically located. Using geographical locations will assist in the placement of replicas.

Because one goal of having a Directory tree is to provide a static database that is updated infrequently, broad geographic designations in which objects remain static, such as states or cities, might provide a more stable structure for your tree than one that is continually changing.

However, if users or other resources are moved between locations frequently, their contexts can change dramatically even though the organization might not.

The following figure shows an example Directory tree in which the

Organization object is designated as ACME
Organizational Units are designated as departments
Organizational Units at a lower level are designated as geographic locations (Detroit, London, and Tokyo) of those departments

The upper OU level reflects the management organization of the company, and the lower OU level divides the tree into physical locations. This tree is based on data from network administrators at each site, which makes it easy to administer. However, this tree may not facilitate the placement of replicas.

Figure 7-3 Directory Tree with Organizational Unit Designations at Different Levels

Organizational Units do not all have to be the same type. That is, you can designate a workgroup as an Organizational Unit and also designate a project as Organizational Unit.

You might want to organize your Directory tree by function if groups of users have the same functionality.

The following figure shows a Directory tree in which MFG (Manufacturing) and HQ (ACME Headquarters) represent departments, and Tokyo and London represent geographical locations, all under the Organization ACME.

Figure 7-4 Directory Tree with Mixed Organizational Unit Object Types

Some areas of your tree might need more than one Organizational Unit. In the current example, the Organizational Unit MFG contains another level of Organizational Units because MFG itself is a self-contained business unit, with its own Quality Assurance department, Engineering and Development departments, etc.

Therefore, another level of Organizational Units resides under the MFG Organizational Unit to allow the department network supervisors more flexibility in designing their portions of the Directory tree.

Having different Organizational Units can help network supervisors customize the Directory tree for their particular needs.

The tree in this example facilitates replication well, but it might be more difficult to manage than the example illustrated in Figure 7-3.

Placing Leaf Objects in the Directory Tree

Container objects and their contents should be defined by workgroups, shared resources, and information usage. Therefore, leaf objects representing resources used by a single group should be placed in the same container.

Keep the following considerations in mind when placing leaf objects in the Directory tree:

Design your Directory tree so that users have shared access to resources.
For example, if you have a high-speed printer in the organization that everyone needs access to, place the Printer object for that printer in a container where you can assign rights to allow everyone access to that Printer object.
You can always add, delete, or move leaf objects after you have installed your Directory tree.
Create User objects only in the container object where they will typically log in. It is undesirable to create duplicate User objects for the same person.
Plan to use User Templates in specific Organization and Organizational Unit objects. For more information, see "Managing User Templates" in Supervising the Network.
Also, plan to use Alias objects as necessary. Alias objects refer to an object that exists elsewhere in the tree without actually duplicating the object. Updates to an original object are immediately available to all Alias objects that reference it.
Rights should be granted by exception. That is, you should grant rights at the container level, then at the group level, and then on an individual object level if necessary.
For more information on container rights, see see "Container Rights" on page 26.
For more information on inheriting rights, see "Security" in Concepts. For more information on Group objects, see "Managing Group Objects" in Supervising the Network.

Directory Tree Planning Example

The following example represents some of the planning conventions used for implementing NDS in an organization with offices across a continent.

Assume that the ACME Corporation has offices in the following three cities within the United States:

Sales and accounting offices located in the corporate headquarters in New York, New York
A development and test facility in Detroit, Michigan
Manufacturing sites in Los Angeles, California

The following figure shows the physical layout of the offices, facilities, and sites used in the example, illustrating some of the previously discussed planning guidelines.

Figure 7-5 Physical Layout of a Medium-to-Large Directory Tree

The following figure shows the logical layout for an example Directory tree for ACME Corporation and some example names for leaf objects.

Figure 7-6 Example Logical Layout and Leaf Object Names

Notice that in this example all the usernames start with the initial of the first name, followed by the last name. Also notice that the names for LaserJet* printers include an "LJ" and Apple* printers include an "APL".

These are just examples of how naming standards can be used in the Directory tree. However you decide to name your objects, you should standardize naming throughout the Directory tree in order to exploit the Directory to its fullest.

See Appendix C, "NDS Object Classes and Properties" for ideas on how to standardize the naming of objects and properties in your Directory tree.

Organizing Objects into a Logical Hierarchy

Technical documentation

» Table of Contents

» Glossary