Special Edition: Using IntranetWare
Chapter 4. Novell Directory Services (NDS) and NetWare Administrator

• The Novell Directory Services (NDS) Architecture
  To begin to understand NDS, you must examine the components that make up an NDS database and how they are constructed to form a representation of the enterprise network.
• NDS Objects
  Network resources are represented in the NDS database by different types of objects, each with properties appropriate to its function.
• NDS Naming Principles
  The way in which an object is uniquely identified by a compound name defines its exact location in the NDS hierarchy.
• NDS Utilities
  NetWare includes NDS administration and navigation tools for use on various client platforms.

The original concept behind NetWare was to unite a collection of personal computers by connecting each of them to a central computer that provided communications and storage services for all. Users could work on the same data and share the same hardware simultaneously. When the concept grew popular, the departmental networking model was applied to every department, soon resulting in a corporate internetwork composed of many or even hundreds of servers.

Originally, NetWare required that each server be administered individually. Access to the resources controlled by a server was provided by setting permissions in a flat-file database called a bindery. A user that required access to every server in the company needed a separate account in each bindery. As networks grew larger, the bindery concept became increasing difficult to administer.

Novell Directory Services, introduced as part of the NetWare 4.0 release, addressed the problem of multiple-user accounts by replacing the bindery with an object-oriented database that spans the entire network. Incorporating all NetWare resources and their users into a single, hierarchical database, NDS unites all of an organization's server-centric departmental networks into a single enterprise network. In this chapter, you learn about the basic principles with which an NDS database is constructed and utilized.

The result of using NDS is that users have a single account with which they can gain access to any server or other NetWare resource in the enterprise. A single account means one login instead of many, and a single point of administration for the network support staff.

IntranetWare expands the role of the NDS database even further. TCP/IP services, such as the NetWare Web and FTP servers, use NDS accounts to control user access to specific intranet applications and resources. Developers of third-party applications can even create their own customized extensions to the NDS database, which can provide authentication and access control services for whatever resource is provided by the application.

The NetWare operating system includes the tools and utilities with which you create, access, and maintain the NDS database. Chief among these is NetWare Administrator. In NetWare 4.11, NetWare Administrator is positioned as the central administrative utility for Novell Directory Services. Many other utilities are launched from Administrator's menus, and the program functions as the front end for the NDS database itself.

Understanding NDS Architecture

Novell Directory Services is a database of the resources found on a NetWare network, the users that access the resources, and various logical groupings that are used to facilitate network administration tasks and structure the database. NDS is designed to make the components of a large enterprise computing network accessible and comprehensible to the people that use them.

The fundamental unit of the NDS database is the object. The entire database is composed of objects that represent physical or logical entities. Every NetWare server, for example, is represented by an object, as is every volume on that server. Every NetWare user is also represented by an object, and so are non-physical elements, such as user groups and user profiles. Other objects represent printers, print servers, and print queues.

The NDS database is therefore composed of many different types of objects. Each object type is distinguished by its own set of properties. A property is a field associated with an object type that is designed to hold a particular type of information suited to the needs and characteristics of the object itself.

A user object, for example, has properties designed to hold information about the identity of the user and the specific network resources to which the user has been given access, among other things. A group object, on the other hand, has some different properties, most notably a list of the user objects that belong in the group.

The data associated with the properties of a specific object are called the values for those properties. Therefore, a user object will have a property in which the user's name is stored. The value for that property might be John Smith in one user object, and Jane Doe in another.

Figure 4.1: All NDS objects are composed of properties, and each property can have a specific value.

The NDS database is located on NetWare servers scattered around an enterprise network. When an application on a client computer requires access to a network resource, the NetWare client sends an access request to the NDS database using a proprietary Novell Directory Services protocol. NDS processes the request and then either grants or denies the client access to the resource.

The NDS Hierarchy

The NDS database is structured much like the directory tree used by most file systems. It stems (perversely) from a root at the top of the tree (written as [ROOT]), and has objects arrayed in branches in a hierarchical fashion, as shown in Figure 4.1. The structure of the tree is designed by the administrator of the network. The objective is to create a tree that represents the networking infrastructure of the entire enterprise in a logical manner.

To facilitate the creation of the structure, there are two basic types of NDS objects: container and leaf. Leaf objects are those described earlier, that is, the objects that represent the actual building blocks of the network. Container objects, not surprisingly, exist only to hold other container objects and multiple leaf objects.

Container objects are used to create the logical divisions that form the structure of the tree. The two most commonly used container objects are organizations and organizational units. Organizations can only be located at the top of the tree, and organizational units form the layers beneath.

Figure 4.2: The NDS tree hierarchy should be designed to facilitate the needs of both users and administrators.

A typical NDS tree design uses these container objects to represent the natural divisions of the enterprise. You can use containers to represent the various branch offices of your company, the floors of your building, or the departments in your organization. The guiding principle behind NDS tree design is to locate user objects in the vicinity of the network servers and printers that they use every day. The tree should also be designed so that both users and administrators can locate objects representing resources in remote areas of the enterprise in an intuitive manner.

Containers also act as logical groupings of the objects within them. Just as rights flow downstream in the NetWare file system, access rights assigned to a container object are inherited by all of the objects in the container. You can therefore use containers like the groups found in NetWare binderies, and even create container login scripts that are executed by every user object in the container during the login process.

Partitions and Replicas

Every client workstation on the enterprise network must access the same NDS database. Because the system is designed to accommodate very large networks with many thousands of users, clearly it would not be possible to have everyone access the database on one server. Copies of the database, called replicas, are therefore situated on NetWare servers throughout the enterprise in order to balance the load.

All NetWare 4.x servers run NDS, but this does not mean that every server has a complete replica of the entire database stored locally. Because of this, and because of the continual updates that are copied to replicas all over the network, there is always a great deal of background communication traffic going on between NDS servers.

When an enterprise network encompasses multiple locations connected by WAN links, you can split the NDS database to optimize communication between servers. In most cases, users access the resources on their local servers more frequently than those at remote locations. It, therefore, makes sense to store the part of the NDS tree that represents those resources at that location. To do this, the database is split into segments called partitions. Each partition is stored on a different server, and is replicated on servers at the other locations.

Thus, every user has access to the entire NDS database at all times, and the partitions and replicas provide fault tolerance to the NDS system. When an enterprise NDS database is properly partitioned and replicated, any server on the network can fail without interrupting client access.

The way that the database is partitioned, and the number and types of replicas that are used, are decisions that are, again, left to the network administrators. See Chapter 6, "Using the NDS Manager," for more information on creating partitions and replicas in a logical and efficient manner.

Understanding the Directory Schema

The rules that define the object types permitted in the NDS database, and the properties associated with each type, are known as the directory schema. NetWare includes a default set of schema that represent the resources commonly found on all NetWare networks and the containers used to organize them in the NDS tree. However, it is possible for other applications to extend the schema to create object types of their own. The basic components of the directory schema are the following:

• Object classes
• Attribute types
• Attribute syntaxes

Every object in the NDS database is defined by one or more object class. The object classes are basic templates that govern the creation and use of a particular object type. Object classes define the properties (or attributes) that the final object will possess. They are chosen from a set of attribute types, which are based on a collection of attribute syntaxes. The following are some of the attributes provided by object classes:

• Super classes—These are the superior object classes whose attributes are inherited by other object classes. The schema have a class hierarchy of their own that is independent of the tree's object hierarchy. The process by which an object type is defined is simplified through the specification of super classes as the source of more general object attributes. Individual attributes that are unique to this object are then defined explicitly. For example, the Device super class contains attributes that are inherited by object classes that represent network devices, such as servers and printers. Some of the attributes in a super class are also inherited from the Top class, which is the uppermost class in the hierarchy and the super class of all other super classes.
• Containment classes—These restrict a particular object's location in the NDS tree. An example of a containment class is the attribute of an organization object that states that it can only be contained by the Root or by a country object.
• Naming attributes—These impose restrictions on the name that can be assigned to a particular object. A naming attribute is used, for example, to restrict the name of a country object to two characters.
• Mandatory/optional properties—These are attributes that determine whether particular properties of an object must be assigned a value when the object is created, or can be left blank. For example, the last name property of a user object is mandatory.

Attribute types dictate the nature of the data that can be supplied as a value for a particular property of an object. For example, the property of a user object that stores the user's telephone number is restricted to numerical values by an attribute type. Attribute types also indicate the length of the property's field, and whether or not it can contain multiple values. In addition, attribute types specify the attribute syntax that are to be applied to that property.

Attribute syntax defines the rules that are applied to the data when the same property is compared in multiple objects. If, for example, you search the NDS database for all users that have been registered as working in the Sales department, the property in which the departmental information is stored will be assigned an attribute syntax that causes the case of the value to be ignored. Thus, the results of the search will include users that have been registered as belonging in the Sales department, as well as those in sales. In the same way, an application can successfully compare telephone numbers, even when some of the values contain hyphens, and some don't (that is, 555-1234 as compared to 5551234).

Certain modules included in the IntranetWare package create their own NDS objects, and there are now many third-party products that extend the schema to create new object types for use by their applications.

To aid in this process, NetWare provides a collection of object classes, attribute types and syntax called the base schema, which application developers can use as templates for the creation of object types based on the general categories of objects found in the default NDS database. To the base schema, the developer adds additional super classes, which further refine the attributes of the object.

Some network backup software products, for example, extend the schema to create an object type for the job queue in which pending backup and restore procedures are stored for execution at specific times. This object functions a lot like a print queue, and very likely uses some of the same super classes as the NetWare print queue object. The application extends the schema and creates the object during the installation process, and such utilities as NetWare Administrator are able to view and manipulate the new object types by accessing an snap-in module provided by the application developer.

Once created, the new object is addressed by the backup software, using standard NDS API calls, enabling it to store application data in the NDS database itself. This data can later be used by the software in any way that it sees fit. By allowing new object types to use pre-defined elements like object classes and attribute syntax, Novell has designed NDS to facilitate this kind of proprietary extension, and has made the necessary programming tools publicly available.

The goal of NDS, as repeatedly stated by Novell, is to create a universal network directory that can accommodate all of the computing resources used by an enterprise, whether they run Novell products or not. The NDS database is sometimes referred to simply as the Directory for this reason. (The capital D is used to distinguish the NetWare Directory from a typical file system directory.) Its ultimate intention is for Novell Directory Services to be used as the Directory for the Internet itself.

Objects and Their Properties

The schema provides a menu of object types, with varying properties and purposes, that are used to populate the NDS tree. In NetWare Administrator, each object type is represented by its own icon, and the tree display creates a representative depiction of the entire network that the user can easily navigate and manipulate.

Novell Directory Services is a part of nearly every transaction that takes place on a NetWare 4.x network. The core NetWare file and print services use NDS objects to regulate and authenticate access to network volumes and printers. In order for a user to access a particular volume on a NetWare server, for example, a relationship must be established between the user's object and the corresponding volume object in the NDS database.

The NDS tree contains more than just user and volume objects, however. Table 4.1 defines no less than thirty-two object types. Maintaining and documenting the complex matrix of relationships between all of these objects is the primary function of the NDS database. When it functions properly, it is almost invisible; when it doesn't work, NetWare grinds to a screeching halt.

Object Icon	Object Name	Description
	AFP Server	An AppleTalk Filing Protocol server. Create this object to document the existence of an AFP server on your network.
	Alias	An object that represents or points to another object. Create this object when you must list an object in the directory tree by a different name and/or in a different part of the directory tree.
	Application (DOS)	An object representing a networked DOS application that is delivered to clients using NetWare Application Manager.
	Application (Windows 3.x)	An object representing a networked Windows 3.x application that is delivered to clients using NetWare Application Manager.
	Application (Windows 95)	An object representing a networked Windows 95 application that is delivered to clients using NetWare Application Manager.
	Application (Windows NT)	An object representing a networked Windows NT application that is delivered to clients using NetWare Application Manager.
	Auditing File	An object used to administer the access rights of NetWare auditing logs.
	Bindery Object	An object created as a result of an upgrade of a NetWare 2.x or 3.x server. You can't create this type of object directly, and it has no corresponding type among the NetWare 4.1 list of leaf objects.
	Bindery Queue	A queue on a NetWare 2.x or 3.x server that's referenced in the NDS directory tree.
	Communications Server	A server that provides communications features, such as shared modems and faxing.
	Computer	An object created to document the existence of a non-server computer on your network.
	Country	A container object that represents a country.
	Directory Map	An object created to reference or point to a particular directory on a network file server. NetWare-aware utilities can then reference the literal directory, using the directory map object name.
	Distribution List	A collection of objects that have Message Handling Service (MHS) mailboxes. These objects can be addressed together when sending MHS messages.
	External Entity	An object that references something that exists outside the directory tree.
	Group	An object that represents a group of users. By using group objects, you can grant users access to files, directories, printers, and so on, collectively rather than individually.
	License Certificate	An object that is created whenever an application is installed that can use NetWare Licensing Services for software metering.
	Licensed Product	A container used by NetWare Licensing Services to contain license certificate objects for the purpose of software metering.
	LSP Server	An object that is created when you register a License Service Provider into NDS with the NetWare Licensing Service modules loaded.
	Message Routing Group	A collection of MHS servers that exchange messages with each other.
	Messaging Server	A server that runs the MHS NLM and stores messages.
	NetWare Server	An object that represents a server running NetWare.
	Organization	A container object that represents an organization or company.
	Organizational Role	An object that represents a job responsibility that requires associated access rights to network resources. As with a group, you can grant users access to directories, files, shared printers, and so on, by associating the users with the organizational role object.
	Organizational Unit	A container object that represents a department or division of an organization or company.
	Print Queue	An object that represents a print queue, used to store print jobs that are waiting to be printed on a shared printer.
	Print Server	An object that represents a print server, which controls flow of print jobs from print queues to shared printers.
	Printer	An object that represents a shared printer.
	Profile	An object that stores a login script (set of instructions automatically executed at login time) that you can assign to users.
	Template	A leaf object that is used to facilitate the creation of multiple leaf objects with similar characteristics.
	User	An object that represents a human being who logs in to, and uses, the network.
	Volume	An object that represents a disk volume installed in a NetWare file server.

Different object types have different sets of properties, depending on the object's purpose. The properties defined by the directory schema are designed to contain information that can be placed into four basic categories:

• Names
• Addresses
• Descriptions
• Memberships

Certain properties are designated (by an object class) as being mandatory. A value is required for these properties in order for the object to fulfill its basic function. All objects have a name property, which obviously is required to distinguish one object from another of the same type.

Many properties contain optional properties, though, that are frequently ignored by network administrators. Address information, for example, need not be limited to the network address that identifies specific computers on the network. You can also use the NDS database to store personal information about users, such as street addresses and phone numbers, serving almost as a human resources database, if desired.

When NDS objects represent pieces of equipment, such as servers and printers, adding values to properties describing the nature of the device and its location can often make life easier for everyone who uses the equipment. How many phone calls to the help desk could be saved if every user could tell which of the many printer objects in the tree is the color printer on the third floor?

Perhaps the most important information stored in the property fields of most objects concerns memberships, that is, a listing of each object's relationships with other objects. A user object, for example, contains properties that list the groups of which the user is a member, the files and directories to which the user has rights, and the other users with which he has a security equivalence, among other things. Conversely, a group object has a list of its members, and a volume object has a list of its trustees.

Many objects contain properties that are highly specialized, designed to hold data that is suitable only for the object's specific function. You will learn about the creation and use of the various object types throughout this book as you examine the specific networking processes with which they are concerned.

Understanding NDS Object Naming

Every object in the NDS tree must be given a name when you create it, but if you have an enormous NDS database with hundreds of servers and thousands of users in it, chances are you will have some duplication, such as two user objects called SmithJ. Fortunately, Novell Directory Services enables you to create two objects of the same name as long as the two objects are not located in the same container object.

When there are two identically named objects in one NDS tree, there must also be a way of distinguishing them. NDS is capable of uniquely identifying any object, based on its context in the NDS tree. An object's context is simply its location in the tree expressed as a complete hierarchical listing of the containers that hold the object, extending all the way back to the [ROOT] object.

Distinguished Names

Suppose that there are two User objects with the name SmithJ, one in the Accounting department, and one in Sales. To uniquely identify each of these users, you must use a complete NDS name, listing all of the containers in which the object resides. This is also known as the object's distinguished name, (DN). A distinguished name consists of the object name itself, followed by the name of the object's immediate container and then all of the other intermediate containers between the object and the root, in ascending order. Each object name is separated from the others by a period. Thus, the distinguished name of SmithJ in the Accounting department would be:

This is easily differentiated from SmithJ in the Sales department, whose distinguished name would be:

The name of the user object alone is called a relative distinguished name (RDN), or a partial name. Objects in a distinguished name that are farther away from the [ROOT] object are said to be less significant; those closer to the [ROOT] are more significant. Thus, East Wing is the least significant container object in the distinguished name SmithJ.

The NDS Context

NetWare's NDS clients expand all object names into their full distinguished names before any communication is sent to the NetWare server. When you log in to your NDS tree by specifying your user object name and password, the client appends your current context to the object name before it is sent to the server.

Your context, which is specified in your client software (either in a NET.CFG file or a Windows registry entry) is the full distinguished name of your user object, minus the actual leaf object name. The primary function of the context is to insulate users from the need to specify objects' long distinguished names whenever possible.

The context is also applied when users access network resources. If SmithJ wants to access a server or a printer that is located in the same container as his user object, he merely has to specify the name of the desired leaf object, and his default context is, again, automatically appended.

This is why you should make every effort, when designing your NDS tree, to locate user objects in the same container as the server and printer objects that the users access on a regular basis. The client's name context is used as the default whenever a user specifies any object name in an NDS-aware application.

Thus, SmithJ (in Accounting) would have East Wing.Accounting.NY.CorpNet listed in his client software as his default context. Logging in as simply SmithJ, he will never be confused with his colleague in Sales because his context is automatically sent along with his user object name.

Typeful and Typeless Names

There is another aspect of NDS notation that is included in a distinguished name. The DNs specified in the earlier examples have been typeless names, so called because they do not include the abbreviations for each object type. Typeful (or typed) names included an object type specification for each object listed in the name. The abbreviations used for NDS object types are as follows:

Therefore, the typeful version of the distinguished name SmithJ would be noted as follows:

Typeful distinguished names are always supplied to the NetWare server by an NDS client, but it is usually not necessary for the user to include the abbreviations when specifying the name of an object because the client uses a default typing rule to apply the abbreviations itself. In most cases, the defaults are correct.

The default typing rule states that, for any fully distinguished name supplied by a client, the least significant partial name will be a leaf object (causing the CN= abbreviation to be prepended to it), the most significant partial name will be an organization (O=), and all of the partial names in between will be organizational units (OU=).

The default typing rule works out very well, in most cases, but if you have country objects in your NDS tree, it may be necessary to identify them as such by adding the C= abbreviation to the country object in your distinguished names. If only one partial name out of a full DN is typed, then the default typing rule is applied only to the partial names that are typeless. This means that if you supply the following DN to an application:

the default typing rule will be applied to expand the name as follows:

The country object designation will not be modified by the application of the default types to the other names. However, the country object name will be tested to ensure that it is exactly two characters long. If it is not, the name will be rejected.

Context Qualifiers

When a name context is specified in the configuration of an NDS client, it is always appended to any partial name specified in a client application. It is up to the user to be aware of this fact, and to behave accordingly. Suppose that SmithJ wants to access a printer whose object is in another container. His computer specifies the following as his name context:

and he types the following as the path to the printer object:

His client will end up sending the following DN to the server:

This name will be rejected by the server as pointing to a nonexistent container because what SmithJ really wanted was for the North Wing container to replace the East Wing container, as follows:

The only way to appropriately specify the name of the desired object, in this case (without typing out the entire name), is to use a context qualifier. A context qualifier is a means of instructing the client to append only a part of the name context to the given input.

The use of context qualifiers is never mandatory. They are just another convention designed to help users avoid typing long NDS names.

Using Trailing Periods

To use one type of context qualifier, you add one or more periods to the end of a partial name: each period represents one container that should be omitted from the context when it is added. Thus, in the example found in the previous section, the way to correctly specify the location of the printer object would be:

The period after North Wing indicates that the first container (East Wing) should be left off the context when it is appended to the name. Two periods would cause both the East Wing and the Accounting containers to be omitted, resulting in the following path:

This technique is also known as trimmed masking.

Using a Preceding Period

When you add a period in front of a partial name, the NDS client utilizes only the object type abbreviations from the context, replacing the names with those specified by the user. This type of context qualifier is often misunderstood because the name that you supply must account for every container level specified in the context.

For example, if a user called DoeJ had the name context in her NDS client configured as:

she could specify the location of an object in a different container by using the following name:

The preceding period would cause each container in her name to be given the object type abbreviation of the equivalent container in her context. Thus, the full distinguished name that the server would send to the client would be:

The three containers (Sales, LA, and US) are typed by the context qualifier, and the leaf object name is assigned the abbreviation CN by the default typing rule. Without the preceding period, all of the names would be typed by the default rule, and the US container would be mistakenly identified as an organization object instead of a country object. This is an important distinction, because even if the object name US is correct, the server will reject it if the object type is wrong.

This technique (which is known as masking) must be used carefully because the object types are applied to the name supplied by the user from right to left. This means that if DoeJ had specified only the name

(perhaps because both her context and the desired object had US as their most significant container), the DN sent to the server would appear as follows:

The client does not check to see if this is a valid name (which it isn't), or even if it specifies a leaf object (which it doesn't). It is up to the server to reject this name by generating an error message to the client.

Understanding Bindery Context

The NDS context has thus far been treated solely as an element of a NetWare client configuration. However, the term context also has relevance on the NetWare server.

Although it is recommended that you use NDS clients on your NetWare 4.11 network, there are several reasons why you might use NetWare's bindery emulation feature. Bindery emulation, as the name implies, refers to the capability of NDS to support standard NetWare 2.x/3.x bindery logins.

You may be in a situation in which you have a large number of non-NDS client workstations, and the transition to NDS client software will take place over an extended period of time. These workstations would probably be running the NetWare Shell (NETX) on DOS or Windows 3.1 or the Microsoft Client for NetWare Networks on Windows 95 without the additional NDS support module.

You may even have clients that are running NDS-capable software, such as the NetWare DOS Requester (VLM) or one of the Client32s, but which are using bindery emulation until the machines can be reconfigured or the users trained.

When clients log in using bindery emulation, they (figuratively) log in to a server, not an NDS tree. However, because there is no bindery in NetWare 4.x, they are, in fact, logging in to a particular context of the NDS database as found on a NetWare server.

A bindery client cannot see the contents of the whole NDS tree. It is only capable of seeing and accessing the objects that are located in containers that have been specified as part of the bindery context.

The bindery context, as configured on a NetWare server, should mainly consist of the containers in which the server and print objects needed by the bindery clients are located. Unlike a workstation, which can only have a single context, a server can have up to sixteen containers specified as its bindery context. Multiple bindery contexts would typically be needed when bindery users require access to servers and printers found in various containers.

Setting a Server's Bindery Contexts

When you install a NetWare 4.11 server, by default it receives a master or read/write replica for the NDS partition that stores its directory tree context. It is essential that a replica containing the context used by bindery emulation clients be present on the server they use for their primary login. Because bindery emulation clients log in to a server and not a tree, they do not have access to any part of the NDS database that is not located on their login server.

During the NetWare installation process, the context in which the server object is created is set up to be that server's bindery context. You can change the bindery context and add additional bindery contexts by running the SET BINDERY CONTEXT command from the server console prompt or adding it to the server’s STARTUP.NCF or AUTOEXEC.NCF file.

To set the server's bindery context to be Accounting.NY.CorpNet, type the following from the server console's system prompt:

If you want to include multiple containers in the server's bindery context, specify each one in a single SET BINDERY CONTEXT command separated by semicolons (;). For example, to set the containers Accounting.NY.CorpNet, Sales.LA.CorpNet, and Paris.CorpNet as the bindery contexts of the server, enter the following command (on one line) from the server console:

Remember that the server must have master or read/write replicas of the NDS partitions in which each of the specified containers are located.

Navigating the Tree

Context, to a Novell Directory Services user, is more than a static configuration parameter specified in your client software. Your context is your location at any given time in the NDS tree. This is somewhat comparable to an understanding of your default directory in DOS. When you want to run a program, you must take into account where the executable file is in relation to your current directory.

NDS, however, lacks an equivalent of the DOS PATH command. More often, you must specify a path to an object in another container using one of the notation methods covered in the "Understanding NDS Object Naming" section, earlier in this chapter, or you must navigate your way through the tree to the proper context.

The following sections introduce you to the NDS—included with NetWare 4.11—that you can use to traverse the NDS tree and locate objects in other containers. As with most NetWare-related tasks, utilities are included with the operating system that enable you to use the DOS command prompt, the character-based, C-worthy interface, or a Windows GUI.

You will be called upon to use the techniques discussed in these sections many times in other chapters. These skills are basic to an understanding of NDS and to the administration of a NetWare 4.x enterprise network. Also, if you can pass along some conception of NDS to your users, they will be able to better make use of the network resources available to them without calling for help.

Using CX

CX is NetWare's command-line NDS navigation utility. Just as the DOS CD command works with directories, CX enables you to change your context to any other container in the tree. You can then reference any object in that container by specifying only its common name.

For example, if you wanted to use the NetWare CAPTURE command to direct your print output to a printer in another container, you would normally have to specify the full distinguished name of the printer object, as follows:

If you used country objects in your tree—or some other construction that invalidated the default typing rule—you might even have to specify object types as well:

If, however, your current context was the same as that of the printer object, you could omit everything but the printer's common name from the command, as follows:

Because you are in the same context, you don't have to enter the complete directory name; CAPTURE assumes that the object you specified is in the same context. All NetWare 4.11 commands and utilities are designed so that you can easily use the objects in your current context.

Using CX is the best way to get a full understanding of how the NDS naming system works, and how context is used by the NetWare utilities. This is because a CX command is immediately processed by the NetWare client on your workstation, where the NDS name information you've entered is canonicalized and then sent to the NetWare server.

When the server processes the canonical name sent by the client, it either allows the change of context or rejects the NDS name as invalid. The distinguished name that was sent to the server is then displayed at the workstation, either as the new context or as part of an error message. If you specify an incorrect name, therefore, you are immediately shown the results of your mistake and given the opportunity to try again. If you can use CX effectively, then the behavior of the other NDS utilities will be that much clearer.

Using CX to Learn Your Current Context

Running the CX command with no parameters displays your current position in the directory tree. If you're located at the root of the tree and type CX and press Enter, the command displays the following information:

If your current context is Accounting.NY.CorpNet and you enter CX, the following context information is displayed:

Using CX to Specify a New Context

The most common use of CX is to modify your current context by specifying the name of a different container in the directory tree. If the new container can be found by moving downward from your current location in the tree, then you can just enter CX followed by the name of the container that you want as your new context. If, for example, your current context is the [ROOT] of the tree and you want to change it to Accounting.NY.CorpNet, then the following command is needed:

CX switches you to the context you specify and displays your new context.

The preceding example shows the new context as a typeless name because the default typing rule can be applied effectively to identify the objects. If you used country objects in your tree (or if you want to for any other reason), you can also use typeful names, causing the preceding command to look like this:

Using CX with Relative Context Specifiers

In the previous section, you changed your context from the [ROOT] to a different container. In effect, you supplied the full distinguished name of your desired context. In "The NDS Context," earlier in this chapter, however, you learned how the NetWare 4.11 clients append your current default context to any NDS name that you specify in an application.

The CX command is no exception to this. When you use CX to switch contexts from one container to another located farther down the same branch, you can simply specify the new container name relative to your current position in the tree.

In other words, if your current context is Accounting.NY.CorpNet, you can switch it to the East Wing container by using the following command:

This CX command works because your client software appends your current context to the command, as shown:

As long as you are moving downward in the NDS tree hierarchy, the technique of specifying the new container name relative to your position is effective. If, however, you wanted to change your context to the Sales.LA.CorpNet container, none of the following commands would work correctly:

This is because, in each case, your current context would be appended to the partial name given, resulting in the following nonexistent containers:

You can prevent the CX command from adding your current context to your CX commands in two ways: with the use of a flag or by masking the name with a context qualifier. If you include the /R (for root) parameter in the command, CX treats the requested context as being relative to the [ROOT] of the directory tree. If you include the /R switch in the preceding examples, then CX Sales /R and CX Sales.LA /R will still result in an error because the contexts given do not exist off of the [ROOT], but CX Sales.LA.CorpNet /R will function properly because the full distinguished name of desired context is given.

You can get the same results as using the /R flag by masking the name with a context qualifier, as shown in "Context Qualifiers," earlier in this chapter. By preceding the specified context with a period, as in CX .Sales.LA.CorpNet, you get the same result as when you type CX Sales.LA.CorpNet /R because the object types from your current context are being applied to the name you have supplied, resulting in the following typeful name that is sent to the server:

The CX Sales and CX Sales.LA examples will again fail, even with the preceding period, because the context qualifier causes the object types from the current context to be applied to the most significant name first. Thus, these names will be interpreted as O=Sales and OU=Sales.O=LA, respectively, neither of which are valid in this tree.

Using Periods to Move Up the Directory Tree

By using the /R flag with the CX command or using a preceding period, you are in essence instructing your client software to travel up the tree all the way to the root in order to define a new context. You may, however, not want to move all the way to the top of the tree. You might just want to travel upwards a few levels on the same branch.

It is possible to move up a few levels without specifying an entire context from the root by using the other type of context qualifier: trimmed masking. Trimmed masking involves the use of periods to take the place of the containers immediately above the current context in the NDS hierarchy.

In its simplest form, you don't have to specify any container names at all with the trimmed masking technique. If you issue the CX command with a single period as a parameter, your context will be moved up one level in the tree. If your current context is:

then the CX . command (don't forget the space) will change the context to:

In the same way, two periods (as in CX ..) will move your context up two levels to:

What is actually happening here is that each period is causing the least significant name to be left out of the default context that is appended to the given NDS name. Because these commands supplied no name, the resulting canonicalized name sent to the server ends up being the context alone, minus one name for each period. Because of this, you can also use trimmed masking in combination with partial names. If, for example, your context name is

then the command CX West_Wing. will be valid. This works because the current context is appended to the partial name given, minus the least significant container name, because of the period. The result is as follows:

You can use as many trailing periods as you have levels in your NDS tree. In the previous example, it is not strictly necessary to travel all the way up to the [ROOT] of the tree to change the context from Accounting.NY.CorpNet to Sales.LA.CorpNet. Because both contexts are found within the CorpNet container, you can use the command CX Sales.LA. to prevent the Accounting and NY names from being appended, as follows:

Using CX to Display Directory Tree Information

Besides displaying your current context or switching to another context, CX can also be used to display the structure and contents of your NDS tree.

You can use the /T (for tree) parameter to view the tree structure of the container objects found below a given context. For example, the CX /T command displays the tree hierarchy beginning at your current default context, as shown in Figure 4.3.

Figure 4.3: The /T switch causes the CX command to display a character-based representation of the NDS tree beneath the current context.

You can also display the tree structure starting with another context by specifying that context in the command. To see the directory structure of the entire NY container, issue the CX .NY.CorpNet /T command.

By default, the /T parameter causes CX to display only container objects. To display both container and leaf objects, you must use the /A parameter along with /T. You also can combine the /T and /R parameters. To view the structure of the entire tree, starting with the root and including all objects, issue the CX /T/R/A command to produce a display like that shown in Figure 4.4.

To display a simple (non-hierarchical) list of the container objects in your immediate context, use the CX /CONT command. To view the container objects in another context, add the context name to your CX command before the /CONT parameter, as follows:

Figure 4.4: By using the CX /T/R/A command, you can display the entire contents of your NDS tree in a hierarchical fashion.

Table 4.2 summarizes the options available for use with the CX command.

Browsing the Tree with NETADMIN and PCONSOLE

Although the primary purpose of CX is to change a user's context, other NetWare utilities incorporate a context-changing mechanism into their interfaces. Such DOS utilities as NETADMIN and PCONSOLE, though menu-based, are not graphical, yet their primary function is to manipulate the properties of NDS objects.

It is therefore important for users to be able to change their current context within the utility in order to locate the required objects. NETADMIN and PCONSOLE are both utilities that are based on the C-worthy interface, an ASCII-based, mouseless, menu-driven standard since the early days of NetWare.

DOS, obviously, has been largely left behind in today's workplace, and Novell is now focusing its development efforts on NetWare Administrator and other Windows-based utilities. Programs like PCONSOLE and NETADMIN are still part of the NetWare package, but they no longer have the same capabilities as their Windows counterparts.

Using NETADMIN

NETADMIN, first introduced in the NetWare 4.0 release, started out as the DOS equivalent of NetWare Administrator. It can be used to create and delete most types of NDS objects and manage their properties. As the functionality of NDS and the NetWare Administrator utility was improved, however, it became impractical to implement all of the improvements into NETADMIN.

Although it is still a usable tool for standard NDS management tasks, NETADMIN lacks several of NetWare Administrator's important new features. For example, although the version of NETADMIN included in NetWare 4.11 can move and rename subtrees, it cannot manipulate multiple objects simultaneously or address two NDS trees at once, nor does it have the drag-and-drop capabilities that are native to a Windows-based program.

NETADMIN is also incapable of creating or manipulating the new object types created by extensions to the directory schema, such as the application objects created for use with the NetWare Application Launcher program.

Using PCONSOLE

PCONSOLE existed long before NetWare 4.0 was released. PCONSOLE has always been the control center for NetWare's printing architecture. When NDS was introduced, PCONSOLE was given a dual role. It can now function as a print maintenance utility in either bindery or NDS mode. The F4 key switches the menu structure between the two modes, enabling you to manage both NDS and bindery printers using the same program.

Although NetWare Administrator has the same print object management capabilities as PCONSOLE, it also simplifies the process of creating print objects with its Print Services Quick Setup feature. The NetWare Distributed Print Services product, which is scheduled for release in version 2 of IntranetWare, eliminates the separate NDS objects devoted to printing and is also managed from NetWare Administrator.

Changing Context in the C-Worthy Interface

The nature of NetWare's menu-based DOS utilities makes it impossible for them to display a graphical representation of the NDS tree. As with the DOS utilities that require navigation of the file system, such as FILER, you must change to the context (or directory) containing the items that you want to manage before you can manipulate their properties.

Both NETADMIN and PCONSOLE (in NDS mode) display your current context at the top of the screen at all times, and have a Change Context selection on their main options menus (see Figure 4.5). Selecting Manage Objects in NETADMIN or one of the print objects menu items in PCONSOLE displays a listing only of the objects found in the current context.

Figure 4.5: Both the NETADMIN and PCONSOLE utilities display your current NDS context and enable you to change your current context.

To manage objects in another context, you must first select Change Context from the NETADMIN or PCONSOLE menu. When you do this, both utilities pop up an Enter Context box into which you can manually supply a new context, using any of the notation techniques covered in the "Using CX" section earlier in this chapter. All of the typing rules and context qualifiers that are used with CX are valid here, as they are from any NetWare prompt that requires the specification of an NDS name.

When you press Enter after specifying a context, the name you have entered is immediately canonicalized and sent to the server. If the object name is incorrect or does not exist, an error message is generated, and you are returned to the Enter Context prompt.

In this sense, therefore, these menu-based utilities function just as CX does on the command line. However, instead of typing in a new context, you can also elect to browse the NDS tree by pressing the Insert key at the Enter Context prompt.

Pressing the Insert key displays—in an Object, Class window—all of the container objects in your current context. The object name and its class are listed along with two objects representing the current context and its parent, as shown in Figure 4.6.

Figure 4.6: You move about the NDS tree in NETADMIN and PCONSOLE by selecting an object from the display of your current context.

From the Object, Class display, you navigate the NDS tree by selecting one of the listed container objects to move downwards in the tree, or the (parent) object to move upwards. As you move about the tree, the display at the top of the screen changes to reflect your current context. Pressing the F10 key accepts the context shown, and returns you to the main menu where you can choose to modify the objects found in that context.

Obviously, the view of the NDS tree that is provided by the C-worthy interface is not as comprehensive or intuitive as that of a graphical utility that can show the actual tree structure of the database. A user that is relatively unfamiliar with the design and structure of the tree would probably be better served by using the NetWare Administrator utility. However, NETADMIN and PCONSOLE are not without their usefulness.

Many long-time NetWare users are very accustomed to the eccentricities of the C-worthy interface, and can manipulate the DOS utilities with remarkable speed. The responsiveness of such programs as PCONSOLE and NETADMIN is also generally faster than that of Windows-based utilities, such as NetWare Administrator, if only because of their smaller size. For everyday maintenance activities, such as assigning trustee rights, managing print queues, and creating user objects, the DOS-based utilities remain a viable option.

Using NetWare Administrator

By virtue of its capability to display the entire contents of an NDS tree (or even of multiple trees) at the same time, NetWare Administrator lessens the importance of the context when it comes to maintaining the tree. Unlike NETADMIN or PCONSOLE, NetWare Administrator does not limit you to managing only the objects in your current context. You can highlight any object in the tree display at any time and access the Details dialog box to display and modify its properties.

Setting the NDS Browser Context

Strictly speaking, when you are using NetWare Administrator, your context is represented by the container object at the top of the tree display in the active window. This context is displayed in the title bar of that active window, which you can modify by selecting the Set Context option from the View menu.

The Set Context dialog box, as shown in Figure 4.7, enables you to specify a different context and even a different NDS tree, again using the standard NDS notation techniques. Buttons are also provided that enable you to select a tree from a listing of those found on the network and to browse the current tree for a new context.

Figure 4.7: The Set Context dialog box enables you to specify both the tree and the container that you want to appear as the top level of the active browser window.

When you click the Browse Context button on the toolbar, you are presented with a Select Object dialog box, as shown in Figure 4.8. This is the standard browser dialog box that is used in NetWare Administrator whenever you are required to select an NDS object. The browser dialog boxes presented in various circumstances differ only in the object types that are listed and the context that is initially displayed.

Figure 4.8: NetWare Administrator's Select Object dialog box is shown whenever the user is called upon to specify the name of a particular NDS object.

In this case, the Select Object dialog box lists only the container objects and server volumes in your current context.

When the Select Object dialog box is displayed for other purposes, the available options may change. For example, when you select a user object on the tree and modify its properties in order to grant that user a new security equivalence, you will be presented with a Select Object dialog box that differs in two ways:

• It lists all of the object types to which the user can be made equivalent, not just containers.
• It begins by displaying the objects in the context where that user object is found, not the objects in your (the administrator's) current context.

Apart from the objects that are displayed and the starting point, however, the process of navigating the tree in the Select Object dialog box is always the same.

Using the Select Object Dialog Box

In the upper-left corner of the Select Object dialog box, the current context is displayed, which changes as you navigate the tree. The dialog box is split into two panes, labeled Available Objects and Browse Context.

When you are using the dialog box to select a new context for the main window display, these panes may be confusing because they both display the container objects found in the current context. When the Select Object dialog box is used for other purposes, these panes are more easily distinguished because the left side will usually contain both the container and leaf objects in the current context, while the right pane lists only containers.

In any case, you use the right pane to navigate the tree and the left pane to select the desired object. As with the NETADMIN context selector, the right pane of the Select Object dialog box uses two periods plus an arrow to designate the parent container of the current context, enabling you to move upwards in the tree. To move downwards, you select the name of one of the container objects shown in the left pane.

Another way in which confusion can arise when you are selecting a container object using the Select Object dialog box is that you do not want to navigate to the desired container in the right pane. The object of the exercise is to display the container that you want to select in the left pane. Therefore, you must actually navigate to the parent of the desired container in the right pane.

In other words, if your current context is CorpNet and you want to change your context to Accounting.NY.CorpNet, it may seem natural to navigate all the way to the Accounting container in the right pane, as shown in Figure 4.9.

Figure 4.9: Although it may seem to be correct, you cannot set a new context in the Select Object dialog box while displaying the contents of the desired container object.

When you navigate to the desired context via the right pane, the context indicator in the dialog box says Accounting.NY.CorpNet, and it appears as though everything is going right. However, you then notice that the OK button is grayed out and that there is no way to actually save your changed context.

The reason the OK button is unavailable is that you have not actually selected an object in the left pane. When you attempt to do this, however, you see that the left pane lists only the objects that are contained in the Accounting.NY.CorpNet context.

In order to actually select the desired container, you must move upwards in the tree to the NY.CorpNet context so that the Accounting container is displayed in the left pane, as shown in Figure 4.10. You can then select the Accounting container in the left pane, which activates the OK button.

Figure 4.10: In order to set your context to Accounting.NY.CorpNet, you must browse to the NY.CorpNet container and then select Accounting.

Once you select OK, the desired context is placed into the Set Context dialog box. Press OK in the Set Context dialog box, and your active NDS browser window is modified so that the new context appears at the root of the display.

Summary

This chapter introduces several important concepts that are crucial to understanding Novell Directory Services and the role that it plays in the operation of a NetWare network. You must understand how NDS objects are named and various ways that they can be notated, in order to efficiently administer them. In later chapters, as you learn to work with the NDS database and the tools used to manage it, you will apply these concepts again and again.