CNE Training Guide NetWare 4.1 Administration

Previous chapterNext chapterContents


- 2 -

Introduction to NetWare Directory Services


NetWare Directory Services (NDS) is perhaps the single most important feature of NetWare 4.x. It enables a network consisting of many servers to be treated as a single network that you can easily administer. By using NDS, you can treat all network resources as logical resources. You can group the logical resources together to represent their logical relationships, and you can administer them from any workstation on the network. Network administration is reduced to managing the resources in the NDS database. This chapter will teach you basic NDS concepts and ways you can use NDS to access and manage network resources. An understanding of NDS services is fundamental to managing NetWare 4.x, because access to network resources revolves around the ways that NDS is represented, accessed, and managed.

Understanding NDS

NetWare Directory Services (NDS) is a distributed global database of services and resources that are available on the network. The term global implies the existence of a single database that is shared by all servers on the network, and is available to users from any point on the network. Most resources important to network management on the network have an entry in this global database.

Conceptually, this database exists when Directory Services is installed, and it is not tied to any physical resource such as a server. In practice, because NDS is implemented as a database, it must be stored on storage devices on the network (such as physical volumes that are associated with physical servers). Because the size of the NDS database can become very large, the NDS database is not stored at any central site (except for very small networks). Reliability concerns also figure in this storage decision. Portions of the NDS database are distributed on volume storage devices at strategic locations on the network. These subdivided elements of the NDS are called partitions.


STUDY NOTE: NDS is




STUDY NOTE: NDS provides the following benefits:


Understanding NDS Logical Resources

NDS logical resources are represented by objects. Because these logical resources are associated with NDS, they are often called NDS objects. You can look at NDS objects conceptually as records in a global database (see fig. 2.1). The network resources that you can represent as NDS objects include network printers, network volumes, NetWare file servers, AppleTalk Filing Protocol servers, user accounts, and so on.

Each NDS object holds information about the logical resource it represents. Information about an object is stored as properties of the object. Because you can view an NDS object as a record, the properties are similar to the fields of a record (see fig. 2.2). For example, the properties of a User object include the user's login name, last name, groups the user belongs to, user's telephone number, and so forth. Figure 2.3 provides examples of NDS Resource objects and their properties. The figure shows some of the properties of a User object and a NetWare Server object. The properties are listed in the property column, and represent the categories or types of information you can store in the object.

Figure 2.1 Viewing NDS as a global database.

Figure 2.2 Properties of objects.

Figure 2.3 Example NDS objects and property values.

The actual information stored in a property is listed in the Value column and is called a property value. Some properties are crucial and must have a value associated with them. These are mandatory, or required, properties. An example of a mandatory property for all NDS objects is the name property, called the common name. If the name property is not defined, an object cannot be referenced. The last name property for User objects is mandatory.

Some of the NetWare Server object's properties are also shown in figure 2.4. You can view these properties using the NetWare Administrator GUI tool. This figure shows that you can specify the Department, Organization property for the Server object. The properties Net Address, Status, and Version cannot be changed by the administrator, and represent the current status of the physical file server.


AUTHOR'S NOTE: In NetWare 3.x there was an optional Full Name property for user accounts. But in NetWare 4.x the last name property is mandatory. This might seem strange at first because the last name property does not seem to serve any crucial technical function in the NDS database. The answer to this mystery lies with X.500, on which the NDS is based. Although certain properties are explicitly defined as being mandatory in X.500, others are optional. Many of the properties defined in NDS User objects are taken directly from the X.500 definition. In X.500, the last name property for User objects is called the surName property, and this is mandatory. NDS defines the last name property as mandatory to be compliant with X.500.

Figure 2.4 NetWare server properties.

Certain properties in NDS are defined for informational purposes and are optional properties. Examples of these are a user's telephone number, fax number, user's title, and electronic mail address. Many objects have an optional See Also property.

Property values can be single-valued or multivalued. If a property is single-valued, you can define no more than one value for that property. An example of this is the network address property of a NetWare File Server object. Multivalued properties can have more than one value defined. An example of this is the telephone number property for User objects. You can define multiple telephone numbers for a User object.


AUTHOR'S NOTE: Property values can be numeric, a string, or in some special format, such as a network address on an IPX network (4-byte network address, 6-byte node address, 2-byte socket number). In X.500 terms, the properties of an object are called its attributes. The actual format of the value of a property is defined by the attribute syntax for that property/attribute.


PRACTICAL TIP: For your company or organization, define which of the optional properties should have values defined for them. It is generally a good idea to define op-tional properties for information purposes so that you can query the NDS database for information on these property values. Certain organizations, however, might not want to give out telephone numbers or other information about users. In this case, certain properties might not be defined, or NDS security might be used to enable only certain users to view information on the NDS objects.

Comparing NDS to the NetWare Bindery

NDS treats all resources on the network as objects belonging to a global database. This global database (directory) represents the network and has a structure that corresponds to a logical view of the network. The directory is not kept in a centralized location, but portions of it (partitions) are distributed across servers on the network; it can, therefore, be described as a distributed database. This is different from the approach used in pre-NetWare 4.0-based networks, in which the resources on a server were centrally located in a flat database called the bindery. Because the bindery served as a centralized database, it was a potential single point of failure. Also, the bindery could only define resources available on the server on which it was resident, it lacked the global nature of NDS.


STUDY NOTE: NDS provides a global directory that represents a logical view of the network.

The directory database in NDS is organized in a hierarchical fashion. This hierarchical structure maps well onto the organizational structure of most companies; moreover, you can use the structure to represent logical relationships between network resources, such as the grouping of resources under a node that represents a specific department. It is interesting to contrast the differences between the NDS and the NetWare 3.x bindery, because the differences provide insight into the improved manner in which network resources are managed in NetWare 4.0. Table 2.1 summarizes the differences between the NDS and the NetWare bindery.

Table 2.1NDS Versus the NetWare Bindery

Attribute/Feature NDS Bindery
Structure Hierarchical Flat
Users Network-wide Server-centered
Login Network-wide Server-centered
Passwords Single password Password per server
Groups Network-wide Server-centered
Location Distributed Server-centered

In earlier versions of NetWare, the bindery was used to keep information on network resources in a flat database. This flat database did not represent the logical relationship between network resources. The bindery was server-centered, and was used to store information on resources available at a NetWare server, rather than the entire network. As a result of this limitation, tasks such as user account creation had to be performed on each server separately. User and group accounts had to be stored in the bindery of the server on which they were defined. The concept of a network-wide user account did not exist. There was an attempt to provide this capability using NNS (NetWare Name Service), but this was not very successful, and was never popular because of a number of problems dealing with its implementation.


STUDY NOTE: Because the bindery is implemented as a flat database, it is not used to represent logical relationships between network resources.

The NDS structure is hierarchical. This enables NDS to represent relationships between network resources in a manner that is more comprehensible for the user and the network administrator. The logical representation of resources in the NDS is called an NDS object. The NDS can also be used to store information about objects so that you can query this information in much the same way as you can a telephone directory. For instance, you can use the User object information to keep data such as phone numbers, fax numbers, electronic mail and other addresses, locations, and so forth. User and group accounts in the NDS are network-wide in scope, and this eliminates the network administrator's need to create user and group accounts on each server to which the user needs access.

Many tasks such as user/group account creation, which in earlier releases of NetWare had to be done separately on each server, are eliminated because the user/group account needs to be created just once in the directory. After you create the user account, you can assign it rights to any network resource that is represented in the NDS, such as NetWare volumes and network printers. Another benefit of the NDS is that the user needs to remember just one password to the network. Once validated, the user's trustee assignments provide the user with necessary access privileges to network resources.


STUDY NOTE: NDS eliminates the need for creating separate user and group accounts on each NetWare server. NDS enables the creation of User and Group objects that have a network-wide scope.

It is important to understand that NDS provides control of directory resources such as servers and volumes, but not control over the contents of volumes, such as files and directories. The trustee right mechanisms used in NetWare 3.x are still used to provide access to files and directories.


STUDY NOTE: NDS provides control over directory information on network resources, not control over files or directories on a network volume.

Understanding the NetWare Directory Database

NDS is a global, distributed database that records information about network resources hierarchically. The distributed nature of NDS enables it to store information concerning many types of objects, such as users, printers, servers, and volumes that are of interest to the network's user community (see fig. 2.5). The distributed information is actually stored on NetWare servers throughout the network in a manner that is transparent to the user. A directory synchronization mechanism is used, so that directory changes in any part of the NDS database are propagated throughout the network. In other words, NDS synchronizes itself to present a consistent view of itself to the rest of the network. Directory synchronization takes place automatically without user intervention. The network administrator can set certain parameters to minimize the effect of directory synchronization on network traffic.

Figure 2.5 The NDS database.

For security reasons, NDS is kept as a hidden data area on a storage volume. NDS presents a hierarchical view of itself to the rest of the world. Access to any portion of NDS is controlled by a new set of object trustee assignments made on NDS objects.

The hierarchy in NDS is often described in terms of a directory tree, such as the one shown in figure 2.6.

Figure 2.6 Hierarchical NDS tree for Network Widgets, Inc.

The hierarchical relationship enables network resources to be organized in a manner that reflects the ways the network is used, instead of the physical topology and connectivity of the network. You can make the directory organization more closely match the user's view of the network. For example, in figure 2.6, engineers Tom, Mary, and Dei of the organization Network Widgets, Inc. have user accounts defined under the departmental unit (called organization unit, in NDS terminology) Engineers. Figure 2.7 shows that the users are in different physical locations. In figure 2.7, engineers Tom and Mary are shown to be in Dallas and user Dei is in Los Angeles. Because they all belong to a group of engineers, however, they will have similar needs to access network resources. Under these circumstances it makes sense to group them in an organization unit called Engineers, regardless of their physical location.

Figure 2.7 Physical network for Network Widgets, Inc.

The file server for the engineers of Network Widgets, Inc. is currently defined in Los Angeles. Should there be a need in the future to physically move the server to Dallas, you can move the file server without changing the NDS view of the network. The file server EFS_1 is still under the organization unit of Engineers in the NDS tree. In figure 2.6, you can see that volume EFS_1_SYS, which is physically attached to the server EFS_1, is in the organization unit Engineers because it is primarily used by the engineers of the company. Another volume, called EFS_1_VOL1 also is physically attached to server EFS_1, but its NDS representation is kept in the organization unit Sales because it is primarily used by members of the sales team. Volume EFS_1_VOL1 might be kept in the Sales organization unit because the group Sales does not yet have its own file server. This discussion shows that you can place network resources in the NDS tree according to their use and the user's view of the network, rather than by physical location of the resource.

NDS is based on the CCITT X.500 standard. CCITT stands for Consultative Committee for International Telephone and Telegraphy, and is an international body that develops standards in the area of data communications. Its members comprise the standard-making bodies of various countries. CCITT publishes and updates standards periodically at four-year intervals.

NDS is not in complete compliance with X.500 because NDS is largely based on the 1988 X.500 recommendations. The X.500 standard has further evolved into the 1992 X.500 specification, but this was not available to NDS designers, who began work on NDS before 1992.


AUTHOR'S NOTE: For strategic reasons you can expect Novell's implementation of NDS to comply with the international consensus on X.500 when this becomes universal. The protocol mechanism for keeping the NDS database updated when changes are made to it (directory synchronization) is another area of expected change. This has not been completely specified in the X.500 standards. As a result of this oversight, Novell, like many other X.500 vendors (DEC, Retix, etc.), has had to design its own directory services synchronization protocol to deal with directory synchronization. Many X.500 vendors, including Novell, are seeking common ways to implement X.500-compliant synchronization methods and services. Novell provides an API to exchange data between other name services, making it possible to build name service gateways to other name services.

NDS complies closely with X.500 recommendations. Details of the kinds of objects that make up the directory are specific to NetWare-based networks. You can add other general classes of objects that are not Novell-specific to the NDS directory by making use of the NDS programming APIs. This capability makes it possible to integrate it with other vendors' X.500 directory implementations. The schema (type of objects in a database) of NDS is extensible, which means the NDS database is extensible.

The NDS database is called the Directory Information Base (DIB) in the X.500 specification. Novell's documentation uses the terms NDS database or NDS tree, and these are the terms that will be used throughout this book.



STUDY NOTE: NetWare Directory Services is

NDS provides


Classifying NDS Components

NDS employs a hierarchical structure, and uses a specific terminology to describe its components. Although some of the terms have been derived from CCITT's X.500 recommendations, others are specific to Novell. Before you can obtain a working understanding of NDS, you must understand the vocabulary and terms used to describe NDS.

Tree Structure of NDS

The NDS database is organized as a hierarchical tree. Computer scientists use the term tree to describe a method of representing data beginning from a single point, called the root. The root of this tree has branches, which can, in turn, branch off to other branches or leaves. Figure 2.8 illustrates this tree concept, along with a picture of the NDS tree.

Figure 2.8 NDS tree components.

The tree has a single root, an important detail because the NDS database also has a single root. If you have several NDS databases constructed separately from each other, they will have separate roots. At the moment, no way exists to dynamically exchange NDS information between NDS trees with their own separate roots. Tools exist for combining several separate NDS trees (each with its own root) into a single, larger NDS tree. An example of such a tool is DSMERGE, which enables two NDS trees to be merged.

The root of the tree describes the first level of the tree, and is also used to describe the entire tree. The [Root] object cannot be created using any of the NetWare administration tools. It is created during the installation of a NetWare 4.x server, at which time you have the opportunity to install the Server object in an existing NDS tree or define a separate NDS tree with its own [Root]. Once defined, the [Root] object cannot be renamed, moved, or deleted.


STUDY NOTE: You can have only one [Root] per NDS tree. The [Root] object cannot be renamed, moved, or deleted.
The [Root] object can contain only Country, Organization, and Alias objects.

A branch from the root of a tree leads to another object on the tree, and describes a complete subtree. An object on a tree that contains other objects is called a container object (all nodes of a tree represent a logical concept of an organization or a resource, and are called objects). A branch of a tree can, therefore, be seen as a container object plus all the objects underneath it.


STUDY NOTE: The NDS tree is used to represent the hierarchical structure of the NDS database.

A branch of an NDS tree is a container object and all the objects underneath it.
An NDS tree has a single root that is named [Root].


Container Objects

An NDS container is an object that contains other objects, such as resource and service objects, and other containers. Containers provide a practical way of organizing objects by departments, geographic locations, work groups, projects, common usage of network resources, or any other criteria that make it easier to use the network.

Container objects provide a convenient way to organize other objects into groups (see fig. 2.9)--a key advantage of NDS. Besides facilitating a logical organization of the NDS tree, you can use container objects as groups that you can assign certain security rights, which then affect the security rights of all objects in that container.

Figure 2.9 Container objects as groups. Besides the [Root] object, the NDS defines the following container objects:

A container's type is referred to as its object class. Each container type previously listed has a separate object class definition. An object class definition defines the rules that govern the object's existence in the NDS tree. That the Country container can exist directly underneath the [Root] object is an example of such a rule. It cannot be contained in the Organization or Organizational Unit containers. This rule is described in the Containment Classes structure rules for NDS objects.


STUDY NOTE: Container objects are used for


Leaf Objects

An object in the tree that does not (and cannot) contain any other nodes is called a leaf object. A leaf object is similar to a leaf of a real tree--it has no other branches and leaves coming from it. A leaf object acts as a terminal point in the tree and represents a network resource or service (see fig. 2.10). A leaf object can exist only inside a container object.

Figure 2.10 Leaf objects.


STUDY NOTE: A leaf object


Object Class and Schema

A NetWare 4.x-based network can have many different types of network resources and services, and each is described by a special type of leaf object. Earlier, you learned about file server and print server objects. These are examples of leaf objects. The object definition (also called object type) for an object in the NDS database is called its object class. In database technology terms, the collection of the different object definitions possible in the database, their scope and rules of existence, and their operation within the database, is called the schema.

Because the NDS tree is a globally distributed database, database terms are sometimes used to describe the NDS tree, and you should be familiar with them. The NDS schema is, therefore, a collection of object class definitions for objects such as file servers, computers, printers, print servers, and so forth (see fig 2.11). When an object of a type that can exist in the NDS schema is created, the object class is said to be instantiated. The object class implies the potential for an object of that class to exist in the database; it does not imply the existence of an object of that type. The object class must be instantiated (created) before an object belonging to that category can exist.

Figure 2.11 The NDS schema.


STUDY NOTE: Each different type of network resource that can exist in an NDS database is called an object class.
The collection of the different object definitions possible in the database, their scope and rules of existence, and their operation within the database, is called the schema.

In the example shown in figure 2.8, the objects ESL and Engineers are examples of container objects. They are container objects because they can, in turn, contain other objects. The objects FS1 and FS1_SYS are examples of leaf objects. These leaf objects are the terminal points in the tree, and cannot contain other objects.

A container that has objects defined in it is a parent container to the objects that it contains. Although some object classes can contain other objects, other objects cannot. For instance, leaf object classes cannot contain any other object classes. Container object classes can contain other object classes, but there are rules that govern the kind of container class objects that can exist in other container class objects. These structural rules are called Containment Class rules and define where one type of object class can occur in relation to another object class. An object can exist in or be subordinate to only the objects listed among the object's containment classes. Table 2.2 shows the containment class rules for container objects.

Table 2.2 Containment Class Rules for Container Objects

Container Object Containment Classes (Can Exist In) Can Contain
[Root] Cannot exist under any object. Parent to all objects. Country
Alias (Alias can be to another Country object only)
Country [Root] Organization
Organizational Unit
Alias (Alias can be to an Organization or Organizational Unit object only)
Organization [Root]
Country
Organizational Unit leaf objects
Organizational Unit Organization
Organizational Unit
Organizational Unit leaf objects


STUDY NOTE: Understand the containment rules in table 2.2.

NDS objects have a definition hierarchy similar to that used in object-oriented programming languages. The structural rules for objects define the concept of an Immediate Superclass. An object is "derived" from its immediate superior class.

At the topmost level is an object called Top. Top is the superclass of all objects. All NDS objects are directly or indirectly derived from Top. Top is the only class that has no superclass.

When an object has a superclass, the object's definition is said to be derived from this superclass. This means that the object's attributes (properties) are those defined by the superclass object plus any additional properties peculiar to that object. Another way to say this: An object inherits some of its properties from its parent object.

An example of derivation is shown in figure 2.12, in which the Alias object class is derived from the Top superclass. The only new attribute/property defined in the Alias object class is the alias Object Name; all other properties of the Alias object class are inherited from the Top superclass.

Figure 2.12 Deriving an Alias object from the Top Class object.

You can express the definition of the Alias object by using the formalism of ASN.1 (Abstract Syntax Notation Revision 1) as shown in the following:

alias OBJECT-CLASS
SUBCLASS OF Top
MUST CONTAIN {aliasObjectName}

ASN.1 is a standard that deals with rules of encoding and describing structural properties of application-level data. ASN.1 is part of the ISO (International Organization of Standards) recommendations for the presentation layer (layer 6) of the OSI (Open Systems Interconnection) Reference model, and is the language used by protocol designers to describe upper-layer application protocols.

Another interesting definition is that of the User class. The User class is actually derived from the Organizational Person superclass. This means that the User class has all the information types defined in the Organizational Person superclass, as well as any additional attributes defined for the User class. The Organizational Person class is derived from the Person class, which is, in turn, derived from the Top superclass. This inheritance is shown in figure 2.13. In formal terms, the derivation of the User class is defined as follows:

Person OBJECT-CLASS
    SUBCLASS OF Top
    MUST CONTAIN { commonName,  surName } 
    MAY CONTAIN  { description, telephoneNumber,
        fullName, seeAlso }
Organizational Person OBJECT-CLASS
    SUBCLASS OF Person
    MAY CONTAIN {  EMail Address,
                   Facsimile Telephone Number,
                   Locality Name, // Not implemented in NDS
                   Organizational Unit Name,
                   Physical Delivery Office Name,
                   Postal Address,
                   Postal Code,
                   Postal Office Box,
                   State or Province name,
                   Street Address,
                   Title }
        CONTAINMENT {Organization,
                   Organizational Unit }
        NAMED BY   {Common Name,
                   Organizational Unit Name }
User OBJECT-CLASS
       SUBCLASS OF Organizational Person
       MAY CONTAIN {Account Balance,
                             Allow Unlimited Credit,
                             Group Membership,
                             Higher Privileges, // Not implemented
                             Home Directory,
                             Language,
                             Last Login Time,
                             Locked By Intruder,
                             Login Allowed Time Map,
                             Login Disabled,
                             Login Expiration Time,
                             Login Grace Limit,
                             Login Grace Remaining,
                             Login Intruder Address,
                             Login Intruder Attempts,
                             Login Intruder Reset Time,
                             Login Maximum Simultaneous,
                             Login Script,
                             Login Time,
                             Message Server,
                             Minimum Account Balance,
                             Network Address,
                             Network Address Restriction,
                             Password Allow Change,
                             Password Expiration Interval,
                             Password Minimum Length,
                             Password Required,
                             Password Unique Required,
                             Passwords Used,
                             Print Job Configuration,
                             Printer Control,
                             Private Key,
                             Profile,
                             Public Key,
                             Security Equals,
                             Server Holds }

The X.500 standard defines two subclasses (derived classes) from the Person class. These are the Residential Person and Organizational Person subclasses. The Residential Person object class is not defined in NDS. This is used in X.500 to define directory services similar to those found in phone books.

Figure 2.13 User object class derivation.

Objects belonging to object classes, such as Person and Organizational Person, do not exist as objects in an NDS database. They are used for object derivation and construction only and are therefore called noneffective classes. Classes such as User, Group, and so on, can have their objects exist in an NDS tree. Such classes are called effective classes.

You can only use an effective class to create NDS objects. An object class used to create NDS objects is called the created object's base class. It follows, therefore, that you can use only an effective class as a base class for an object. Sometimes, in object-oriented programming languages, the term parent class is used as a synonym for base class. In NDS terminology, the term parent class is used for container objects that contain other objects, and is not used to describe the object derivation hierarchy.

The NDS base schema defines the following noneffective classes:

The NDS base schema defines the following effective object classes:

The Higher Privileges attribute in the user class definition is not currently implemented. This attribute is meant to activate certain privileges on a temporary basis and then deactivate them. Users of Unix systems will readily recognize that the su (supervisor command) on a Unix system enables an already logged-in user to assume root (supervisor) privileges after proper password authentication. You can expect the Higher Privileges attribute, if it becomes implemented, to provide a similar capability.

The Message Server attribute for the User object class is set to the Server object that stores and forwards broadcast-type messages.

Containers and Directories in File Systems

Containers are similar to directories in a file system. A directory in a file system can contain other subdirectories and files. Similarly, a container in NDS contains other subcontainers and leaf objects (network resources and services; see fig 2.14). You can use a directory in a file system for organizing files. Containers in NDS are used to organize network resources. One difference between an NDS tree and a file system directory tree is that there are limitations in the NDS tree as to where container and leaf objects can occur.

No limit to the NDS tree depth exists. For practical reasons, you might want to limit the depth of the NDS tree.


STUDY NOTE: No limit to the NDS tree depth exists. The NDS tree has restrictions on where you can place certain object classes. File system directory trees do not have this restriction.

Each container typically represents an organization, department within an organization, workgroup center, responsibility center, geographical location, and shared information network usage. The container and its relationship with other objects in the tree must be planned carefully.

Figure 2.14 Containers versus directories for file systems.

Naming Objects

All objects of the NDS tree must have a name, called the object name. The root of the tree has the fixed object name of [Root]. Object names are case-insensitive. This means that two objects with the name NW4CS_SYS and nw4Cs_sYs have the same object name. Therefore, [root] and [Root] refer to the same object--the root of the directory tree.

Objects that are directly in the same container cannot have the same name. Therefore, in figure 2.15, the container ENGINEERS cannot have two Volume objects with the names NW4CS_SYS and nw4Cs_sYs. It is not even possible for two objects that have a different object class to have the same name. Container ENGINEERS, therefore, cannot have a file Server object named ZAPHOD and a User object named ZAPHOD. These two objects can, however, exist in different containers, as shown in figure 2.16.

Figure 2.15 Object names in a container.

Even though object names are case-insensitive, the case of the name at the time of the object's creation is preserved for display purposes. This means that if you create an object named mY_worKstation, it will appear in the case used for the object name at the time the object was created. You can rename both leaf and container objects.

To make object names consistent and more readily understandable, it is important for an organization to have guidelines about object-naming conventions.

Figure 2.16 The same object names in different containers.



STUDY NOTE: Object names

You can use up to 64 characters, consisting of alphanumeric characters, dashes, underscores, parentheses, and even spaces, in an object name. If spaces are used, you will have to enclose the object name in quotation marks (") to be recognized in command-line utilities and login scripts. For simplicity, you might want to avoid this. It is even possible to construct a name with a single blank. Figure 2.17 shows an interesting example of an NDS tree that has two objects with blank names. The first container object under ESL and the User object underneath it have blank object names. Even though blank names are permitted, it is a good idea to avoid them.


Figure 2.17 Blank name objects.

Brackets, periods, and percent signs are not permitted in object names. A few special characters such as plus (+), period (.), and the equals sign (=) must be preceded by a backslash (\). In general, it is a good idea to avoid using special characters in object names, as the names then become confusing and difficult to use and remember.


PRACTICAL TIP: NDS even enables you to use characters that are designated illegal in the documentation for creating names of objects. They are not, however, guaranteed to work consistently in the NDS-based commands and utilities. For this reason, it is best to avoid them.

Classifying Container Objects

NDS supports four types of container objects, as follows:

Figure 2.18 shows the icons used to represent these different container objects. These icons appear when you use the Windows-based network administration tools. The US container, in this figure, represents the Country object. The containers AT&T, DEC, ESL, ESL_KSS, LG, LTREE, MITEL, RSA, SCS, WELFLEET, and WIDGET all represent Organization container objects. The containers ACCOUNTING, CORP, R&D, and SALES represent Organizational Unit container objects.

Figure 2.18 Symbolic represen-tations of container objects.

The [Root] Container Object

The most frequently used container objects are the Organization object and the Organizational Unit object. You can have only one [Root] object per NDS tree. The [Root] object cannot be renamed or deleted. It can have rights to other objects, or other objects can have rights to it.

It is possible to install NetWare 4.x on separate LANs, each with its own [Root] object. This can easily happen if the network is built in different segments, and final connectivity of the separate network segments is done at a later time. Under these circumstances, several [Root] objects can exist, each describing a different tree. Now, if you connect the network segments together, the networks represented by the different [Root] objects are not able to communicate (see fig. 2.19) through normal NDS mechanisms for current releases of NDS. Future releases may support NDS mechanisms for communicating between NDS trees.

Figure 2.19 Multiple [Root] objects and sharing of data.

It is possible, however, to have two servers FS1 and FS2, each defined in its own unique tree TREE1 and TREE2. You could log in to FS1 under TREE1 as a valid NDS user. If you map a drive to a volume on FS2, using the NetWare 3.x syntax, NetWare automatically switches to bindery emulation mode and attempts to connect you. You then have access to the FS2 object, even though the FS2 object is in a separate NDS tree. Follow these steps:

1. Log in to TREE1 as a valid NDS user.

2. Enter MAP N:= FS2/SYS:.

This is the NetWare 3.x syntax, which causes NetWare to switch to bindery-emulation mode.


STUDY NOTE: When installing a NetWare 4.x server that is not the first server installed on the network, you should physically connect this NetWare 4.x server to the rest of the network, so that the server can be installed as part of the NDS tree. You can also use the DSMERGE tool to merge two NDS trees.


PRACTICAL TIP: For extremely secure environments it might be desirable to have separate [Root] objects. This ensures that users in a directory tree under one [Root] cannot access or communicate with users under another [Root].
The [Root] object can contain only Country, Organization, and Alias objects. Of these, Country and Organization are container objects, and Alias is a leaf object.


STUDY NOTE: The only container objects that you can place directly under [Root] are Country and Organization objects.
The only objects that you can place under [Root] are Country, Organization, and Alias objects.

The Country Container Object

The Country object is part of the X.500 recommendations. Figure 2.20 shows an NDS tree with the two-letter designations for several countries. From this figure you can see that the Country object must be placed directly below the [Root] object. The Country object is optional. If used, it must occur directly under the [Root] object.

Figure 2.20 Country objects in an NDS tree.

The Country object can contain only Organization and Alias objects.


STUDY NOTE: An Alias object is the only leaf object that both the [Root] and Country containers have in common. Also, the only leaf object [Root] can contain is the Alias object.


STUDY NOTE: The only container object that the Country container can have is Organization.

Country object names can consist of only two characters.


The Organization Object

The Organization object represents the name of the organization. Figure 2.21 shows an NDS tree that has Organization objects. Notice the special icon used to represent the Organization object. At least one Organization object must be used in an NDS tree. It can occur directly under the [Root] object or a Country object. In figure 2.21, the organization objects CISCO, HP, IBL, IBM, MS, and NOVELL are placed directly underneath the Country object US. Also, organizations such as AT&T, DEC, ESL, ESL_KSS, LG, LTREE, MITEL, RSA, SCS, WELLFLEET, and WIDGET are placed directly underneath the [Root] object. These are the only places in which the NDS schema allows an Organization object to be placed.

Figure 2.21 Organization objects.

The Organization object can contain any leaf object and Organization Unit object, but it cannot contain another Organization object.


STUDY NOTE: You can place the Organization object underneath either the [Root] or the Country object only.

The Organizational Unit Object

Because organizations are usually subdivided into specialized functions, such as by department, network usage, common jobs, location, work groups, responsibility centers, and so forth, you can use the Organizational Unit object to represent the organization's subdivision. The Organizational Unit must occur under an Organization object or another Organizational Unit object. An Organizational Unit cannot occur directly under the [Root] object or Country object.

Figure 2.22 shows examples of an Organizational Unit object and the different locations in the NDS tree in which it can occur. The organizations HP, MS, and NOVELL that are in the Country container object have Organizational Units such as CORP, ENGINEERING, MARKETING, and DISTRIBUTION directly underneath them. The organization ESL_KSS that is directly underneath the [Root] has organizational units CORP, ENG, and SALES underneath it. Notice that CORP is used as an organizational unit name in more than one organization. The object-naming rules require an object name to be unique only within the same level of the container, and this enables the same object names to be used in different containers.

Figure 2.22 Organizational Unit objects.

In figure 2.22, organization LTREE has an Organizational Unit named CORP underneath it. CORP, in turn, has two other Organizational Units, BROCHURES and MARKETING, directly underneath it. Many organizations typically have subdivisions within a department.

The Organizational Unit object can contain any leaf object and Organizational Unit object.


STUDY NOTE: The Organizational Unit object
can occur in an Organization or Organizational Unit object.
can contain any leaf object.

Attribute Types

As part of the X.500 system of naming objects, each object type is represented by an attribute designator. Country objects, for example, have the attribute type C. This means that the Country object US is represented as: C=US The other container objects, Organization and Organizational Unit, have the attribute types of O and OU, respectively. The organization IBM, therefore, is represented by: O=IBM and an organizational unit SALES is represented by: OU=SALES A leaf object that represents a resource or a service has the attribute type designator CN (for common name). A file server named NW4CS, therefore, is represented as: CN=NW4CS The different attribute types are summarized in table 2.3. All attribute types except the one for [Root] are part of the X.500 recommendations.

Table 2.3 Attribute Type Designators

Object Container/Leaf Attribute Type
[Root] Container No special attribute type. Designated by [Root] itself.
Country Container C
Organization Container O
Organizational Unit Container OU
Leaf Object Leaf CN

Leaf Object Types

Leaf objects are the actual representations of network resources. Other objects, such as [Root], Country, Organization, and Organizational Unit, are logical in nature and are used for organizational purposes.

The NDS schema, by default, permits the following leaf objects:

Each leaf object is discussed next.

AFP Server Objects

The AFP Server leaf object's current use is for informational purposes only. It represents an AppleTalk Filing Protocol (AFP) server that is on your network. This can be a Macintosh computer running the AFP protocols, or even a VAX server emulating AFP protocols. You can use the AFP server to store information such as network addresses, users, and operators. One of NDS's benefits is that you can query it for information in a manner similar to databases. If you have an AFP Server object for each AppleTalk server on your network (see fig. 2.23), therefore, you can make general queries, such as, "Show me all AppleTalk servers in container O=IBL."

Figure 2.23 The AFP Server object.

Alias Objects

The NDS system is hierarchical in nature, and the object-naming syntax (as you will learn later in this chapter) consists of listing the NDS objects, beginning from the leaf, all the way up to the top of the tree. If you try to reference an object that is not in your container, the naming syntax becomes complicated, especially for end users who do not have the training to understand NDS naming conventions (see fig 2.24).

NDS permits the definition of an object called the Alias object. An Alias object can point to a leaf or a container object. This capability is similar to the concept of symbolic links used in operating systems such as Unix, except that Unix symbolic links apply to file systems, whereas Alias objects are links to leaf objects in the NDS tree.

You can enter the value for the Aliased object directly or by selecting the Browse icon next to this field, which shows the Select Object dialog box (see fig. 2.25). In this figure, because the Alias object is being created under [Root], the only possible objects that you can alias are the Organization and Country objects. An attempt to alias another object produces an error message.

Figure 2.24 Accessing another object by means of alias.

Figure 2.25 Alias object creation.

Computer Objects

A Computer object is used to represent a non-server computer such as a workstation, minicomputer, or mainframe. You can even use it to represent a router, which is a specialized computer with multiple network boards and routing logic implemented in firmware or software. A Computer object can contain information such as network addresses, computer serial numbers, computer operators, and so forth (see fig. 2.26).

Figure 2.26 A Computer object.

Directory Map Objects

A Directory Map object contains a reference or pointer to a directory on a Volume object anywhere in the NDS tree. Currently, MAP objects are used only with the MAP command, which enables a workstation drive letter to refer to a network directory on a server. Using Directory Map objects can simplify the MAP command, which enables you to point to Volume objects in other containers.

A login script, a sequence of instructions that is executed when a user logs in, illustrates an important use of the MAP command. Login scripts are primarily used to set up a user's network environment. Consider a situation in which a login script containing the MAP command maps the drive letter G: to a directory in Volume object FS1_VOL in container O=ESL. If, at a later point, the Volume object is moved to another container, or if the directory path is changed, the mapping becomes invalid and all references to the former location of the Volume object and directory subsequently change. If, however, the Directory Map object is used to perform the mapping in the login script, only the Directory Map reference to the new volume/directory location changes, and the login scripts do not change. Figure 2.27 shows a Directory Map object in an NDS tree with some of its properties.

Figure 2.27 A Directory Map object.

Group Objects

A Group object is used to refer to a collection of users in the NDS tree, and can only refer to a collection of User objects. The Group object is used to conveniently assign a number of users the same security rights. Figure 2.28 illustrates the concept of groups. In figure 2.29, the users belong to the same container. This is the most common use of groups. The Group object permits users from other containers to belong to the same group.

Figure 2.28 The concept of groups.

The Group object is similar to the concept of groups in NetWare 3.x, except that Group is an NDS object instead of a Bindery ob- ject. There are, moreover, no default groups such as group EVERYONE that, by default, contain all users created on the NetWare 3.x server. To achieve the effect of a group such as EVERYONE, you can use container objects. By using the container name, you can treat all objects created in a container as a group. A Group object has a group membership property, which is a list of User objects defined anywhere in the NDS tree.

Figure 2.29 The Group object membership property.

Members of a Group object can only be User objects. On the other hand, you can use container objects as groups, but any leaf object or other container object can comprise a member of a container object. You can use container groups to provide a hierarchical relationship between groups that is not possible with Group objects and the groups used in NetWare 3.x. For instance, in NetWare 3.x, a group cannot contain other groups. This means the subset relationship between groups does not exist. By using containers that have a natural hierarchical relationship between them, subset relationships between groups is possible.

NetWare Server Objects

The NetWare Server object represents the physical NetWare server on a network. This is the object that provides NCP (NetWare Core Protocol) services. Some of the services provided by this object are represented as special objects in the NDS tree that reference the NetWare server. An example is the Volume object, which can be part of the physical NetWare server but is represented as a separate Volume object.

The NetWare Server object is created during installation. One of the parameters that you specify as part of the installation process is the container in which the NetWare server should be placed. The NetWare Server object contains information such as the physical location of the Server object, its network address, the service it provides, and so forth.

The NetWare Server object is referenced by other objects in the NDS tree. An example is the Volume object, which references the NetWare server that acts as its host server. Without the NetWare Server object, you could not reference the Volume object and, hence, the files on the volume.

Figure 2.30 shows a NetWare Server object in an NDS tree, and some of its properties. Notice that the status of the server is shown as being Up, and its IPX address is IPX:F0004101:000000000001:0451. The F0004101 refers to the eight-hexadecimal-digit internal network number of the NetWare server; 000000000001 refers to the 12-hexadecimal-digit node number; and 0451 refers to the four-hexadecimal-digit socket number for receiving NCP requests. The 000000000001 is a 12-hexadecimal-digit node number and is different from the hardware address of the board, sometimes also called the node address or the MAC (Media Access Control) address. The version number of the server is reported as Novell NetWare v4.10[DS]. The DS stands for Directory Services. For NetWare 4, this node number is always 1 when associated with a NetWare server.

Figure 2.30 The NetWare Server object.

Organizational Role Objects

The Organizational Role object refers to a position or role with which a set of responsibilities and tasks are associated within a department or organization. An example of such a role is the backup operator, who needs access to certain volumes to perform the backup operation. Another example is the print server operator. You can assign a User object to be an occupant of the Organizational Role object. In this case, the User object inherits all the rights that have been assigned to the Organizational Role object (see fig. 2.31). If the responsibility for performing the task is passed on to another user, you can change the user occupant of the Organizational Role object to reflect this.

Figure 2.31 The relationship between the User object and the Organizational Role object.

The Organizational Role object is useful in situations where the task performed by the organizational role does not change, but the person fulfilling that role does change. For example, the person assigned to perform backup tasks can change depending on the workload of individuals in an organization. Instead of changing the rights of the user for performing a certain task, you can assign these rights to the Organizational Role object. The occupant of the Organizational Role object can be changed, and this gives the assigned occupant sufficient rights to perform the organizational role's task. Figure 2.32 shows the Organizational Role object and the individual occupying that role. You can assign only User objects to the property occupant. Figure 2.32 indicates that the occupant of the organizational role is the User object CN=Admin1.OU=CORP.O=ESL.

Figure 2.32 The Organizational Role object.

Print Server Objects

A Print Server object describes the services provided by the NetWare Print Server. The Print Server object is created by the utilities PCONSOLE and NWADMIN (NetWare Administrator Tool), and contains a reference to all the Printer objects it services.

Figure 2.33 shows the Print Server object and some of its properties in the NDS tree. Notice that the print server has a property called the Advertising Name, the name used by the print server to advertise its services using SAP (Service Advertising Protocol). The status of the Print Server in the example indicates that it is down.

Figure 2.33 The Print Server object.

Print Queue Objects

The Print Queue object is used to describe the network print queues, and contains a reference to the Volume object on which the actual print jobs are stored. The Printer object is assigned to a Print Queue object. Print jobs sent to the Printer object go to the associated print queue. As in NetWare 3.x, print jobs can also be sent to the print queue.

Figure 2.34 shows the Printer Queue object in the NDS tree. No- tice that the Volume property indicates the Volume object that is used to support the print queue. Print queues are stored in the QUEUES directory on the specified volume.

Printer Objects

The Printer object is used to describe the physical network printer device. The Print Queue object references the Volume object on which the actual print jobs are stored. Printer objects are assigned to print queues. Print jobs sent to the Printer object go to the associated print queue. As in NetWare 3.x, print jobs can also be sent specifically to the print queue.

Figure 2.34 The Print Queue object.


PRACTICAL TIP: There are additional restrictions for sending jobs to Printer objects. For instance:


Figure 2.35 shows a Printer object in the NDS tree, and the properties of the Print object that contains references to other printer-related objects. In figure 2.35, the Print Queues property list has just one Queue object assigned to it at a priority of 1 (highest). This means that print jobs sent to the Printer object will be sent to the queue represented by the object CN=Q1.O=ESL. The Print Server this printer services is CN=PS-ESL.O=ESL.

Figure 2.35 The Printer object and the Assignment properties.

Profile Objects

The Profile object represents common actions that are performed during login processing--specifically, a login script that is shared by a number of users. Different containers can hold the User objects that share the login script.

The Profile object is listed as a property of a User object, and is executed when an individual uses the User object to log in to the network. Other types of login scripts, such as the system login script and user login scripts, exist. These scripts, however, are properties of the container object and the User object, and do not exist as separate NDS objects. The Profile object is the only login script type that can exist as an independent NDS object.

Figure 2.36 shows a Profile object in an NDS tree, and the login script contained in the Profile object.

Figure 2.36 The Profile object.

User Objects

A User object represents the user account of the individual logging in to the network. This is the most important object as far as the user is concerned. Changes made to this object affect the user directly. A User object must exist for every user that needs to log in to the network. The User object is defined in the NDS tree, which makes it different from NetWare 3.x, in which User objects were defined on a server. Using this single User object, an individual can access all the servers and other network resources to which the user has been assigned rights.

Some of the attributes (called properties in NDS terms) of the User object include: a home directory on a Volume object to which the user has rights, login restrictions, intruder lock out mechanism enabling/disabling, and so forth.

Figure 2.37 shows a User object defined in the NDS tree and some of its properties.

Figure 2.37 The User object.

A User object with the special name USER_TEMPLATE functions as a template for creating default property values for User objects within that container. Only one USER_TEMPLATE object can exist within a container (such as Organization, or Organizational Unit) that enables the creation of such objects.

Volume Objects

The Volume object represents the physical volume that is attached to the server. It also represents data storage and the file system on the network, and is used to store print jobs associated with a network queue.

Although the Volume object appears to be independent of the NetWare server, the Volume object has a logical connection to the NetWare Server object to which it is attached. For this reason, Volume objects have a property called the host server, which associates the volume with its host NetWare server (see fig 2.38).

Figure 2.38 The Volume object.

The Volume object is created when the NetWare 4.x server is first installed in a container. The volume is given a default NDS name that consists of the name of the NetWare 4.x server, followed by an underscore, and the name of the physical volume such as SYS, VOL1, and so forth. The physical name of a volume is the name given when the volume is first initialized as part of the installation process using INSTALL NLM. NDS Volume object name = Object Name of Server _ Physical Volume Name If, therefore, the NetWare Server object name is NW4CS, the first physical volume on it that has the name SYS has an NDS name of NW4CS_SYS. If the server has a second volume named VOL1, its NDS name is NW4CS_VOL1.

Bindery Objects

The Bindery object is created when you place a NetWare 3.x service in the NDS tree as part of the upgrade or migration utility. The internals of this object cannot be managed by NDS. The Bindery object is used to provide bindery emulation services, which enable a NetWare 4.x server to be accessed by NetWare 3.x client software that expects to see a bindery-based server.


PRACTICAL TIP: To access NetWare 4.x servers by NetWare 3.x client software, the SET BINDERY CONTEXT parameter needs to be set at the NetWare server. This parameter is set by default during installation of the NetWare server to the context in which the server is installed. You can additionally define up to 16 containers for the bindery context or up to 255 characters for the bindery context, depending on which limit is reached first. Bindery objects are created only when there is no equivalent object type within the set of standard NDS object types. Certain utilities such as SBACKUP.NLM and AUDITCON.EXE use bindery emulation, and do not work correctly if BINDERY CONTEXT is not set.

Bindery Queue Objects

The Bindery Queue object represents a NetWare 3.x print queue placed in the NDS tree as part of the upgrade or migration process. It is used to provide compatibility with bindery-based utilities and applications.

Distribution List

The Distribution List object was defined starting with NetWare 4.1. A Distribution List object represents a collection of objects that have mailboxes. You can assign objects such as the Organizational Unit, Group, or User objects to a distribution list. This enables you to send the same message to many different recipients by sending it to the Distribution List object.

Distribution lists can be nested. In other words, a distribution list can have other distribution lists as members. However, members of distribution lists do not have security equivalence to the Distribution List object.

Figure 2.39 shows some of the properties of a distribution list. The MailBox page button describes the Mailbox Location property, which is the name of the messaging server that contains the mail- boxes. The Mailbox Location is a property of Organization, Organizational Role, Organizational Unit, Distribution List, Group, and User objects in NetWare Directory Services.

Figure 2.39 The Distribution List object.

Message Routing Group

The Message Routing Group object was defined starting with NetWare 4.1. A Message Routing Group object represents a cluster of messaging servers in the NDS tree. Because the messaging servers do frequent synchronizations among themselves, you should try to avoid connecting message servers in a message routing group through expensive or low-speed remote links. All messaging servers connected to the same message routing group send messages directly among themselves.

Figure 2.40 shows some of the message routing group properties. The Name field is the name you assign to the Message Routing Group object. The Postmaster General is the User object who owns and administers the Messager Routing Group. The Postmaster General can modify the Message Routing Group object and its attributes (it has Supervisor object right to the Message Routing Group).

Figure 2.40 The Creation dialog box for a Message Routing Group object.

Note that a user who has the following rights is called a Postmaster:

You will learn more about object and property rights later in this book.

External Entity

The External Entity object was defined starting with NetWare 4.1. An External Entity object represents a non-native NDS object or service that is imported into NDS or registered with NDS. An example of this might be a non-MHS e-mail address. By importing the non-MHS e-mail address into NDS, you can build an integrated address book for sending mail.

External entities are particularly useful if your messaging environment contains non-MHS Messaging Servers, such as SMTP (Simple Mail Transfer Protocol) hosts, SNADS (Systems Network Architecture Distribution Services) nodes, or X.400 MTAs (Message Transfer Agents). You can then add e-mail addresses of users and distribution lists for these non-MHS servers to the NDS. These non-NDS objects are added as external entities. Having done this, the non-MHS addresses are not accessible by the native NDS messaging applications. This enables MHS users to select non-MHS users and lists from a directory list.

An External Entity object has an External Name property that specifies the NDS name of the External Entity, and a Foreign E-mail Address property that specifies the user's mailbox, which is in a foreign messaging system. Figure 2.41 shows that the foreign e-mail address is an SMTP mailbox, with the address SMTP:karanjit@siyan.com. The e-mail address karanjit@siyan.com is in the format of the SMTP (Internet e-mail) address. Messages sent to this user can be delivered to an SMTP gateway.

Figure 2.41 The External Entity object.

It is important to note that an NDS object can have a mailbox property or a foreign E-mail address property, but not both. These E-mail property values can be assigned when you create an object or at a later time.

Messaging Server

The Messaging Server object is a leaf object that represents a message server program, typically running on a NetWare server. The purpose of the messaging server is to route messages delivered to it. If a message recipient has a mailbox that is local to the Messaging Server, the message is delivered locally; otherwise, the message is transferred to other message servers. Message servers act as store-and-forward message transfer agents.


AUTHOR'S NOTE: For those familiar with the OSI definition of a Message Transfer Agent (MTA), the Messaging Server is an MTA.

The NetWare 4.x servers ship with the MHS.NLM, which implements the MHS Messaging Server. Figure 2.42 shows some of the properties of a Messaging Server.

Unknown Objects

The Unknown object represents an NDS object, the object class of which cannot be determined because its NDS information has been corrupted.

An Unknown object appears if you bring the server down and then up again while specifying a different server name or delete the Server object. New volume names appear, and the old volume names become unknown objects. Also, if you remove the object that an alias Volume object points to, the Alias object appears as an Unknown object.

Figure 2.42 Messaging Server properties.

Unfortunately, if you have an existing server in a DS tree and you decide to rename the server, only the server name is changed automatically. The Volume objects will still have the old server name and volume name. You have to change the Volume object name manually. The old volume names do not become Unknown objects.


STUDY NOTE: Too many Unknown objects in an NDS tree can signal NDS directory corruption. Running the DSREPAIR utility can fix this problem.

Table 2.4 summarizes the previous discussion and briefly describes each type of leaf object.

Table 2.4 Leaf Object Descriptions

Leaf Object Class Meaning
AFP Server An AppleTalk File Protocol Server. Used for informational purpose.
Alias A link to another object. This is a substitute name for an object that points to another object in the NDS tree.
Computer An object that represents a computer: workstation, minicomputer, mainframe, and so on. It is used for informational purposes.
Directory Map An object that makes it possible to perform a simple drive mapping to another container. Makes it easier to maintain login scripts.
Group An object whose members can be other objects. Similar to the concept of groups in NetWare 3.x, except that Group is an NDS object, instead of a Bindery object.
NetWare Server Represents a NetWare server on a network. This is the object that provides NCP (NetWare Core Protocol) services. Some of the services provided by this object are represented as special objects in the NDS tree that references the NetWare server.
Organizational Role Represents a position that has a certain set of defined tasks and responsibilities, and can be performed by any user assigned that role.
Print Server Represents the Print Server service.
Print Queue Represents the network print queue that holds the print jobs before they are printed.
Printer Represents a network printer that can accept print jobs sent to it.
Profile Represents an object that can be used for shar-ing of common actions that are performed during the login processing, regardless of whether they are in the same container.
User The object that represents the user account. Used to contain information on the users who use the network.
Volume The object that represents data storage on the network. Used to represent the file system on the network used for storing files and print jobs associated with a network queue.
Bindery object The object created when placing a NetWare 3.x service in the NDS tree as part of the upgrade process. Internals of this object cannot be managed by NDS. It is used to provide bindery emulation services.
Bindery Queue Created as part of the upgrade process. It represents a NetWare 3.x print queue.
Distribution List Represents a list of mail boxes or other distribution lists. This simplifies sending the same E-mail to a group of users. Distribution lists can contain other distribution lists.
Message Routing Represents a group of messaging servers
Group that can transfer messages directly amongst themselves.
External Entity Represents a non-native NDS object/service that is imported into NDS or registered in NDS. For example, MHS services can use External Entity objects to represent users from non-NDS directories such as SMTP, SNADS, X.400, etc. This enables MHS to provide an integrated address book for sending mail.
Messaging Server A Message Transfer Agent for e-mail applications.
Unknown Represents an NDS object whose object class cannot be determined because its NDS information has been corrupted. Running DSREPAIR can fix this problem.

Object Properties

Objects have attributes called properties that represent the types of information that you can store in the object. In this sense, an NDS object is similar to a record in a database, and the properties of the object are similar to the different field types that you can have in a record.

Figure 2.43 shows the File Server object. The File Server object, in this figure, shows such properties as Name, Network Address, and Location. The actual value assigned for each property is called the property value. A property value is an instance of the property type. Some object properties are mandatory and critical for proper use of the object. Other properties are descriptive and used for informational and documentation purposes, which enables the use of the NDS as a database of management information.

Figure 2.43 NDS object and properties.

The critical values are filled out by the network administrator at the time of the object's creation. The network supervisor, who has Write access to properties, can fill out at a later time the values that are used for information and documentation. An example of User object properties, which are for informational purposes, is the list of telephone and fax numbers for the user, and the user's postal address and job title. A User object's name property is mandatory.


STUDY NOTE: The type of information that is stored in an NDS object is called a property.

The value of an information item that is stored in an NDS object is called a property value.

Some object properties are mandatory; others are optional and are used for descriptive purposes.




PRACTICAL TIP: Fill out as many property values for an object as you have information for because the NDS tree can be used as a database of information that you can query by using tools such as NLIST.

You can have single-value or multivalue properties. A property such as the login name of the user is single-valued, whereas the telephone number for a user is multivalued and represented as a list of values.


Exploring an NDS Tree Case Study

Consider the organization MICROCON, which makes advanced semiconductor devices. Its manufacturing plants and research labs are in San Jose, but its marketing and sales department is in New York. The San Jose facility has a VAX computer, a NetWare 4.x file server used for manufacturing and testing, and another NetWare 4.x server for R&D. The R&D engineers are Rick and James; the manufacturing engineers are Tom and Bill. Ed is the network administrator of the entire network.

The New York facility has two file servers, NY_FS1 and NY_FS2, that are shared by all the users at that facility. Kirk is the overall network administrator. The SALES department is a department within the MARKETING group. Currently, the salespeople are Janice, Jane, and John. Ron works in the Marketing department, which at the moment is understaffed.

A diagram of MICROCON's physical network is shown in figure 2.44. Figure 2.45 shows the NDS tree structure for this organization. Because users Ed and Kirk have network administrator responsibilities, their User objects are defined directly under the containers OU=ENGINEERING and OU=MARKETING. Shared resources used by all users of the San Jose and New York networks also are assigned directly within these containers. Examples of these shared resources are the printer FS1_PRT and the file servers NY_FS1 and NY_FS2. File servers FS1 and FS2 are placed in the containers OU=MANUFACTURING and OU=R&D. The SALES division is defined as a subcontainer of OU=MARKETING. The salespeople's User objects are defined in the OU=SALES container.

Using the previous example, draw a physical network and an NDS tree for the organization Electronic Systems Lab (ESL) based in London, with facilities in Toronto, New York, and Paris. ESL's research labs are located in Paris and Toronto, with marketing in New York and administration and sales in London. A support staff of network administrators in London manages the entire network. Network services and hardware support at other sites are performed by local contractors. Each location has its own servers and printers.

Although other locations have a single file server and two network printers attached to the file server, London and New York both have two file servers each and three network printers. As the company grows, it is expected that additional servers will be added. All locations have their own print servers. The locations are tied together with communications links that run at 1.544 Mbps. The local networks used at each site are based on Ethernet.

Make reasonable assumptions for data that is not provided in this case study. For instance, you might have to invent names for users at each location, and decide which of the users are going to be network administrators.

Figure 2.44 The MICROCON physical network.

Figure 2.45 The MICROCON NDS tree.

When you design the NDS tree for ESL, consider the following:

Using NDS Tools

The two primary tools for creating, deleting, and moving NDS objects are:

Another tool for user batch creation is UIMPORT. UIMPORT is similar to the NetWare 3.x MAKEUSER tool. Because UIMPORT is outside the scope of this book, it is not discussed here.

The Network Administrator Tool is a Windows and OS/2 GUI (Graphical User Interface) tool that you can use to manage NDS objects, whereas the NETADMIN tool is a text utility for creating NDS objects using C-Worthy menus.

Setting Up the Network Administrator Tool (NWADMIN.EXE)

To set up the NWADMIN.EXE tool, you must have installed the NetWare 4.x server and the DOS/Windows client software. The following steps show ways to set up the NWADMIN tool for MS Windows.

If one does not already exist, you must set up the NetWare program group in Program Manager. To set up the NetWare program group, follow these steps:

1. Make sure that you are logged in to the NetWare 4.x network.

2. Select the File menu from Program Manager.

3. Select the New option from the File menu.

4. Select Program Group from the New Program Object dialog box and select the OK button.

5. In the Program Group Properties box, type NetWare in the Description field. In the Program Group File field, type C:\WINDOWS\NWUTILS.GRP (or whichever is the Windows directory). Select OK.

If one does not already exist, perform the following steps to create a program item for NetWare Administrator Tool:

1. Highlight the NetWare program group.

2. Select the File Menu from the Program Manager.

3. Select the New option from the File menu.

4. Select the Program Item from the New Program Object dialog box and select the OK box.

5. In the Program Item Properties box, type NetWare Administrator Tool in the Description field. In the Command Line field, type Z:\PUBLIC\NWADMIN. In the Working Directory field, type Z:\PUBLIC. Select OK.

You can specify a network drive other than Z:. Z: is used because you are likely to have at least one search drive, and this will be mapped to search drive Z:. You will have to make sure that this search drive is not "root mapped."

Select Yes when the message "The specified path points to a file might not be available during later Windows sessions. Do you want to continue?" appears. This message appears because the path is a network drive, and unless you are logged in to the network, the network drive will not be available.

The program item for NWADMIN should appear in the NetWare program group.

Using the NetWare Administrator Tool

This section gives you a guided tour of the creation of the NDS tree structure shown in figure 2.46, using the NetWare Administrator Tool and assuming that you are familiar with MS Windows.


STUDY NOTE: You should be very familiar with performing the operations of creating and deleting contain- ers using the NWADMIN tool. A simulated NWADMIN tool is used in the test engine for the CNE exams.

Figure 2.46 A sample NDS tree.

1. Log in to the network as an Administrator account.

When the NDS services are first installed (at the time the first NetWare 4.x server is installed), a default network administrator user object Admin is created that has supervisor privileges to the entire NDS tree. You can use the Admin user object to login to the network.

2. Activate the NetWare Group and launch the NetWare Administrator Tool program item (double-click on the NetWare Administrator icon).

You should see a screen similar to that shown in figure 2.47, which shows the NDS tree beginning from the current container.

Figure 2.47 The NetWare Administrator menu.

3. To see the NDS tree beginning from the [Root], Select the View menu. Select the Set Context option.

Set the current context to [Root]; which you can do by entering [Root] in the context field or by using the Browse button to browse through the NDS tree and select the context that you want to set as the current context.

4. Highlight the [Root] object. You can do this by clicking on it once.

5. Right-click on the [Root] object to see a list of operations that you can perform under the [Root]. Select Create.

You should see a list of objects that you can create under the [Root] object, as seen in figure 2.48.

Figure 2.48 New objects under [Root] container.

6. Select the Organization object and click OK. You should see a dialog box for creating the Organization object (see fig. 2.49).

Enter the name of the Organization shown in figure 2.46, and select the Create button. You should see the name of the newly created organization MICROCOMM appear in the NDS tree.

7. Highlight MICROCOMM and right-click. Select Create. You should see a list of objects that you can create under the Organization object (see fig. 2.50).

Compare figure 2.50 with figure 2.48. Notice that the list of objects that you can create under an Organization object is much larger.

Figure 2.49 The Create Organiza-tion dialog box.

Figure 2.50 New objects under the Organization container.

8. Select the Organizational Unit object and click on OK. You should see a dialog box for creating the Organizational Unit object (see fig. 2.51).

Enter the name of the Organizational Unit CORP, shown in figure 2.46, and select the Create button. You should see the name of the newly created Organizational Unit CORP appear in the NDS tree if you double-click on MICROCOMM.

9. Repeat steps 7 and 8 to create Organizational Unit container objects for MARKETING and ENGINEERING as shown in figure 2.46. You can check the box labeled Create Another Organizational Unit to speed up creation of objects of the same class.

Figure 2.51 The dialog box for creating the Organizational Unit container.

10. Repeat previous steps to create the rest of the organization as shown in figure 2.46.

11. Delete the NDS tree you have just created. You cannot delete a container object that has objects defined in it. You must, therefore, begin with the bottommost objects and delete them first.

To delete an object, right click on the object and select the Delete operation. Alternatively, highlight the object and select the Object menu, and select the Delete operation from the menu.

To delete a group of objects, perform the following steps:

1. Open the container by double-clicking on it.

2. Highlight the first object to be deleted. Click on the last object to be deleted while holding the Shift key. You should see the objects between the first and the last object highlighted.

3. Press the Delete key.


PRACTICAL TIP: You can also use the Ctrl key to highlight non- contiguous objects upon which you want to perform operations.

Using the NETADMIN Utility

This section gives you a guided tour of the creation of the NDS tree structure using the NETADMIN tool. NETADMIN is a text-based utility that provides a similar functionality to the NetWare Administrator tool. As a system administrator, it is very useful to be able to perform NDS operations using NETADMIN, because you might run into situations where MS Windows is not installed at a NetWare workstation. NETADMIN can work directly on top of DOS, and does not require MS Windows.

The guided tour's goal for this session is to accomplish the same objectives as in the previous section, so that you can compare the differences between the NetWare Administrator and the NETADMIN tools.

1. Log in to the network as an Administrator account.

When the NDS services are first installed (at the time the first NetWare 4.x server is installed), a default network administrator user object, Admin, is created that has supervisor privileges to the entire NDS tree. You can use the Admin user object to log in to the network.

2. The NETADMIN utility is located in the SYS:PUBLIC directory, and you must have a search path to that directory for the NETADMIN command to work correctly.

To invoke the program NETADMIN, enter:
NETADMIN
You should see the NETADMIN screen shown in figure 2.52.

Figure 2.52 NetAdmin options.

The current context is seen on top of the screen under the label Context. If this is not set to [Root], perform the following steps to set it to [Root]:

a. Select "Change context."

b. Type [Root] when asked to "Enter context:".

c. Press Enter to go back to the NETADMIN main menu with the changed context.

3. Select "Manage objects." You should see a list of objects and their classes under the [Root] container (see fig. 2.53).

Figure 2.53 Object classes under [Root] using NetAdmin.

4. Press the Insert key. You should see a list of objects that you can create under [Root] (see fig. 2.54).

Figure 2.54 Object classes under [Root] using NetAdmin.

5. Select "Organization" to create an Organization object. You should see a box for creating the Organization object (see fig. 2.55).

Figure 2.55 NetAdmin box for creating an Organi-zation container.

Enter the name of the organization shown in figure 2.46. You can elect to create a User Template for the Organization object at this point or defer this action until later.

6. Press F10 to save changes and perform the create operation.

When prompted to create another Organization object, answer No. You should see the name of the newly created organization appear in the Object, Class list.

7. Highlight the newly created organization and press Enter. Notice that your context has changed to the organization.

8. Press Insert to create an object. You should see a list of objects that you can create under the Organization object (see fig. 2.56).

Figure 2.56 Object classes under Organization container using NetAdmin.

9. Select the "Organizational Unit" choice to create an Organization object. You should see a box for creating the Organizational Unit object (see fig. 2.57).

Figure 2.57 The NetAdmin box for creating an Organizational Unit container.

Enter the name of the Organizational Unit shown in figure 2.46. You can elect to create a User Template for the organization object at this point or defer this action till later.

10. Press F10 to save changes and perform the create operation.

11. When asked to create another Organizational Unit object, answer Yes and repeat the previous steps to create all the other Organizational Unit objects.

12. Review figure 2.46 and repeat the previous steps to create the rest of the organization, as shown in figure 2.46.

13. Delete the NDS tree you have just created. You cannot delete a container object that has objects defined in it. You must, therefore, begin with the lowest objects and delete them first.

To delete an object, highlight it from the Object, Class list and press the Delete key. You will be asked to confirm your delete operation. You can also delete several objects by marking them with the F5 key and then pressing the Delete key.

Understanding NDS Context

NDS context is a term used to describe the position of an object in the NDS tree in terms of the container that contains the object. For example, in figure 2.58 the context of object Admin is container ESL, and the context of the File Server object FSP_1 is in container CORP.

Figure 2.58 An NDS context.

The context of an object is important because some NDS utilities require you to know the position (or location) of the object in the NDS tree. In general, you must know the object's position (context) so that you can find it. (There are commands, such as the NLIST command, that help you find the object's position in the NDS tree, if you know its name. These will be discussed later in this chapter). The context of an object affects the ways the object is referenced.

The context can also be seen as a pointer that locates the object's position in the NDS tree. The context is described by listing, from left to right, the NDS names of the container objects, separated by periods (.). The order of listing of container objects is to begin with the immediate container and work your way up to the root. Therefore, the context of object Admin in figure 2.58 is Admin.ESL or CN=Admin.O=ESL because only one container exists. The [Root] container object is not listed because it is always implied that the topmost container is [Root]. In the second method of representing the NDS context, an object-type designator such as O (Organization) is used. Both forms are valid, with the second form using attribute-type designators.


STUDY NOTE: The position of an object in an NDS tree is called its context. It locates where you can find an object in the NDS tree. The context of an object refers to its container. The context can never be set to a leaf object (because leaf objects cannot contain other objects).

Another example is the context of object FSP_1 in figure 2.58: FSP_I.CORP.ESL or CN=FSP_I.OU=CORP.O=ESL The [Root] container object is not listed, because it is always implied that the topmost container is [Root]. In the second form of NDS context representation, the object-type designators CN (Leaf Object), OU (Organization Unit), and O (Organization) are used.

A special type of context called the current context indicates the current position of the attached workstation in the NDS tree. An attached workstation is one that is connected (logically speaking) to the NDS tree by means of the network.

When the network client software loads, it makes a connection to the NDS tree. If DOS is used as the workstation software, it can maintain only one current context at a time for each DOS session. You can set the workstation's current context only to container objects and not leaf objects, because a context is defined as the position of the immediate container that contains the object in the NDS tree.

The current context is the default reference point used by the workstation to find other objects in the NDS tree. It is used in the same manner as the concept of the current directory in a file system. Just as the current directory cannot be set to a file name, the current context cannot be set to a leaf object.


STUDY NOTE: The current context is an attached workstation's current position in the NDS tree.

You can use the current context as a reference point to find other objects in the tree.


Leaf objects that are in the current context of a workstation are referred to by their object names. For instance, if a workstation's current context is CORP.ESL, the user of that workstation can reference objects FS1 and PS1 by their common names: FS1 or CN=FS1 PS1 or CN=PS1 It is not essential to use the full NDS name of the object in this case. This is a great convenience to the user of the workstation. Resources that are not in the current context cannot be referred to by their leaf names only; you must specify the NDS path name of the object. Objects FS2 and PS2, in figure 2.59, must be referenced by their NDS path names.

Figure 2.59 Referencing objects in another context.


STUDY NOTE: You can refer to NDS objects that are in the current context of a workstation by their leaf object names.

NDS objects that are not in the current context of a workstation must be referred to by their NDS path name.

Group frequently accessed resources in the user's context to simplify access to these objects.


Specifying NDS Path Names

In the previous section, you observed that objects not in the current context of a workstation must be defined by their NDS path names. There are three ways of specifying NDS path names:


STUDY NOTE: In the Novell documentation, the terms complete name and partial name are used. In the latest versions of the tests, the X.500 terms of Distinguished Name and Relative Distinguished Name are used.

Complete Name

A complete name is the name of an NDS object that includes the leaf name and the names of the containers that contain the leaf object, beginning from the leaf object and going up the tree to the [Root] object. The object names are specified with their attribute name abbreviation (attribute type). The complete name must always begin with a period (.). Periods between object names that make up the NDS name are used as separators for the object names. The complete name is also called the Distinguished Name (DN).

This is an important point to note: The leading period has a different meaning than other periods used in the NDS object name; it signifies that the name is a complete name, and that you can reference the object by enumerating its path--listing the object name and its containers--all the way to the root object.

The general syntax of the complete name of an object is:

.CN=leaf_object.[OU=org_unit_name.{OU=org_unit_name}].O=org_unit.[C=country]

In the previous syntax, the [] brackets and the {} braces are meta characters that have a special meaning. The [] indicates that the contents between the [] are optional. The {} indicates that you can have zero or more occurrences. The leading period is required for complete names. Without the leading period, the complete name becomes a partial name.

To summarize some of the rules of a complete name: the syntax for a complete name always begins with a period, followed by the NDS path of the object all the way up to the root. Because you can have only one [Root] per NDS tree, the [Root] object is not listed as part of the NDS tree. If an attribute type is used to qualify the object name in the NDS path, it will have the following form:

attribute_type_abbreviation=object_name

The attribute_type_abbreviation will be CN for leaf object, OU for Organizational Units, O for Organization, and C for Country. After the name of the object, the list of containers beginning with the most immediate container, and continuing all the way to the [Root] container are enumerated. Because you can have only one [Root], the root object is not listed. The square brackets around the Organizational Unit list indicate that the OUs are optional. Examples of types of complete names follow:

.CN=leaf_object.O=org_unit.C=country

or

.CN=leaf_object.O=org_unit

or

.leaf_object.org_unit

The last example is a typeless complete name, which does not have the attribute types. The C=country has been left out of the syntax example of the complete name, because the Country object is optional.

The most general case of the complete name lists the Organizational Units, a single Organization, and a Country name as shown in the following:

.CN=leaf_object.OU=org_unit_name.OU=org_unit_name.O=org_unit.C=country

In the previous syntax example, only two Organizational Unit objects are shown, but there could be any number of these objects.

In figure 2.60, the complete names of objects FS1, PS1, PRINT_1, PRINT_2, and PS2 follow: .CN=FS1.OU=REGION_A.O=HAL

.CN=PS1.OU=REGION_A.O=HAL

.CN=PRINT_1.OU=OPS.OU=SALES.O=HAL

.CN=PRINT_2.OU=SALES.O=HAL .CN=PS2.O=HAL

Figure 2.60 The NDS tree for complete name examples.

Partial Name

A partial name for an NDS object is its NDS path relative to the current context. This is in contrast to the complete name that lists the NDS path objects relative to the root of the tree. A partial name is similar to specifying the name of a file relative to the current directory, and a complete name is similar to specifying the name of a file, using its complete path name that lists all the directories beginning from the root. The partial name is also called the Relative Distinguished Name (RDN).


AUTHOR'S NOTE: In X.500, the object's full path name, with reference to its position in the NDS tree, is called its Distinguished Name (DN); and the name relative to a context is called the Relative Distinguished Name (RDN). The NDS term for this is complete name. The Distinguished Name of an object is formed by adding the RDN of the object to the DN of the object's parent. You should be familiar with the X.500 terms for taking the test.

The X.500-equivalent term for the NDS database is the Directory Information Base (DIB), and the NDS tree is referred to as the Directory Information Tree (DIT) in X.500 terminology.


Resolving a Partial Name

The NDS must resolve the partial name to a complete name. This is done by appending the current context to the partial name and adding a period at the beginning to indicate a complete name, as in the example that follows: Complete Name = .Partial Name.Current Context Another example will help clarify the preceding rule:

If the current context is OU=CORP.O=ESL, the partial name for object HP_PR1 that is in the same context is CN=HP_PR1. NDS forms the complete name by appending the current context OU=CORP.O=ESL to the partial name CN=HP_PR1, and adding a period at the beginning. Current context OU=CORP.O=ESL

Partial name CN=HP_PR1 Complete name .CN=HP_PR1.OU=CORP.O=ESL The main purpose of a partial name is to simplify the names for NDS objects that are in the current context or in the vicinity of the current context.

The examples so far have been of objects in the current context. In figure 2.61, the object FSP_1 is not in the same context as the current context that is set to O=ESL. In this case, the partial name of FSP_1 is the object name plus the list of all the containers leading up to the current context O=ESL. In other words, the partial name for FSP_1 is: CN=FSP_1.OU=CORP Similarly, if the current context is O=ESL, the partial name of ENG_FS_VOL is: CN=ENG_FS_VOL.OU=ENGI If the current context is O=ESL, the partial name of Admin is: CN=Admin What if the current context is not set to a container that is part of the complete name leading up to the root? In this case, appending a period (.) at the end of the NDS name refers to the previous container. In figure 2.61, the current context is OU=ENG.O=SCS. If the object DEI_FS in OU=CORP is to be referenced, you can use the partial name CN=DEI_FS.OU=CORP.

Figure 2.61 The partial name for objects not in current context, but in the same tree branch.

The trailing period (.) refers to the parent container of the current context, which in this case is O=SCS. The partial name of the object DEI_FS with respect to the container O=SCS is CN=DEI_FS.OU=CORP, but because the current context is in a different tree branch (current context is OU=ENG.O=SCS and not O=SCS), a trailing period must be added.

If the current context in figure 2.62 were OU=OPERATIONS.OU=ENG.O=SCS, you could refer to the same object, CN=DEI_FS, by the partial name CN=DEI_FS.OU=CORP..

Figure 2.62 The partial name for objects when the current context is in a different branch of the NDS tree.

Two trailing periods signify two parent containers above the current context. Because the current context is OU=OPERATIONS.OU=ENG.O=SCS, the two trailing periods refer to the container O=SCS.

The trailing period can occur only in partial names.

A summary of the trailing period rules follows:

1. A single trailing period rule at the end of the NDS partial name removes a single object name from the current context.

2. The resulting name, formed by removing a leftmost object from the current context, is appended to the partial name.

3. A leading period is added to form a complete name.

Relative Distinquished Names Example Exercise

The Relative Distinguished Names for objects HP_PR1, FS1, VOL1, FS2, and BOB in figure 2.63 are listed in table 2.5 for different current context settings.

Figure 2.63 The NDS tree for Relative Distinguished Name examples.

Table 2.5 Partial Name Examples

NDS Object Current Context Relative Distinguished Name
HP_PR1 [Root] CN=HP_PR1.OU=SOPS.O=SAS
HP_PR1 O=SAS CN=HP_PR1.OU=SOPS
HP_PR1 OU=SOPS.O=SAS CN=HP_PR1
HP_PR1 OU=R&D.O=SAS CN=HP_PR1.OU=SOPS.
HP_PR1 OU=RES.OU=
R&D.O=SAS
CN=HP_PR1.OU=
SOPS..
HP_PR1 OU=EXPL.OU=
SOPS.O=SAS
CN=HP_PR1.
FS1 [Root] CN=FS1.O=SAS
FS1 O=SAS CN=FS1
FS1 OU=SOPS.O=SAS CN=FS1.
FS1 OU=EXPL.OU=
SOPS.O=SAS
CN=FS1..
FS1 OU=R&D.O=SAS CN=FS1.
FS1 OU=RES.OU=
R&D.O=SAS
CN=FS1..
FS1_VOL1 [Root] CN=FS1_VOL1.OU=
EXPL.OU= SOPS.O=SAS
FS1_VOL1 O=SAS CN=FS1_VOL1.OU=
EXPL.OU=SOPS
FS1_VOL1 OU=SOPS.O=SAS CN=FS1_VOL1.OU=EXPL
FS1_VOL1 OU=EXPL.OU=
SOPS.O=SAS
CN=FS1_VOL1
FS1_VOL1 OU=R&D.O=SAS CN=FS1_VOL1.OU=
EXPL.OU=SOPS.
FS1_VOL1 OU=RES.OU=
R&D.O=SAS
CN=FS1_VOL1.OU=
EXPL.OU=SOPS..
FS2 [Root] CN=FS2.OU=R&D.O=SAS
FS2 O=SAS CN=FS2.OU=R&D
FS2 OU=SOPS.O=SAS CN=FS2.OU=R&D.
FS2 OU=EXPL.OU=
SOPS.O=SAS
CN=FS2.OU=R&D..
FS2 OU=R&D.O=SAS CN=FS2
FS2 OU=RES.OU=
R&D.O=SAS
CN=FS2.
BOB [Root] CN=BOB.OU=RES.OU=
R&D.O=SAS
BOB O=SAS CN=BOB.OU=RES.OU=
R&D
BOB OU=SOPS.O=SAS CN=BOB.OU=RES.OU=
R&D.
BOB OU=EXPL.OU=
SOPS.O=SAS
CN=BOB.OU=RES.OU=
R&D..
BOB OU=R&D.O=SAS CN=BOB.OU=RES
BOB OU=RES.OU=
R&D.O=SAS
CN=BOB


STUDY NOTE: Study the examples in table 2.5 so that you thoroughly understand the formation of Relative Distinguished Names.


AUTHOR'S NOTE: The X.500 standard defines ways that Distinguished Names are exchanged between OSI systems. Typically this is done using ASN.1 (Abstract Syntax Notation 1), which unambiguously transmits the Distinguished Names across the network. When dealing with implement