Chapter 12

Understanding how context affects an object’s behavior on the network is essential for effective network administration. For example, knowing a user object’s context is vital in implementing a container login script that the user will execute at login.

First, let’s review chapter 1 briefly. When we talk about a directory tree think in terms of a real tree. Like a real tree, all directory trees start out with the [ROOT]s. From here the tree branches out in various units, as shown in Figure 12-1. The first is the tree trunk, or Organization (EMA is the name of our organization in Figure 12-1). A Directory Tree can have multiple Organization objects but it’s not recommended except under special circumstances.. The thicker, heavier branches from the trunk are called Organizational Units (PROD and DEVELOPMENT in Figure 12-1). The smaller branches can be other Organizational Units. Eventually each of these branches have leaves on them. Leaf objects are various object types such as users, printers, and volumes.

First, we will see how the directory tree affects the network. When designing and administering your network, you will always fall back on the directory tree when you make updates and changes. Although a directory tree can be organized however you want to organize it, we will see that proper planning and a commonsense approach make future administration of the network easier and more efficient.

I cannot emphasize enough that the directory tree is the nervous system of the NetWare world. Every object on the network from client Windows NT workstations to the SYS: volume has an object in the directory. This means that the more complex the directory tree, the harder network administration. When organizing objects in the directory tree, remember to use logic and commonsense when planning the various branches, or Organizational Units. If you think you need only one Organizational Unit, then NDS gives you the option to create only one organizational unit, with the flexibility to create more in the future.

When evaluating an NDS tree’s proposed design, or an existing tree’s design, don’t forget that the "D" in NDS stands for "directory". Frequently, initial NDS tree designs are based on an organization chart that reflects management reporting relationships. An NDS tree based solely on that document would be fine if the network were supporting an organization with only a single location with no chance of expanding its physical plant structure and no plans for expanding its network.

For a more complex organization, a better prototype would be the inter-office mail distribution system’s route diagram. Usually, delivery of office mail is based on location codes, which may be further subdivided into floors, buildings, suites and rooms or cubicle, much the same way that the NDS tree is organized into containers and subcontainers. Although knowing the title of the sender or recipient may help expedite the speed of delivery, not knowing the physical location of the recipient’s "in" box will effectively stop the delivery. Managers and their immediate subordinates are not necessarily collocated.

NDS trees are designed to aid the delivery of networked services, just as inter-office mail is designed to provide physical mail deliver services, and thus should be designed similarly.

—by Dan Cheung, CNI, MCNE, MCT

For exam purposes, as well as real world everyday administration, you must know and live the NDS tree. For that reason we’ll go over this one more time to make sure you understand it upside down and inside out.

The first, or top-level object in the directory tree is the [ROOT] object. The [ROOT] is created when the first server is installed in the directory tree. Once it is created in cannot be deleted, renamed, or moved elsewhere in the directory tree. Since the directory is hierarchical in nature, the [ROOT] object has other objects under it, or within it. Figure 12-2 shows the start of a directory tree. A globe represents the [ROOT]. Below the [ROOT] we have our Organization object. Remember that the [ROOT] object can hold only specific container objects. The two types of container objects that can exist directly under [ROOT] are Country and Organization objects. Only one leaf object can exist directly under [ROOT], an Alias object, which must point to another Country or Organization object in the tree. An Alias object pointing to any other type of object is not allowed at this level.

Container objects are just that; they contain other objects. (See Table 12-1 for a complete list of NetWare object types.) A container object in the directory tree holds other NDS objects. As illustrated in Figure 12-3, the hierarchical fashion of the directory tree takes shape when you start to branch out with the various container objects. NetWare has three types of container objects: Country, Organization, and Organizational Unit.

The Country object is optional and not widely used. It can be used to designate a locale for the tree if the NDS tree is being designed with eventual merging into a global WAN in mind (this is not a typical scenario and beyond the scope of this chapter). The Organization object is required, and can be the company name, a location, a division of a company, or even a college or university. Although multiple Organizations can exist in a single directory tree, most have only one. (There are some instances when two or more are needed, but those are special cases not discussed here.) The Organizational Unit is similar in the sense that it is a branch in the tree. There can also be multiple Organizational Units per directory tree. Organizational Units can contain other Organizational Units. This is where network administration can become complicated when you have multicontext environments. The final piece to the tree is the Leaf object. A leaf object represents an individual entity or resource in the tree like a printer, user, or server. Once you reach a leaf, there is no further branching of the tree. In some cases you may have duplicate leaf objects in different Organizational Units. However, this is not recommended, because it may cause problems in searching for resources. The thing to remember here is that location makes the difference. You will notice that managing an object in your NDS tree is a matter of location, location, location.

Next we’ll discuss how object location in the directory tree affects network operation.

As with any other NDS object, each leaf object has a name, called a Distinguished Name. Its Distinguished Name also uniquely identifies it, including its location in the directory tree. With NetWare you always have to think of the object’s name in terms of location in the directory tree. For example, in real-life, a person’s name is Bob Smith and in NetWare terms, his Distinguished Name would be Bob Smith on 123 Main St., Anytown, U.S.A.

This way of naming isolates the object down to its location or context within the directory tree. Context tells NetWare the location of an object. In the Bob Smith example, his context is 123 Main St., Anytown, U.S.A. If he moves to 456 University Dr., Anytown, U.S.A., then his context has changed.

When you consider two different objects in a directory tree, you have to understand the concept of context. Figure 12-4 shows a directory tree containing two objects with the same Common Name, which implies that their Distinguished Names are different. Otherwise, they could not exist in the same directory tree.

In Figure 12-4 notice that the two objects are both named HP_LJ_5. That is, their Common Names are HP_LJ_5 and HP_LJ_5. One resides in the Accounting container and other resides in the Administration container. The difference is in their locations. The Distinguished Name of one is HP_LJ_5.ACC.EMA, and the other is HP_LJ_5.ADM.EMA. They reside in different containers so they can have the same common name, just as Michele, who lives in Illinois, and Michele, who lives in Maine, have the same first name, but their respective contexts identify them as two different people.

The key point here for exam and real-life purposes is to make sure you take context into account when designing your login scripts, and overall resource access. Next we will look at how the directory tree can affect NDS planning and design.

When you first draw out a directory tree for your network, you will have to know how many branches you need. To do this, you have to consider a couple of things. First, how many objects will you have and how do you want to group them? Once you determine this, you can draw out your basic directory tree. The other thing you need to do is think ahead to future network growth. Does your design have the flexibility to grow and change with your network?

Remember that context is your location in the directory tree. Where you reside, and where other objects reside, determines how an NDS object has to be configured. When configuring how users will access resources you have to keep in mind where the resources reside. An example of this is a printer that may exist in a different Organizational Unit in the directory tree. Figure 12-5 shows our directory tree with a user in the Accounting container and a printer that in the Administration container. If user BSmith wants to print a document on the printer in the Administration container, then BSmith would be printing to a container outside of his context. In this case would you have to change BSmith’s context? No You can use the name of the printer: HP_LJ_5.ADM.EMA.

There are two types of contexts within Novell Directory Services. The first is current context. Current context is where you currently are in the directory tree. Even though BSmith’s context is the Account container (ACC.EMA), he could change his current context to ADM.EMA.

The other type of context is object context, which is where the object resides in the directory tree. The object context is the long form of an object’s name. For example, Bsmith’s object context is CN=BSmith.OU=ACC.O=EMA. Therefore, you can identify the object context by starting with the object and listing every container back to the [ROOT].

A new feature of NetWare 5 is contextless login. With previous versions of NetWare you had to know your location in the directory tree, or have the proper context to login. As we have discussed, an object can reside anywhere in the directory tree. With previous versions of NetWare you had to be set up in the correct context or the login process would fail to find the User object.

With NetWare 5, users can log in anywhere on the network, regardless of context. This is done with Catalog Services. We will not go into detail here but for the exam know that NetWare 5 has contextless login. With contextless login you can authenticate from any point on the network simply by typing your login name and password, without knowing the location of your User object in the NDS tree

NetWare 5 has some shorter methods than those we’ve mentioned for accessing the various resource types. There are a couple of naming concepts to become familiar with, and different ways to get to the same part of the directory tree. Here we will look at these different naming concepts and some useful things to know for navigating the NDS directory tree.

For some of you this may seem like a redundant review, but for concise exam preparation we must cover this again. The directory tree has some naming concepts that engineers and administrators need to be familiar with.

.CN=TRobins.OU=MKTNG.OU=HDQTRS.O=EMA.

or

TRobins.MKTNG.HDQTRS.EMA

With Distinguished Names there is also a short form known as the Relative Distinguished Name. The Relative Distinguished Name is a shorter, incomplete form of a Distinguished Name. Now that I have you thoroughly confused, let me explain.

The other type of naming concept to know for the exam is Typeful Naming. As we have seen, there are different ways to spell out a complete Distinguished Name. One way uses the attribute abbreviations. For example, Trobins is the Common Name, or CN. The Organizational Units are OU. Typeful Names are basically names that include the attribute abbreviation along with the name of the object. For example:

.CN=Bsmith.OU=HOME.O=PLATE

A Typeless Name is a name without the attribute abbreviations. For example:

.BSmith.HOME.PLATE

These two types of naming are essentially telling us the same thing. The typeful name simply denotes the object type, which can help us avoid confusion when there are container and leaf objects in the same tree with similar or identical names.

You may have noticed that there are sometimes dots preceding or following the name. Let’s review how the dots make up the various name types.

Table 12-2 shows the basic relationship between the trailing and leading dot.

Here is a summary of how dots are used in NetWare object names:

• Distinguished Names must have a leading dot. The leading dot means that the name is complete and includes all containers leading to [Root].
• Trailing dots can be used only with Relative Distinguished names because they modify the current context. A trailing dot moves the context up one level in the tree.
• Other dots within a name are simply separators. They separate each object in the tree’s hierarchy.

When setting up and designing your tree, there are many things you must take into account. The goal of proper NDS tree design is to make it simple for your users to access resources while at the same time making it easy for you to administer.

To design and implement a successful NDS tree, you must organize the network resources carefully. This means placing resources as near as possible to the users who need access to them. The hierarchical nature of the NDS tree allows this to be done. One problem some administrators run into, is organizing too much. Don’t break your tree up into too many branches. Using common sense and good organization will make the tree come together.

When considering where to place objects in your directory tree, keep the login process in mind. When designing login scripts (which we will talk about more in detail later) you have to be careful about which resources a certain user would need. The more contexts you have to deal with, the more complicated your login script.

When designing login scripts you want to be able to give access to resources in a fashion that is simple to administer and change.

Figure 12-7 shows a directory tree with our user TROBINS in the HDQTRS container. We also see a DOWNTOWN container that has some resources such as printer, volume, and server.

Now if TROBINS works in the downtown office where the printer, server, and volume are that he accesses daily, it would make more sense for his User object to be in the DOWNTOWN container. On the flip side, if TROBINS is a user who works at headquarters, but accesses resources in the downtown office only occasionally, then the placement of his User object shown in Figure 12-7 may be appropriate. The main thing to remember is to keep users near the resources they access most often in the directory tree.

When it comes to configuring your directory tree for a multicontext environment, be sure to use proper naming when giving rights to users. The first step is to make sure you have the proper context set for a user. As long as you know where the user resides, and the current context is set appropriately, assigning the appropriate rights is easy. This is especially because the NWADMIN application is GUI-driven.

When it comes to login scripts, especially in a multicontext environment, you have to be sure you use the proper naming to get to the various resources that are needed by a user for a group of users.

The easiest way to do this is to use the Typeful Distinguished Name when identifying objects in the NDS tree. For example, to capture a printer in a login script, I would use the Typeful Distinguished Name. That way if anyone else has to look at the login script, they can identify exactly what the NDS path is for that object.

• There are different types of login scripts. Make sure you understand what each login script is and how it differs from the others. The login scripts are as follows, in order of execution:Container login scripts
• Profile login scripts
• User login scripts
• Default login script (executes only if a user login script does not exist)

Container login scripts are login scripts that customize settings for all users in a container. Profile login scripts are a way to customize certain items for groups of users. The profile login script allows administrators to have users share a common login script even though they aren’t in a common context or members of the same group objects in the directory . User login scripts are scripts with individual login properties. The default login script is executed for any user who does not have an individual user login script.

This part of the Administration exam is by far one of the easier parts as long as you nail a couple of things. The first is the different types of naming: Distinguished, Relative Distinguished, Typeless, and Typeful.

The second thing is to understand how context affects object interaction in the directory tree. Remember that there is object context, or where an object resides in the directory tree. There is also current context, which is the current location in the directory tree.

We should also be sure to understand how the login scripts work, and the different types of login scripts. This will not be seen as much on the exam, but it is good to know when looking at the scenario questions.

• The directory tree is the nervous system of the NetWare world. Every object on the network has an object in the directory. The more complex the directory tree, the harder network administration is.
• The first, or top-level object in the directory tree is the [ROOT] object. The [ROOT] is created when the first server is installed in the directory tree. Once it is created in cannot be deleted, renamed, or moved elsewhere in the directory tree. Since the directory is hierarchical in nature, the [ROOT] object has other objects under it, or within it. The two types of container objects that can exist directly under [ROOT] are Country and Organization objects. Only one leaf object can exist directly under [ROOT], an Alias object, which must point to another Country or Organization object in the tree.
• Container objects hold other NDS objects. The hierarchical fashion of the directory tree takes shape when various container objects branch out. NetWare has three types of container objects: Country, Organization, and Organizational Unit.
• The Country object is optional and not widely used. It can be used to designate a locale for the tree if the NDS tree is being designed with eventual merging into a global WAN in mind.
• The Organization object is required, and can be the company name, a location, a division of a company, etc. Although multiple Organizations can exist in a single directory tree, most have only one.
• The Organizational Unit is a branch in the tree. There can also be multiple Organizational Units in the directory tree. Organizational Units can contain other Organizational Units. This is where network administration can become complicated when you have multicontext environments.
• The Leaf object represents an individual entity or resource in the tree like a printer, user, or server.
• Each NDS object has a Distinguished Name, which uniquely identifies the object, including its location in the directory tree. With NetWare, always think of the object’s name in terms of its location in the directory tree.
• Context is your location in the directory tree. Where you reside, and where other objects reside, determines how an NDS object has to be configured.
• There are two types of contexts within Novell Directory Services: current context, where you currently are in the directory tree, and object context, where the object resides in the directory tree.
• A new feature of NetWare 5 is contextless login. With previous versions of NetWare you had to know your location in the directory tree, or have the proper context to login. With NetWare 5, users can log in anywhere on the network, regardless of context. With contextless login you can authenticate from any point on the network simply by typing your login name and password, without knowing the location of your User object in the NDS tree.
• The Distinguished Name is the complete directory path from the object back to the [ROOT].
• The Relative Distinguished Name is a shorter, incomplete form of a Distinguished Name. A Relative Distinguished Name is from the object up to the current context.
• Typeful Names are names that include the attribute abbreviation along with the name of the object. A Typeless Name is a name without the attribute abbreviations.
• Distinguished Names must have a leading dot. The leading dot means that the name is complete and includes all containers leading to [Root].
• Trailing dots can be used only with Relative Distinguished names because they modify the current context.
• Other dots within a name separate each object in the tree’s hierarchy
• Place resources as near as possible to the users who need access to them. When considering where to place objects in your directory tree, keep the login process in mind. The more contexts you have to deal with, the more complicated the login script.
• When configuring a directory tree for a multicontext environment, be sure to use proper naming when giving rights to users. The easiest way to do this is to use the Typeful Distinguished Name when identifying objects in the NDS tree.
• There are four different types of login scripts. They are, in order of execution: Container login scripts, Profile login scripts, User login scripts and Default login script.