The Country object is an optional container that organizes a directory tree by country. This type of object can only be defined directly under the Tree Root and must be named using a two-character abbreviation. Novell states that you must use a valid two-character country abbreviation. Presumably, this is to ensure that your network is in compliance with the two-character abbreviations defined in the ISO X.500 standard.

Interestingly, if you create a Country object using the ConsoleOne utility, it allows you to use any two-character name. To determine which two-character names are compliant with the ISO X.500 standard, click Help when creating the Country object and NetWare 6 will tell you whether the name is compliant. You can also visit the ISO Web site at www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html to see a list of country codes. The only objects that can exist in a Country container are an Organization or Alias object pointing to an Organization.

If you don’t use a Country object, the next layer in the tree is typically an Organization. You can use an Organization object to designate a company, a division of a company, a university or college with various departments, and so on. Every directory tree must contain at least one Organization object. Therefore, it is required. Many small implementations use only the Organization object and place all their resources directly underneath it. Organization objects must be placed directly below the Tree Root unless a Country object is used. Finally, Organization objects can contain all objects except Tree Root, Country, and Organization.

Earlier, we defined the Organization as a one-dimensional object. That means the tree can support only one layer of Organization objects. If you look closer at the icon, you’ll see a box with multiple horizontal boxes underneath. Additional vertical hierarchy is defined by Organizational Units, which are multidimensional. I’ll describe them in just a moment.

Figure 19.3 illustrates the object dialog box for the ACME Organization using ConsoleOne. Within the screen there are many page buttons that identify categories of eDirectory properties for this object. Associated with each page button is an input screen for a specific set of information. The Identification page button (shown here) enables you to define a variety of Organization properties, including Name, Other Name, Description, Location, Telephone, and Fax Number.

FIGURE 19.3 Properties of an eDirectory Organization object.

Similar page buttons enable you to configure important Organization parameters, including postal information, print job configurations, trustee assignments, and so on. As far as ACME is concerned, the Organization container defines the top of the functional tree.

The Organizational Unit object is a natural group. It allows you to organize users with the leaf objects they use. You can create a user template for security, group login scripts, trustee assignments, security equivalences, and distributed administrators.

An Organizational Unit can represent a division, business unit, project team, or department. Organizational Units are multidimensional in that you can have many hierarchical levels of containers within containers. Remember, Organization objects can exist at only one level in the eDirectory tree.

Organizational Units are the most flexible containers because they can contain other Organizational Unit objects or leaf objects. As a matter of fact, Organizational Units can contain most of the eDirectory object types, except the Tree Root, Country, or Organization containers (or aliases of any of these).

Now let’s take a look at the real stars of our eDirectory world—leaf objects.

Current context is sometimes referred to as name context. It defines where you are in the eDirectory tree at any given time, not where you live. This is an important distinction. For example, if you’re using a NetWare 6 utility, it’s important to know what the utility considers as the current context in the eDirectory tree (that is, the default container to use if one isn’t specified). This concept is somewhat similar to knowing your current default drive/directory when using a DOS or Windows utility on your workstation.

In addition, current context affects how much of an object’s distinguished name you must provide to find it. (See the “Distinguished Names” section later in this chapter for more information.) Current context also enables you to refer to an object in your current container by its common name because the object’s context is the same. Note that current context always points to a container object rather than a leaf object. Typically, at login, you’ll want a workstation’s current context set to the container that holds the user’s most frequently used resources.

In Figure 19.7, Fred’s context is “...in the ADMIN division of ACME.” This context identifies where Fred lives in the eDirectory tree structure. It identifies all container objects leading from him to the Tree Root. In addition to context, Figure 19.7 identifies Fred’s common name (CN). A leaf object’s common name specifically identifies it within a given container. In this example, the User object’s common name is Fred.

Two objects in the same eDirectory tree may have the same common name—provided, however, that they have different contexts. This is why naming is so important. As you can see in Figure 19.8, our eDirectory tree has two Freds, but each has a different context.

FIGURE 19.8 Understanding eDirectory context.

Object context (sometimes referred to as context) defines where a particular object is located in the eDirectory tree structure. It is a list of container objects leading from the object to the Tree Root. Locating an object through context is similar to locating a file using the directory path. As you learned earlier, object context is used for two important purposes: logging in and accessing resources. Unfortunately, eDirectory does not have a search path feature (such as NetWare SEARCH drives or the DOS PATH command used in the file system). This means that when you request a particular network resource, you (or your workstation) must provide eDirectory with enough information to locate the object in the tree.

Each eDirectory object has a naming type (also known as an attribute type) associated with it, which enables you to precisely identify objects in your tree. The tree organization obviously dictates how the objects can be located and used. This naming type is identified by a one- or two-character abbreviation. Accompanying the naming type is the value of the object, or the name you enter for the object when you create it. The following are examples of naming types and associated values:

The common name (CN) attribute is the name shown next to the leaf object in the eDirectory tree. This attribute applies to all leaf objects (servers, users, groups, and so on). When requesting a resource such as a server, the CN must be included in the request. Note: Common Names in eDirectory 8.7 behave slightly differently.

Now that you understand how eDirectory context works, let’s review the naming rules associated with it:

So, there you have it. That’s how context works. With this in mind, it’s time to explore the two main types of eDirectory names: distinguished names and typeful names.

An object’s distinguished name is its complete eDirectory path. It is a combination of common name and object context. Each object in the eDirectory tree has a distinguished name that uniquely identifies it in the tree. In other words, two objects cannot have the same distinguished name.

In Figure 19.9, AEinstein’s context is .OU=R&D.OU=LABS.O=ACME and his common name is CN=AEinstein. Therefore, Einstein’s distinguished name is a simple mathematical addition of the two:

FIGURE 19.9 Building AEinstein’s distinguished name.

Notice the use of periods. A distinguished name always starts with a leading period. Trailing periods aren’t allowed. The leading period identifies the name as distinguished (that is, complete). Otherwise, it is assumed to be incomplete or, in other words, a relative distinguished name.

A relative distinguished name (RDN) lists an object’s path to the current context, not the Tree Root. The relativity part refers to how eDirectory builds the distinguished name when you supply a relative name. By definition, for example, the common name of a leaf object is a relative distinguished name. When you use a relative distinguished name, eDirectory builds a distinguished name by appending the current context to the end:

Relative distinguished name + current context = distinguished name

For example, if the current context is .OU=LABS.O=ACME and you submit a relative distinguished name of CN=AEinstein.OU=R&D, the distinguished name would be resolved as (refer to Figure 19.10) the following:

FIGURE 19.10 Building AEinstein’s relative distinguished name.

To resolve a relative name, you must not lead with a period. Instead, you can use trailing periods to change the current context used to resolve the name (as if naming weren’t hard enough already). The bottom line is that each trailing period tells eDirectory to remove one object name from the left side of the current context being used. This concept is somewhat similar to the trailing dot feature used in the DOS CD command.

For example, assume that .OU=R&D.OU=LABS.O=ACME is your current context and that CN=LEIA.OU=ADMIN.. is your relative distinguished name. In this case, the distinguished name would resolve as follows (refer to Figure 19.11):

FIGURE 19.11 Using trailing periods to resolve Leia’s distinguished name.

As you can see, it’s very important where you place your dots! Here’s a quick summary:

For a complete summary of eDirectory distinguished naming rules, refer to Table 19.3.

TABLE 19.3 Getting to Know Distinguished Naming

Now, let’s step back into reality for a moment and explore the other eDirectory naming category—typeful and typeless names.

Typeful names use attribute type abbreviations to distinguish between the different container types and leaf objects in eDirectory names. In all the examples to this point, we’ve used these abbreviations to help clarify context, distinguished names, and relative distinguished names. The following are the most popular attribute type abbreviations:

These attribute types help avoid the confusion that can occur when creating complex distinguished and relative distinguished names. I highly recommend that you use them. Of course, like most things in life—they’re optional! You can imagine how crazy eDirectory naming gets when you choose not to use these attribute abbreviations. This insanity is known as typeless naming.

Typeless names operate the same as typeful names, but they don’t include object attribute types. In such cases, eDirectory has to guess what object types you’re using. Take the following typeless name, for example:

Is this the ADMIN Organizational Unit under ACME? Or is this the Admin user under ACME? In both cases, it’s a valid distinguished name, except that one identifies an Organizational Unit container and the other identifies a User leaf object (refer to Figure 19.12).

FIGURE 19.12 Trying to understand typeless naming.

Well, here’s the bottom line: which one is it? It’s up to eDirectory. If you don’t provide a typeful object name, eDirectory calculates attribute types for each object. Fortunately, NetWare 6 has some guidelines for guessing what the object type should be.

Although this works for most cases, it’s only a general guideline. Many times, typeless names are more complex. Consider our example in Figure 19.12, for instance. We know now that the rightmost object is an Organization, but what about Admin? Is it a common name or an Organizational Unit? We still don’t know. Fortunately, NetWare 6 includes a few exceptions to deal with complex typeless scenarios. Here’s how it works:

There you have it. This completes our discussion of typeless names and eDirectory naming in general. As you can see, this is an important topic because it affects all aspects of eDirectory design, installation, and management. No matter what you do, you’re going to have to use the correct name to log in to the tree or access eDirectory resources. As you’ve learned, an object’s name is a combination of what it is (common name) and where it lives (context).

Now, let’s build a naming standards document.

eDirectory tree design begins with an object naming standard. Begin by taking a long, hard look at ACME and the network resources it uses. Consider the affect of naming on these resources and come up with some simple guidelines for standardizing the names. The good news is that most of your effort is focused on a few leaf and container objects, namely the following:

You should keep the following in mind:

Creating an eDirectory naming standards document for objects is as easy as 1-2-3-4:

1.   List each type of object used in the eDirectory tree

2.   Specify the standard you will use for each object type

3.   Provide a brief example for each object type used

4.   Specify the rationale for each object type selected

This completes our discussion of the main eDirectory object classes. In addition, you might want to consider naming standards for Group, Organizational Role, Directory Map Object, and Profile objects. Refer to Table 19.4 for a detailed summary of ACME’s eDirectory object naming standard.

The final step is to put your naming guidelines under the microscope. Now you must focus in on each object class and provide rules for required, optional, and system properties.

First, determine which properties should be required. Start with the mandatory eDirectory properties and expand from there. For example, eDirectory won’t allow you to create a User object without the Login Name and Last Name properties. In ACME’s case, we’re also requiring Given Name, Full Name, Middle Initial, Title, Location, Telephone Number, Fax Number, Home Directory, and Require Password.

Next, determine which properties will be optional. Finally, identify system properties (such as Network Address and so on). In addition, you’ll want to provide naming rules for how the properties look. Refer to Table 19.5 for a detailed summary of ACME’s eDirectory property naming standard.

After you’ve completed the naming guidelines and examples, there’s only one more set of rules to complete your naming standards document: syntax. Table 19.6 shows a simple but effective syntax standard. Notice that I’ve also included examples. In the most basic sense, this is a summary of the entire naming standards document. Small organizations could probably get away with using just the naming syntax guidelines.

TABLE 19.6 ACME’s Naming Standard Syntax

Here’s the legend for Table 19.6:

Congratulations! You’ve completed the ACME naming standards document. What an accomplishment. It wasn’t easy, but now you should feel much more comfortable about the future of ACME’s design. At the very least, we know what to call eDirectory objects and their properties.

The next step is eDirectory tree design. This is when you get a chance to establish rules for tree design, just as you did for naming standards. Have fun.

First, you must name the tree itself. The tree name is represented by the [Root] object, which is placed at the top of the eDirectory pyramid. A good strategy is to create a tree name that consists of the name of your organization name plus -TREE. For example, our company is called ACME, so we named the tree ACME-TREE (refer to Figure 19.17).

The tree name must be unique. If you need to install more than one logical tree on the same physical network, be sure that the trees have different names. You can change the name of the tree after initial eDirectory installation, if necessary, by using the DSMERGE utility. Changing the tree name has a greater effect on larger networks because it requires a great deal of effort to reconfigure clients to use the new tree name.

The Organization layer defines the company and its purpose. All other geographic and organizational functions are provided by lower Organizational Unit layers. A good strategy is to use an abbreviation of your organization’s name as the name of the Organization object. For example, our company is named A Cure for Mother Earth, which is abbreviated to ACME (see Figure 19.17).

Using a single Organization container provides an excellent tool for distributing management policies throughout the entire company. For example, you can implement a workstation-naming convention from your eDirectory naming standards document by creating ZENworks Workstation Import Policy objects and placing them at the Organization level. In this policy, you can define how Workstation objects are named when they’re created in eDirectory. In this case, the policy would affect the whole company. See Figure 19.18 for an example of a single O=ACME Organization tree design.

FIGURE 19.18 A single O=Organization at ACME.

Limiting your eDirectory tree to a single Organization object is not a requirement. Following are a few exceptions that could justify the use of multiple Organization containers:

In Figure 19.19, we’ve combined ACME and the UN into a single eDirectory tree. In this example, the two multinational conglomerates (ACME and UN) include many different locations, each of which operates independently of each other. As you can see in the figure, we’ve created an O=Organization for each corporation.

FIGURE 19.19 ACME and the UN share an eDirectory tree.

The final top layers are defined by Organizational Unit containers. These are the most important layers in the tree because they represent a transition point between the inflexible upper layers and the flexible bottom layers. These OU layers also define the layout of the rest of the tree. In summary, this is where your tree begins to take shape.

You can choose one of three approaches for the final tier of the top layers:

The first approach is based on the geographic boundaries (or location) of your WAN. Remember, the sole purpose of the eDirectory tree is to productively organize network resources. These resources are geographically distributed and rely on slow WAN links for interconnectivity. Basing your organization on geographic boundaries provides a natural place in the eDirectory to make security and administrator assignments for each location. To optimize partitioning, replica placement, and time synchronization, you should design the first layer of OUs along these WAN boundaries.

As a matter of fact, the dynamic nature of eDirectory essentially forces you to design the top layers of the tree according to geography. Some reasons include the following:

The geographic approach relies on your WAN layout map. As you could see in Figure 19.13, ACME is organized around five main hubs: CAMELOT, RIO, SYDNEY, TOKYO, and NORAD. These hubs become the foundation of ACME’s OU structure, as shown in Figure 19.17. After you’ve established the geographic top of the tree, you can zero in on each location with an organizational design—at the bottom layers.

Of course, life is full of exceptions, and the geographic approach is not always the best answer. Following are three exceptions to consider:

If you’re using a campus layout (such as a research park or university), first consider the speed of the links between buildings or floors. The geographic approach could still be used with buildings representing minor OU sites within the network infrastructure. Even in ACME’s case, the distributed campus buildings could be useful second-tier container objects—as long as they help organize the network resources.

The second approach relies on the introduction of regional containers above the geographic OU layers. This is necessary if the total number of locations is high—10 to 15 subcontainers per location, for example. Adding an intermediate regional layer helps to ensure a balanced pyramid design.

Consider what happens when ACME decides to expand. Let’s say it decides to integrate more offices throughout the world. In this example only, ACME’s WAN infrastructure would look something like Figure 19.20. Notice that the distributed offices connect together via 56-Kbit links, whereas the hubs still use 512-Kbit lines. Also, each city is added to the WAN layout through their appropriate regional hub.

FIGURE 19.20 ACME’S new WAN layout with expanded cities.

Using the WAN infrastructure, we’ve designed a new tree that includes regional OUs named North America (NA), South America (SA), Europe (EUR), Asia (ASIA), and Australia (AUST). These regional OU layers group the appropriate cities and help keep the eDirectory tree design looking like a pyramid (see Figure 19.21).

FIGURE 19.21 Regional top layers for ACME.

The final option is based on functional workgroups throughout your company. This functional approach should only be used in the following two cases:

In either of these cases, you can place your departments, divisions, and workgroups at the top of the tree and physical locations at the bottom. This is a little less efficient because any change to the organizational structure ripples down the entire eDirectory tree design.

Consider the example in Figure 19.22. We’ve reversed the ACME design and put the workgroups at the top. Remember, most network changes occur at the organizational level. Therefore, this functional design will cause numerous changes to the top of the tree. Remember this design strategy: flexibility at the bottom, rigidity at the top. Also, when considering other design requirements (such as administration, partitions, replicas, and bindery services), it’s apparent that the functional design causes much more management overhead because of the inflexibility of the top layers of the tree.

FIGURE 19.22 Functional top layers for ACME.

Examine Table 19.10 for a critical comparison of the two most popular tree-design approaches: geographic and functional.

TABLE 19.10 Comparison of Geographic and Functional Design Approaches

Although your eDirectory tree might prove to be most efficient if you choose between the geographic, regional, or functional approaches, you aren’t required to choose only one. Some companies, in fact, require a combination of these approaches in the design of the top layers of their eDirectory trees.

This completes step 2: design the top layers. Yeah! We’re well on our way to completing ACME’s eDirectory tree design. There’s only one step left, and it involves thousands of resources. Good luck.

A centralized administration strategy depends on a single network administrator or IS group for management of eDirectory objects, partitioning, replication, and security. Central administrators (including Admin) are typically placed at the Organization level and must have Supervisor and Inheritable [SI] rights to the [Root] object.

If the eDirectory tree is to be managed centrally, the IS staff will build the entire tree and have control over all eDirectory objects. This approach helps standardize naming, simplifies object placement, and improves administrator navigation.

Another unique centralized administration strategy is to place all servers in a single eDirectory container (called the server container approach). The server container approach provides easier server access for users and simpler tracking of server activity. See Table 19.11 for a summary of the advantages and disadvantages of the server container centralized administration strategy.

TABLE 19.11 Understanding the Server Container Strategy

A decentralized administration strategy relies on various distributed individuals or groups who have managerial control over decentralized branches of the eDirectory tree. These individuals might be departmental administrators, or they might be responsible for all the network resources in a particular location.

If a department uses highly sensitive information and requires isolation from the rest of the organization, you could consider creating multiple trees or creating multiple organization objects.

In the decentralized administration model, you still need a centralized IS administrator to handle the top layers of the tree. However, you can block Admin from sensitive local information by placing an inherited rights filter (IRF) at the department or location level.