2.2 Designing the eDirectory Tree

Designing the eDirectory tree is the most important procedure in the design and implementation of a network. The design consists of the following tasks:

2.2.1 Creating a Naming Standards Document

Using standard names such as object names makes your network more intuitive to both users and administrators. Written standards can also specify how administrators set other property values, such as telephone numbers and addresses.

Searching and browsing the directory rely greatly on the consistency of naming or property values.

The use of standard names also makes it easier for NetIQ Identity Manager to move data between eDirectory and other applications. For more information on Identity Manager, see the NetIQ Identity Manager Setup Guide.

Naming Conventions

Objects

  • The name must be unique in the container. For example, Debra Jones and Daniel Jones cannot both be named DJONES if they are in the same container.

  • Special characters are allowed. However, plus signs (+), equals signs (=), and periods (.) must be preceded by a backslash (\) if used. Additional naming conventions apply to Server and o, as well as to bindery services and multilingual environments.

  • Uppercase and lowercase letters, as well as underscores and spaces, are displayed as you first entered them, but they aren’t distinguished. For example, Manager_Profile and MANAGER PROFILE are considered to be identical.

  • If you use spaces, you must enclose the name in quotes when entering it on the command line or in login scripts.

Server Objects

  • Server objects are automatically created when you install new servers.

  • You can create additional Server objects for existing Windows servers and for eDirectory servers in other trees, but they are all treated as bindery objects.

  • When creating a Server object, the name must match the physical server name, which

    • Is unique in the entire network.

    • Is from 2 to 47 characters long.

    • Contains only letters A-Z, numbers 0-9, hyphens (-), periods (.), and underscores (_).

    • Does not use a period as the first character.

  • Once named, the Server object cannot be renamed in NetIQ iManager. If you rename it at the server, the new name automatically appears in iManager.

Country Objects

Country objects should follow the standard two-letter ISO country code.

For more information, see the ISO 3166 Code Lists.

Multilingual Considerations

If you have workstations running in different languages, you might want to limit object names to characters that are viewable on all the workstations. For example, a name entered in Japanese cannot contain characters that aren’t viewable in Western languages.

IMPORTANT:The Tree name should always be specified in English.

Sample Standards Document

The following is a sample document containing standards for some of the most frequently used properties. You need to have standards only for those properties you use. Distribute the standards document to all administrators responsible for creating or modifying objects.

Object Class | Property

Standard

Examples

Rationale

User | Login name

First initial, middle initial (if applicable), and last name (all lowercase). Eight characters maximum. All common names are unique in the company.

msmith, bjohnson

Using unique names company-wide is not required by eDirectory but helps avoid conflicts within the same context (or bindery context).

User | Last name

Last name (normal capitalization).

Smith

Used for generating mailing labels.

Telephone and fax numbers

Numbers separated by hyphens.

US: 123-456-7890 Other: 44-344-123456

Used by autodialing software.

Multiple classes | Location

Two-letter location code (uppercase), hyphen, mail stop.

BA-C23

Used by interoffice mail carriers.

Organization | Name

The name of your company for all trees.

YourCo

If you have separate trees, a standard Organization name allows for future merging of trees.

Organizational Unit | Name (based on location)

Two- or three-letter location code, all uppercase.

ATL, CHI, CUP, LA, BAT, BOS, DAL

Short, standard names are used for efficient searching.

Organizational Unit | Name (based on department)

Department name or abbreviation.

Sales, Eng

Short, standard names make it easy to identify which department the container is servicing.

Group | Name

Descriptive name.

Project Managers

Avoid extremely long names. Some utilities will not display them.

Directory Map | Name

Contents of the directory indicated by the Directory Map.

DOSAPPS

Short, standard names make it easy to identify which department the container is servicing.

Profile | Name

Purpose of the profile.

MobileUser

Short, standard names make it easy to identify which department the container is servicing.

Server | Name

SERV, hyphen, department, hyphen, unique number.

SERV-Eng-1

eDirectory requires server names to be unique in the tree.

2.2.2 Designing the Upper Layers of the Tree

You should carefully design the upper layers of the tree because changes to the upper layers affect the rest of the tree, especially if your organization has WAN links. You want to design the top of the tree so that few changes will be necessary.

Use the following eDirectory design rules to create your eDirectory tree:

  • Use a pyramid design.

  • Use one eDirectory tree with a unique name.

  • Create a single Organization object.

  • Create first-level Organizational Units that represent the physical network infrastructure.

Figure 2-1 depicts the eDirectory design rules.

Figure 2-1 eDirectory Design Rules

To create the upper layers of the tree, see Creating an Object and Modifying an Object's Properties.

Using a Pyramid Design

With a pyramid-designed eDirectory, managing, initiating changes to large groups, and creating logical partitions are easier.

The alternative to the pyramid design is a flat tree that places all objects in the top layers of the tree. eDirectory can support a flat tree design. However, a flat tree design can be more difficult to manage and partition.

Using One eDirectory Tree with a Unique Name

A single tree works best for most organizations. By default, one tree is created. With one tree you have single-user identity on the network, simpler administration of security, and single point of management.

This recommendation for a single tree for business use does not preclude additional trees for testing and development.

Some organizations, however, might need multiple trees because of legal, political, or corporate issues. For example, an organization consisting of several autonomous organizations might need to create several trees. If your organization needs multiple trees, consider using NetIQ Identity Manager to simplify management. For more information on Identity Manager, see the NetIQ Identity Manager Setup Guide.

When you name the tree, use a unique name that will not conflict with other tree names. Use a name that is short and descriptive, such as EDL-TREE.

If two trees have the same name and are located on the same network, you might encounter the following problems:

  • Updates going to the wrong tree

  • Resources disappearing

  • Rights disappearing

  • Corruption

You can change the tree name using the DSMerge utility, but do so with caution. A tree name change impacts the network because you need to reconfigure the clients to use the new tree name.

Creating a Single Organization Object

Generally, an eDirectory tree should have one Organization object. By default, a single Organization object is created and named after your company. This allows you to configure changes that apply to the whole company from a single location in the tree.

For example, you can use ZENworks® to create a Workstation Import Policy object in the Organization object. In this policy, which affects the whole organization, you define how Workstation objects are named when created in eDirectory.

In the Organization container, the following objects are created:

  • Admin

  • Server

  • Volume

    Networks with only a Windows or Linux server running eDirectory have no Volume objects.

You might want to create multiple Organization objects if your company has the following needs:

  • It comprises multiple companies that do not share the same network.

  • It needs to represent separate business units or organizations.

  • It has a policy or other internal guidelines that dictate that organizations remain separate.

Creating Organizational Units That Represent the Physical Network

First-level Organizational Unit design is important because it affects the partitioning and efficiency of eDirectory.

For networks that span more than one building or location using either a LAN or a WAN, the first-level Organizational Unit object design should be based on location. This allows you to partition eDirectory in a way that keeps all objects in a partition at one location. It also provides a natural place to make security and administrator assignments for each location.

2.2.3 Designing the Lower Layers of the Tree

You should design the lower layers of the tree based on the organization of network resources. You have more freedom in designing the lower layers of an eDirectory tree than the upper layers because lower-layer design affects only objects at the same location.

To create the lower layers of the tree, see Creating an Object and Modifying an Object's Properties.

Determining Container, Tree, and Database Size

The number of lower-level container objects you create depends on the total number of objects in your tree and your disk space and disk I/O speed limitations. eDirectory has been tested with over 1 billion objects in a single eDirectory tree, so the only real limitations are disk space, disk I/O speed, and RAM to maintain performance. Keep in mind that the impact of replication on a large tree is significant.

A typical object in eDirectory is 3 to 5 KB in size. Using this object size, you can quickly calculate disk space requirements for the number of objects you have or need. Keep in mind that the object size will grow depending upon how many attributes are completed with data and what the data is. If objects will hold binary large object (BLOB) data such as pictures, sounds, or biometrics, the object size will subsequently grow.

The larger the partitions, the slower the replication cycles. If you are using products that require the use of eDirectory, such as ZENworks and DNS/DHCP services, the eDirectory objects created by these products will affect the size of the containers they are located in. You might consider placing objects that are for administration purposes only, such as DNS/DHCP, in their own partition so user access is not affected with slower replication. Also, managing partitions and replicas will be easier.

If you are interested, you can easily determine the size of your eDirectory database or the Directory Information Base (DIB) Set.

  • For Windows, look at the DIB Set at \novell\nds\dibfiles.

  • For Linux, look at the DIB Set in the directory you specified during installation.

Deciding Which Containers to Create

In general, create containers for objects that have access needs in common with other eDirectory objects. This lets you service many users with one trustee assignment or login script. You can create containers specifically to make container login scripts more effective, or you can place two departments in one container to make login script maintenance more feasible.

Keep users close to the resources they need to limit traffic over the network. For example, people who work in the same department generally work near each other. They usually need access to the same file system and they print to the same printers.

Exceptions to general workgroup boundaries are not hard to manage. If two workgroups use a common printer, for instance, you can create an Alias object to the printer in one of the workgroups. You can create Group objects to manage some User objects within a workgroup or User objects across multiple workgroups. You can create Profile objects for subsets of users with unique login script requirements.