This chapter is from the book
This chapter is from the book
This chapter is from the book
Implementing eDirectory Naming
Test Objective Covered:
Identify the flow and design of the eDirectory tree (continued).
Now that you understand what the eDirectory tree is made of, you need to explore how it works. As you manage the eDirectory tree, pay particular attention to its structure. A well-designed tree will make resource access and management much easier.
The structure of the eDirectory tree is both organizational and functional. The location of an object in the tree can affect how users access it and how network administrators manage it. The eDirectory tree structure impacts the following areas of administrative responsibility:
eDirectory planning
Resource access
Resource setup
You complete these tasks by implementing eDirectory planning guidelines, using proper eDirectory naming structure, and understanding current context. Let's take a closer look.
Planning Guidelines
An efficient eDirectory tree provides all the following benefits:
It makes resource access easier for users.
It makes administration easier for network administrators.
It provides fault tolerance for the eDirectory database.
It decreases network traffic.
The structure of the tree can be based on location, organization, or administration. In many cases, it's a combination of all three. Many factors influence the structure of your eDirectory tree. Before you design your tree, you might need to study workgroups, resource allocation, and/or learn how data flows throughout your network.
As a CNA, it's your responsibility to navigate and manage the tree, not to design or troubleshoot it—that's what CNEs are for. This material is also covered in much greater detail in Novell's CNE Study Guide for NetWare 6.
TIP
Study the eDirectory benefits carefully—they are the foundation of your life as a NetWare 6 CNA. One final important point: eDirectory does not provide fault tolerance for the file system.
eDirectory Naming Structure
eDirectory naming defines rules for locating leaf objects. One of the most important aspects of a leaf object is its position in the eDirectory tree. Proper naming is required when logging in, accessing eDirectory utilities, printing, and for most other management tasks.
The name of an eDirectory object identifies its location in the hierarchical tree. Therefore, each object name must be unique. eDirectory naming impacts two important NetWare 6 tasks:
Login—Typically, you need to identify the location of your User object in the eDirectory tree for NetWare 6 to authenticate you during login.
Resource access—eDirectory naming exactly identifies the type and location of NetWare 6 resources, including file servers, printers, login scripts, and files.
The whole NetWare 6 eDirectory naming scheme is much more complicated than "Hi, I'm Fred." It requires both your name and location. For example, a proper eDirectory name would be "Hi, I'm Fred in the ADMIN division of ACME." As you can see in Figure 3.10, Fred's eDirectory name identifies who he is and where he works.
The eDirectory tree affects resource access because the organization of objects in the tree dictates how they can be found and used. In fact, the whole eDirectory naming strategy hinges on the concept of context. Context defines the position of an object within the Directory tree structure. When you request a particular network resource, you must identify the object's context so that eDirectory can find it. Similar to locating files by using a DOS directory path, context represents a list of container objects leading from the object to the Tree Root. NetWare 6 uses specific naming guidelines for creating an object's context.
)
Figure
3.10 Getting to know the real Fred.
NOTE
Novell recommends that before you implement eDirectory, you create a document that describes your naming standards. The eDirectory naming rules you're going to learn here work only if object names are consistent across the network. A naming standards document provides guidelines for naming key container and leaf objects, including users, printers, servers, volumes, print queues, and organizational units. In addition, it identifies standard properties and value formats. Consistency, especially in the naming scheme used for objects, provides several benefits:
A consistent naming scheme provides a guideline for network administrators who will add, modify, or move objects within the Directory tree.
A naming standard eliminates redundant planning and gives network administrators an efficient model to meet their needs, but it leaves implementation of resource objects open and flexible.
Consistent naming schemes help users identify resources quickly, which maximizes user productivity.
Consistent naming enables users to identify themselves easily during login.
There are two main types of context: current context and object context. Check it out.
Context
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 are 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 is not 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 section "Distinguished Names" 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 to a leaf object. Typically, at login, you'll want a workstation's current context set to the container that holds the user's most requently used resources.
In Figure 3.10, 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 3.10 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 3.11, our eDirectory tree has two Freds, but each has a different 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 we 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 allows you to precisely identify objects in your tree. The tree organization 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. Following are examples of naming types and associated values:
C = Country container
O = Organization container
OU = Organizational Unit container
CN = Common name (specifies a leaf object)
)
Figure
3.11 Understanding eDirectory context.
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 Common Name must be included in the request.
Now that you understand how eDirectory context works, review the naming rules associated with it:
Current context is a pointer to the eDirectory container that your Novell Client is currently set to.
An object's context defines its location in the eDirectory tree.
Each object has an identifier abbreviation that defines it for naming purposes, namely the following: C = Country, O = Organization, OU = Organizational Unit, and CN = common name (of leaf object).
Context is defined by listing all containers from the object to the Tree Root, in that order. Each object is separated by a period.
Context is important for logging in and accessing eDirectory resources.
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 (DN) and Relative Distinguished Names (RDN).
Distinguished 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 3.12, 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:
.CN=AEinstein.OU=R&D.OU=LABS.O=ACME
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. In other words, a relative distinguished name.
Relative Distinguished Names
A relative distinguished name 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
)
Figure
3.12 Building AEinstein's 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 (see Figure 3.13) the following:
.CN=AEinstein.OU=R&D.OU=LABS.O=ACME
To distinguish 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 wasn'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 (see Figure 3.14):
.CN=LEIA.OU=ADMIN.O=ACME
)
Figure
3.13 Building AEinstein's relative distinguished name.
As you can see, it's very important where you place your dots! Here's a quick summary:
All objects in an eDirectory name are separated by dots.
Distinguished names are preceded by a dot. This identifies them as complete.
Relative distinguished names are not preceded by a dot. This identifies them as incomplete.
Trailing dots can be used only in relative distinguished names because they modify the current context to be used. Each dot moves the context up one container as the distinguished name is resolved.
For a complete summary of eDirectory distinguished naming rules, refer to Table 3.4.
)
Figure
3.14 Using trailing periods to resolve Leia's distinguished name.
Table 3.4 Getting to Know Distinguished Naming
|
|
DISTINGUISHED NAMES |
RELATIVE NAMES |
|
What it is context |
Complete unique name |
Incomplete name based on current |
|
How it works from the object to the Tree Root |
Lists the complete path from the object to the current context |
Lists the relative path |
|
Abbreviation |
DN |
RDN |
|
Leading period required |
Leading periods allowed |
No leading periods |
|
Trailing periods allowed |
No trailing periods optional |
Trailing periods |
Now, let's step back into reality for a moment and explore the other eDirectory naming category—typeful names.
Typeful Versus Typeless Names
Typeful names use attribute type abbreviations to distinguish between the different container types and leaf objects in eDirectory names. All the examples to this point used these abbreviations to help clarify context, distinguished names, and relative distinguished names. Following are the most popular attribute type abbreviations:
C = Country container
O = Organization container
OU = Organizational Unit container
CN = Common name of a leaf object
These attribute types help avoid the confusion that can occur when you're creating complex distinguished and relative distinguished names. I highly recommend that you use them. Of course, like most things in life, they are 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 do, 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:
.Admin.ACME
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 (see Figure 3.15).
Well, here's the bottom line: which one is it? It's up to eDirectory. If you do not 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:
The leftmost object is a common name (leaf object).
The rightmost object is an Organization (container object).
All middle objects are Organizational Units (container objects).
)
Figure
3.15 Trying to understand typeless naming.
Although this works for most cases, it's only a general guideline. Many times, typeless names are more complex. Take the example in Figure 3.15, for instance. You 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:
Exception Rule 1: Container Objects—Many NetWare 6 utilities are intelligent enough to resolve typeless names, depending on what they are trying to accomplish. CX, for example, is used primarily for changing context. If you apply the CX command to a typeless name, it assumes the leftmost object is an Organization or Organizational Unit. This is because you can't change your current context to a leaf object. ConsoleOne is the best graphical utility for changing your context. In summary, here's how the example from Figure 3.15 would look with the CX utility:
CX .ADMIN.ACME resolves as ".OU=ADMIN.O=ACME"
Exception Rule 2: Leaf Objects—Similarly, resource-based utilities recognize the leftmost object of a typeless name as a leaf object. Many of these utilities are expecting to see a common name. The most prevalent are LOGIN, MAP, and CAPTURE. Here's how it works for the example in Figure 3.15:
LOGIN .Admin.ACME resolves as ".CN=Admin.O=ACME"
Exception Rule 3: Contextless Login—If you have Catalog Services and Contextless Login activated, eDirectory will resolve typeless names by offering the user a list from the eDirectory Catalog. (Note: NetWare 6 eDirectory does not support Catalog Services.)
There you have it. This completes the discussion of typeless names and eDirectory naming in general. As you can see, this is an important topic because it impacts all aspects of eDirectory design, installation, and management. No matter what you do, you're going to have to use the correct name to login 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).
TIP
As a world-class NetWare 6 CNA, you should always use typeful distinguished names in login scripts and capture statements. It is good form, and more importantly, some utilities still require naming attributes for administrative management.
Now you can complete your eDirectory adventure with a quick lesson in changing your current context.
Changing Your Current Context
A user's current context can be set in one of the following ways:
Before login, using the Name Context field on the Client tab of the Novell NetWare Client Properties (or Novell Client Configuration) window
During login, using the Context field on the eDirectory tab of the Novell Login window (which is accessed by clicking the Advanced button)
Using the CONTEXT login script command
Using the CX utility
It's best to set a user's context at login, so the user can have easy access to the network resources he or she uses the most. If a user wants to access resources located in a different context, he or she will need to use correct naming conventions. The next sections explore each of these four methods for changing a user's current context before, during, and after login.
Setting a User's Context Before Login
On Windows 95/98 and Windows NT/2000 workstations, you can set the workstation's current context before login by entering the appropriate context information in the Novell NetWare Client Properties window, as shown in Figure 3.16. The typeless distinguished name in the Name Context field sets the workstation's current context before login. It can be entered with or without a preceding period.
)
Figure
3.16 The Novell NetWare Client Properties dialog box.
To set up a workstation's current context before login, access the Network icon in the Windows 95/98 or Windows NT/2000 Control Panel, select the Novell Client for Windows, and then click Properties. When the Novell Client Properties dialog box appears, enter the current context in the Name Context field on the Client tab. If you're already logged in to the network, a faster way to change this field is to right-click the N icon in the system tray and to select Novell Client Properties from the pop-up menu. When the Novell Client Configuration dialog box appears, enter the current context into the Name Context field on the Client tab. (Refer to Chapter 4, "NetWare 6 Connectivity," for more information regarding Novell Client installation and configuration.)
Setting a User's Context During Login
On Windows 95/98 and Windows NT/2000 workstations, you can set a workstation's current context during login by entering the appropriate context information in the Novell Login window. To do so, when the Novell Login window is displayed, click the Advanced button and then enter the current context into the Context field on the NDS tab.
Using the CONTEXT Login Script Command
Setting a workstation's current context during login sets the current context that will be in effect for the user after the user attaches to the network. This prevents the user from having to use distinguished names to access eDirectory resources. Remember, eDirectory attempts to resolve relative distinguished names into distinguished names by appending the current context to the end of the relative name.
The CONTEXT login script command is similar to the NetWare 6 CX command-line utility, except that it does not support all the same options (that is, it sets only the current context). To set a workstation's current context during login, add this command to the appropriate Container, Profile, or User login script:
CONTEXT distinguished name
For example,
CONTEXT .OU=LABS.OU=NORAD.O=ACME
or
CONTEXT .LABS.NORAD.ACME
Note the use of a preceding period (.) to identify the distinguished name. This method is not workstation specific; it can be set for an individual or a group.
Using the CX Command
You can view information about an object's context or change your workstation's current context using the CX command-line utility (which is executed at the DOS prompt on a client workstation). CX is the key NetWare 6 utility for dealing with eDirectory context. It enables you to perform two important tasks: change your workstation's current context and/or view information about a resource's object context.
CX is a relatively straightforward command with a great deal of versatility. In fact, it's similar to the DOS CD command in its general approach. If you type CX by itself, the system displays your workstation's current context. This is marginally interesting, at best. CX really excels when you combine it with one or more command-line switches. Following are some of the more interesting ones:
CX—View your workstation's current context.
CX .—Move the context up one container for each period (.). Don't forget the space between CX and the period (.).
CX /T—View the Directory tree structure below your current context.
CX /A /T—View all objects in the Directory tree structure below your current context.
CX /R /A /T—View all objects in the Directory tree below the Tree Root.
CX /CONT—List containers only, below the current context, in a vertical list, with no directory structure.
CX /C—Scroll output continuously.
CX .OU=ADMIN.O=ACME—Change your current context to the ADMIN container of ACME.
CX /?—View online help, including various CX options.
CX /VER—View the version number of the CX utility and the list of files it executes.
Probably the most useful CX option is CX /R/A/T. I'm sure there's a hidden meaning there somewhere in the rodent reference. Or, if you lean toward the artistic side of the fence, try CX /A/R/T. And finally, for all you urbanites, there is CX /T/A/R. Regardless, the CX /R/A/T option displays the relative location of all objects in the eDirectory tree.
Understanding Inheritance
eDirectory rights can also be obtained through inheritance. In simple terms, inheritance occurs when rights granted to a trustee of a container flow down to all objects within and below the container. Inheritance minimizes the individual rights assignments needed to administer the network because object/property rights can automatically flow down the tree from containers to subcontainers to leaf objects. Inheritance is an automatic side effect of trustee assignments. Both object and property rights can be inherited.
Congratulations! This completes the lesson on eDirectory.
So far, you've explored the basics of NetWare 6 and the intricacies of eDirectory. Now you're ready for Prime Time:
NetWare 6 Connectivity (Chapter 4)
NetWare 6 File System (Chapter 5)
NetWare 6 Security (Chapter 6)
NetWare 6 Advanced Security (Chapter 7)
NetWare 6 Queue-Based Printing (Chapter 8)
NetWare 6 NDPS Printing (Chapter 9)
NetWare 6 Messaging Services (Chapter 10)
NetWare 6 Internet Infrastructure (Chapter 11)
Don't be scared—I'll be with you every step of the way. And we'll explore eDirectory many times throughout this CNA Study Guide.
Well, that's all there is to it — not really! Remember, the glass is half full, and you have taken a huge "gulp" in this chapter. Use this information wisely as you expand the horizons of your network. Next, the discussion of NetWare 6 administration features continues as you learn how to connect to this mysterious and exciting network Directory.
See ya there!