'; zhtm += '

' + pPage + ''; zhtm += ''; window.popUpWin.document.write(zhtm); window.popUpWin.document.close(); // Johnny Jackson 4/28/98 } //-->

Migrating to Netware 4.1

- 2 -

Designing Your NDS Tree

Defining NDS
The Difference between NDS and the NetWare Bindery
Understanding the NetWare Directory Database
Defining NDS Components
- Tree Structure of NDS
- Container Objects
- Leaf Objects
- Object Class and Schema
- Containers and Directories in File Systems
Understanding Object Names
Defining Container Object Types
- The [Root] Object
- The Country Container Object
- The Organization Object
- The Organizational Unit Object
- Attribute Types
- Leaf Object Types
- Object Properties
- NDS Tree Case Study
Understanding NDS Context
Naming NDS Paths
- Complete Name
- Partial Name
Learning NDS Naming Rules
- NDS Path
- Typeless Name
Considering NDS Partitions
- Cost of Synchronizing Replicas
- Default Partitions and Replicas
- Guidelines for Managing Partitions and Replicas
Designing an NDS Tree
- Creating a Structural Design for the NDS Tree
Understanding NDS Design Criteria
- Security of the NDS Tree
- Partitioning and Replication of the NDS Tree
- Synchronizing Time in the NDS Tree
Designing the NDS Tree
- NDS Design--Case Study 1
- NDS Design--Case Study 2

Before you install a NetWare 4.x network, you must plan it; and before you can plan it, you must thoroughly understand NetWare Directory Services (NDS). NDS is an essential feature of NetWare 4.x, and it is the single most important difference between NetWare 4.x and NetWare 3.x. All network resources are represented, accessed, and managed through NDS. In this chapter, you learn the basic concepts of NDS and how to apply those concepts to designing your own NDS tree. A successful migration begins with a well-designed NDS tree, so this chapter is one of the most important in the book.

The chapter begins with a brief introduction to NDS and continues with the following topics:

NDS components
NDS context
NDS paths
NDS naming rules
Partitions and replicas
NDS tree design

After you master these topics, you will have gone a long way toward understanding NetWare 4.x.

Defining NDS

NetWare Directory Services (NDS) is a distributed global database of services and resources available on the network. Conceptually, this database exists when directory services are 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 on physical volumes associated with physical servers. Because the NDS database can become quite massive, and for reliability reasons, the NDS database is not stored at any central site (very small networks being the occasional exception). Portions of the NDS database are distributed on volume storage devices at strategic locations on the network. These subdivided elements of the NDS database are called partitions.

The Difference between NDS and the NetWare Bindery

As you learned earlier, 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 is therefore a distributed database. This is different from the approach used in pre-NetWare 4.0-based networks, where the resources on a server were centrally located in a flat database called the bindery. Because the bindery served as a centralized database, it could become a single point of failure.

The directory database in NDS is organized hierarchically. This hierarchical structure maps well into the organizational structure of most organizations. It can be used to represent logical relationships between network resources. For instance, a group of resources could fall under a single node that represents a department of an organization. Examining the differences between NDS and the NetWare 3.x bindery gives some insight into the improved manner in which network resources are managed in NetWare 4.0. Table 2.1 summarizes the differences between NDS and the NetWare bindery.

TABLE 2.1 NDS versus Bindery

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

The bindery was used in earlier versions of NetWare 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-centric, and was used to store information on resources available at a NetWare server and not the entire network. Consequently, 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. There was no concept of a network-wide user account. (There was an attempt to provide this capability using NNS, NetWare Name Service, but it was not very successful, and NNS was never popular.)

The NDS structure is hierarchical, which enables NDS to represent relationships between network resources more comprehensibly for the user and the network administrator. The logical representation of a resource in NDS is called an object. NDS can be used to store information about objects so that this information can be queried in much the same way the white and yellow pages of a telephone directory can be used. For instance, the user object information can be used to keep information such as phone numbers, fax numbers, electronic mail address, address, location, and so forth. User and group accounts in NDS are network-wide in scope, which eliminates the need for the network administrator to create user and group accounts on each server to which the user needs access.

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

NDS provides control of directory resources, such as servers and volumes, but not over the contents of volumes, such as files and directories. Access to files and directories is provided by the trustee rights mechanisms used in NetWare 3.x. See Chapter 10, "Implementing NetWare 4.x Security," for more on NetWare 4.x security.

Understanding the NetWare Directory Database

NDS is a global, distributed database that keeps information on network resources in a hierarchical manner. The distributed nature of NDS enables it to store information on many types of objects, such as users, printers, servers, and volumes of potential interest to the network user community (see fig. 2.1). The distributed information is actually stored on NetWare servers throughout the network in a manner transparent to the user. A directory synchronization mechanism is used so that directory changes on 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. The 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.

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

The hierarchical relationship in NDS is often described in terms of a directory tree, such as the one shown in figure 2.2.

Figure 2.1 The NDS database.

Figure 2.2 A hierarchical NDS tree for Network Widget, Inc.

The hierarchical relationship enables network resources to be organized in a manner that reflects how the network is used, instead of the physical topology and connectivity of the network. The directory organization can be made to more closely match the user's view of the network. For example, in figure 2.2, the engineers Tom, Mary, and Dei, of the organization Network Widget, Inc., have user accounts defined under the departmental unit (called Organizational Unit, in NDS terminology) Engineers. Figure 2.3 shows that the users are not in the same physical location. In figure 2.3, engineers Tom and Mary are in Dallas, while user Dei is in Los Angeles; but, because they all belong to the group Engineers, they have similar needs to access network resources. Under these circumstances, it makes sense to group them in an Organizational Unit called Engineers, regardless of their physical location.

Figure 2.3 A physical network for Network Widget, Inc.

The file server for the engineers of Network Widget, Inc., is currently defined in Los Angeles. Should a need arise to physically move the server to Dallas, the file server can be moved without changing the NDS view of the network. The file server EFS_1 still is under the Organizational Unit of Engineers in the NDS tree. In figure 2.2, you can see that volume EFS_1_SYS, which is physically attached to the server EFS_1, is in the Organizational Unit Engineers because it is primarily used by the engineers of the company. Another volume, called EFS_1_VOL1, also is physically attached to the server EFS_1, but its NDS representation is kept in the Organizational Unit Sales because it is primarily used by members of the sales team. One reason for the volume EFS_1_VOL1 to be kept in the Sales Organizational Unit could be that the group Sales does not as yet have its own file server. From this discussion you can see that network resources can be placed in the NDS tree according to their use and the user's view of the network, instead of the physical location of the resource.

NDS is based on the CCITT X.500 standard. CCITT is the Consultative Committee for International Telephone and Telegraphy. This is an international standard body. NDS is not in complete compliance with X.500, because it is based largely on the 1988 X.500 recommendations. The CCITT standards evolve continually and the latest updates of these standards are published every four years. The X.500 standard has further evolved into the 1992 X.500 specification. For strategic reasons, you can expect Novell's implementation of NDS to comply with the international consensus on X.500. Another area of expected change is the protocol mechanisms for keeping the NDS database updated when changes are made to it (directory synchronization). Because these have not been completely specified in the X.500 standards, Novell, like many other X.500 vendors (DEC, Retix, and so forth), 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 does provide an API to exchange data between other name services, which makes possible building name service gateways to other name services.

NDS complies closely with the X.500 recommendations for naming objects and organizing objects in directory trees. The details of the kind of objects that make up the directory are specific to NetWare-based networks. Other general classes of objects which are not Novell-specific could be added to the NDS directory by making use of NDS programming APIs, which makes possible integrating NDS with other vendors' X.500 directory implementations.

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

Defining NDS Components

NDS has a hierarchical structure and uses a specific terminology to describe its components. Some of the terms derive from CCITT's X.500 recommendations while others are specific to Novell. Before you can get 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. A tree is a computer science term that describes a way to represent data that begins at 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.4 illustrates the concept of a tree, along with a picture of the NDS tree.

Figure 2.4 The NDS tree components.

The tree has a single root (see fig. 2.4a). This is important to realize, because the NDS database also has a single root. If you have several NDS databases constructed separately from each other, they have separate roots. At the moment, you have no way of dynamically exchanging NDS information between NDS trees and their own separate roots. Tools for combining several separate NDS trees (each with its own root) into a single larger NDS tree are becoming available. One example of such a tool is DSMERGE, which allows two NDS trees to be merged. (See Chapter 5, "Merging NDS Trees," for more on merging NDS trees with DSMERGE.)

The root of a tree describes the first level of the tree, and is used to describe the entire tree.

A branch from the root of a tree leads to another node on the tree, and describes a complete subtree (see fig. 2.4b). A node on the tree that contains other nodes is called a container object. A branch of a tree, therefore, consists of a container object and all the objects underneath it.

Container Objects

A container in NDS is an object that contains other objects, such as other containers, resource objects, and service objects. Containers provide a practical way of organizing objects by department, geographic location, workgroup, common usage of network resources, or any other criteria that make the network easier to use.

Container objects provide a convenient way to organize other nodes into groups (see fig. 2.5), a key advantage of NDS--besides facilitating a logical organization of the NDS tree, container objects can be used as groups that can be assigned certain security rights, which then affect the security rights of all nodes in that container.

Figure 2.5 Container objects as groups.

Leaf Objects

A node 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, which does not have any branches or other 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.6). A leaf object can only exist inside a container object.

Figure 2.6 Leaf objects.

Object Class and Schema

A NetWare 4.x-based network can have many different types of network resources and services, and each of these resources and services is described by a special type of leaf object. File server and print server objects 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, along with their scope and rules of existence and operation, is called the schema. Because the NDS tree is a global distributed database, database terms are sometimes used to describe the NDS tree, and you should be familiar with them. The NDS schema, therefore, is a collection of object class definitions for objects such as file servers, computers, printers, print servers, and so forth (see fig. 2.7). 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 a potential for an object of that class to exist in the database; it does not imply an 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.7 NDS schema.

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

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. In a similar manner, a container in NDS con-tains other subcontainers and leaf objects (network resources and services). See figure 2.8. A directory in a file system can be used for organizing files. Containers in NDS are used to organize network resources.

Figure 2.8 Containers versus directories for a file system.

The container typically represents an organization, department within an organization, workgroup center, responsibility center, geographical location, shared information, and network usage. The container and its relationship with other objects in the tree must be planned carefully. It currently is difficult to make changes after the NDS tree is constructed, but tools for major restructuring of NDS are expected to become available.

Understanding Object Names

All nodes 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, which 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.9, the container ENGINEERS cannot have two volume objects with the names NW4CS_SYS and nw4Cs_sYs. It is not even possible to have the same name for two objects that have a different object class. Therefore, container ENGINEERS cannot have both a file server object named ZAPHOD and a User object named ZAPHOD. These two objects can, however, exist in different containers, as seen in figure 2.10.

Figure 2.9 Object names in a container.

Figure 2.10 The same object in different containers.

Even though object names are case insensitive, the case of the name at the time the object is created is preserved for display purposes. If you create an object named mY_worKstation, for example, it appears in the case used for the object name at the time the object was created. Leaf objects can be renamed, but not container objects.

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

An object name can be up to 64 characters long and can consist of alphanumeric characters, dashes, underscores, parentheses, and even spaces. If spaces are used, you have to enclose the object name in quotation marks (") for it 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.11 shows an interesting example of an NDS tree that has two objects with a blank name. The first container object under ESL and the User object underneath it have a blank object name. Even though blank names might be permitted, it is a good idea to avoid them, because the utilities that query NDS do not handle them in a consistent manner.

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

Figure 2.11 Example of a blank name object.

TIP: NDS might even enable you to use characters that the documentation designates as illegal for creating names of objects. However, they are not guaranteed to work in a consistent manner in the NDS-based commands and utilities. For this reason, it is best to avoid them.

Defining Container Object Types

NDS supports the following container objects:

Country object
Organization object
Organizational Unit object

Figure 2.12 shows the icons used to represent these different container objects. These icons are displayed when using 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.12 Symbolic representations of container objects.

The [Root] Object

The most frequently used container objects are the Organization object and the Organizational Unit object. The Organization container object can occur under the [Root] object. The [Root] object, although not listed as a container object in Novell documentation, is a special type of container that holds all other container objects. There can be 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 (you can learn more about rights and security in Chapter 10).

It is possible to install NetWare 4.x on separate LANs, each with its own [Root] object. This could easily happen if the network was built in different segments, with final connectivity of the separate network segments achieved later. Under these circumstances, several [Root] objects could exist, each describing a different tree. Now, if you connect the network segments together, the networks represented by the different [Root] objects cannot communicate (see fig. 2.13) using normal NDS mechanisms. Accessing two servers FS1 and FS2 is possible, however, each with its own unique tree, TREE1 and TREE2; you could do so as follows:

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

2. MAP N FS2/SYS:

Because FS2 has a different tree, NetWare automatically switches to bindery emulation mode and attempts to connect you in that fashion. (See Chapter 9, "Setting Up NetSync for Bindery Emulation," for more on bindery emulation.)

TIP: When installing a NetWare 4.x server that is not the first server installed, you should have physical connectivity from this NetWare 4.x server to the rest of the network, so that the server can be installed as part of the NDS tree.

TIP: For extremely secure environments, having separate [Root] objects might be desirable, to ensure that users in a directory tree under one [Root] cannot access or communicate with users under another [Root].

NOTE: Alias is the only leaf object that can be directly under [Root].

Figure 2.13 Multiple [Root] objects and the sharing of data.

NOTE: The only container objects that can be directly under [Root] are the Country and Organization objects.

The Country Container Object

The Country object is part of the X.500 recommendations. Country object names are limited to two characters. They can be any two characters, but using the CCITT's two-letter designations for countries is recommended. Figure 2.14 shows an NDS tree with the two-letter designations for several countries. 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.

The Country object can contain only Organization and Alias objects.

NOTE: Alias is the only leaf object that both the [Root] and country containers can contain.

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

NOTE: Country object names can be two characters only.

Figure 2.14 Country objects in an NDS tree.

The Organization Object

The Organization object represents the name of the organization. Figure 2.15 shows an NDS tree that has the 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.15, the Organization objects CISCO, HP, IBL, IBM, MS, and NOVELL are placed directly underneath the Country object US. Also, organizations 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 where the NDS schema enables an Organization object to be placed.

Figure 2.15 Organization objects.

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

The Organizational Unit Object

Because an organization is usually subdivided into specialized functions, such as by department, network usage, common jobs, location, workgroups, responsibility centers, and so forth, the Organizational Unit object can be used 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.16 shows examples of an Organizational Unit object and the different locations in the NDS tree where 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, which enables the same object names to be used in different containers.

Figure 2.16 Organizational Unit objects.

In figure 2.16, organization LTREE has an Organizational Unit CORP underneath it. And CORP has two other Organizational Units BROCHURES and MARKETING directly underneath it. This is typical of many organizations that can be expected to have subdivisions within a department of an organization.

The Organizational Unit object can contain any leaf object and Organizational Unit 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, which means that the Country object US is represented as follows:

C=US

The other container objects, Organization and Organizational Unit, have the attribute types of O and OU, respectively. Therefore the organization IBM is represented by

O=IBM

and an Organizational Unit SALES would be represented by

OU=SALES

A leaf object that represents a resource or a service has the attribute type designator CN (Common Name). Therefore, the file server named NW4CS, would be represented as

CN=NW4CS

The different attribute types are summarized in table 2.2. All attribute types except the one for [Root] are part of the X.500 recommendations.

TABLE 2.2 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. The 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 only the following leaf objects:

AFP Server
Alias
Bindery
Bindery Queue
Computer
Directory Map
Distribution List
External Entity
Group
Message Routing Group
Messaging Server
NetWare Server
Organizational Role
Print Queue
Print Server
Printer
Profile
Unknown
User
Volume

AFP Server Object

The AFP server leaf object is currently used for informational purposes only. It represents an AppleTalk Filing Protocol (AFP) server that is on your network. This could be a Macintosh computer running the AFP protocols, or even a VAX server emulating AFP protocols. The AFP server can be used to store information, network address information, or information on users and operators. One of the benefits of NDS is that it can be queried for information in a manner similar to databases. So, if for each AppleTalk server on your network you have an AFP server object (see fig. 2.17), you can make general queries such as: "Show me all AppleTalk servers in container O=ESL."

Alias Object

The NDS system is hierarchical and the object naming syntax (discussed later in this chapter) consists of enumerating the NDS objects, starting 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 a little complicated, especially for end users who do not have the training to understand the NDS naming convention (see fig. 2.18).

Figure 2.17 The AFP server object.

Figure 2.18 Accessing another object via alias.

NDS permits the definition of an object called the Alias object. An Alias object can point to a leaf or a container object, similar to the concept of symbolic links used in operating systems such as Unix; except that Unix's symbolic links apply to file systems, whereas Alias objects are links to leaf objects in the NDS tree. Figure 2.19 shows the information you need to supply at the time you create an Alias object. In this dialog box, the name MyAliasName is going to be the new name of the Alias object that is going to be created under [Root] (shown highlighted in figure 2.19). The value for the aliased object can be entered directly or by selecting the browse icon next to this field, which shows the Select Object dialog box. Because the Alias object is being created under [Root], the only possible objects that can be aliased are the Organization and Country objects. An attempt to alias another object produces an error message.

Figure 2.19 Alias object creation.

Computer Object

A Computer object is used to represent a nonserver computer, such as a workstation, minicomputer, or mainframe, or even 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 the network address, computer serial number, computer operator, and so forth (see fig. 2.20).

Figure 2.20 Computer object.

Bindery Object

The Bindery object is created when placing a NetWare 3.x server/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 allow a NetWare 4.x server to be accessed by NetWare 3.x client software that expects to see a bindery-based server.

TIP: For NetWare 4.x servers to be accessed by NetWare 3.x client software, the SET BINDERY CONTEXT parameter, which can be used to list up to 16 containers, needs to be set at the NetWare server. Certain utilities such as SBACKUP.NLM and AUDITCON.EXE use bindery emulation. These utilities will not work correctly if BINDERY CONTEXT is not set. This parameter is set by default during the NetWare server installation. Additionally, if using Ethernet, the server must also load the driver with a frame type of ETHERNET_802.3 to support NetWare 3.x client software that makes use of this frame type. By default, NetWare 4.x uses the ETHERNET_802.2 frame type. The Ethernet 802.3 frame type, as defined by Novell (which is different from the rest of the industry's definition) does not include the LLC (Logical Link Control) layer specified by the IEEE 802.2 standard. This is the reason Novell has begun calling the ETHERNET_802.3 frame the ETHERNET_802.3 raw format. The frame type ETHERNET_802.2 includes the LLC layer, which is a sublayer of the data link layer (OSI Model layer two). Use of the LLC layer in ETHERNET_802.2 identifies the upper-layer protocol that needs to handle the data portion (also called the payload) of the frame. In the case of NetWare 4.x, the default upper-layer protocol is IPX, but TCP/IP can also be used. The LLC layer enables protocol multiplexing/demultiplexing. This means that support exists for delivering data to multiple protocol stacks and receiving data from multiple protocol stacks. The LLC layer also permits third party hardware-based routers to function properly. Without the LLC layer, hardware-based routers had to devise special techniques to discern whether an ETHERNET_802.3 raw frame carried an IPX packet.

Bindery Queue Object

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

Directory Map

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 in the MAP command, which enables a workstation drive letter to refer to a network directory on a server. Using the Directory Map objects can simplify the MAP command used to point to Volume objects in other containers.

A very important use of the MAP command is in LOGIN scripts. LOGIN scripts are a sequence of instructions that get executed when a user logs in. They are used primarily to set up a user's network environment. Consider the situation in which a LOGIN script contains the MAP command to map the drive letter G: to a directory in the volume object named 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 would be invalid and all references to the former location of the Volume object and directory would have to change. If the Directory Map object were used to perform the mapping in the LOGIN script, only the directory map reference to the new volume/directory location would have to change, and the LOGIN scripts would not change. Figure 2.21 shows a Directory Map object in an NDS tree with some of its properties.

Figure 2.21 A Directory Map object.

Distribution List Object

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, which 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. Members of distribution lists, however, do not have security equivalence to the distribution list.

Figure 2.22 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 mailboxes. The Mailbox Location is a property of Organization, Organizational Role, Organizational Unit, Distribution List, Group, and User objects.

Figure 2.22 Distribution List object.

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 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 that 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.23 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.

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.

Figure 2.23 External Entity object.

Group Object

A Group object is used to refer to a collection of users in the NDS tree. The Group object can only refer to a collection of User objects. The Group object is used as a convenience for assigning a number of users the same security rights. Figure 2.24 illustrates the concept of groups. In this figure, 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.

The Group object is similar in concept to the groups in NetWare 3.x, except that Group is an NDS object rather than a bindery object. Also, NDS offers no equivalent to the NetWare 3.x group EVERYONE that, by default, contains all the users created on the NetWare 3.x server. To achieve the effect of a group such as EVERYONE, container objects can be used. All objects created in a container can be treated as a group by using the container name. A Group object has a group membership property that is a list of User objects defined anywhere in the NDS tree. Members of a Group object can only be User objects.

Figure 2.24 The concept of groups.

Container objects, on the other hand, can be used as groups; but members of a container object can be any leaf object or other container objects. Container groups can be used to provide a hierarchical relationship between groups, which is not possible with Group objects or 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. When using containers that have a natural hierarchical relationship between them, subset relationships between groups is possible. Figure 2.25 shows the Group object membership property.

Figure 2.25 Group object membership property.

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, 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.

The Message Routing Group 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 message routing group. The Postmaster General can modify the Message Routing Group object and its attributes because he or she has Supervisor object rights to the Message Routing Group.

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

Supervisor access to the MHS (Message Handling System) Messaging Server object.
Supervisor access to the Mailbox Location, Mailbox ID, and EMail Address properties of users of the MHS Messaging Server.
Read access to the Message Routing Group that the MHS Messaging Server is in.

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

Messaging Server Object

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

NOTE: For those familar 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 that implements the MHS Messaging Server. (See Chapter 8, "Setting Up Mail Services," for more on message handling in NetWare 4.x.)

NetWare Server Object

The NetWare Server object represents the physical NetWare server on a network and provides NetWare Core Protocol (NCP) 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 of this 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 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 of this is the Volume object that 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.26 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 8-hexadecimal-digit internal number of the NetWare server; 000000000001 refers to the 12-hexadecimal-digit node number; and 0451 refers to the 4-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 Media Access Control (MAC) address. The version number of the server is reported as Novell NetWare 4.0[DS]. The DS stands for Directory Services.

Figure 2.26 The NetWare Server object.

Organizational Role Object

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

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 changes. For example, the person assigned to perform backup tasks could change depending on the workload of individuals in an organization. Rather than change the rights of the user for performing a certain task, these rights could be assigned just once to the Organizational Role object. The occupant of the Organizational Role object could be changed, and this would give the assigned occupant sufficient rights to perform the organizational role's task. Figure 2.27 shows the Organizational Role object and the individual occupying that role at the moment. Only User objects can be assigned to the property Occupant. Figure 2.28 indicates that the occupant of the organizational role is the User object CN=Admin1.OU=CORP.O=ESL.

Figure 2.27 The relationship between a User object and an Organizational Role object.

Figure 2.28 The Organiza-tional Role object.

Print Queue Object

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

Figure 2.29 shows the Print Queue object in the NDS tree. Notice 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.

Figure 2.29 The Print Queue object.

Print Server Object

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

Figure 2.30 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. This is the name used by the print server to advertise its services using SAP (Service Advertising Protocol). The status of the print server indicates that it is down.

Figure 2.30 The Print Server object.

Printer Object

The Printer object is used to describe the physical network printer device. The Print Queue object has a reference to the Volume object on which the actual print jobs are stored. The print queue in turn is assigned to one of the Printer objects. Print jobs sent to the Printer object are sent to the associated print queue. As in NetWare 3.x, print jobs also can be sent to the print queue.

TIP: Further restrictions when sending jobs to the printer include the following:

You must be a user of ALL queues assigned to that Printer.

You need Browse NDS rights to the Printer object and ALL assigned queue objects.

You need to designate a default queue for the Printer.

Figure 2.31 shows a Printer object in the NDS tree and the properties of the Print object that contain references to other printer-related objects. In figure 2.31, 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 are sent to the queue represented by the object: CN=QUEUE_0.OU=CORP.O=SCS. This printer services the print server CN=PS_0.OU=CORP.O=SCS.

Figure 2.31 The Printer object and the Assignment properties.

Profile Object

This is an object that represents common actions performed during login processing. It represents a login script shared by a number of users. The User objects that share the login script can be in different containers.

The Profile object is listed as a property of a User object. It is executed when an individual uses the User object to log in to the network. Other types of login scripts exist, such as the system login script and user login scripts. These are properties of the container object and the User object, however, 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.32 shows a Profile object in an NDS tree and the login script contained in the Profile object. (See Chapter 11, "Setting Up Login Scripts," for more on login scripts.)

Unknown Object

The Unknown object represents an NDS object whose object class cannot be determined because its NDS information has been corrupted. Figure 2.33 shows an object of unknown type under the container, O=ESL. The Unknown object is the first one listed under O=ESL, and has the question mark icon next to it. If you bring a server down and then up again, specifying a different name, new volumes will appear, along with the old volumes. The old volumes become Unknown objects. Also, if the object that an Alias object points to is removed, the Alias object appears as an Unknown object.

Figure 2.32 The Profile object.

Figure 2.33 An Unknown object.

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

User Object

A User object represents the user account of the individual that logs 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. The User object must exist for every user who needs to log in to the network with LOGIN. The User object is defined in the NDS tree, which makes it different from NetWare 3.x, where 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 are a home directory on a Volume object that the user has rights to, LOGIN restrictions, enabling/disabling intruder lock-out mechanisms, and so forth.

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

Figure 2.34 The User object.

A User object with the special name USER_TEMPLATE is used as a template for creating default property values for User objects within that container. You can have only one USER_TEMPLATE object within a container (Organization, Organizational Unit containers) that enables the creation of such an object.

Volume Object

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

Though the Volume object appears to be an object that is 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 Host Server that associates the volume with its host NetWare server (see fig. 2.35).

Figure 2.35 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, followed by the name of the physical volume, such as SYS or VOL. The physical name of a volume is the name given when the volume was first initialized as part of the installation process using the INSTALL NLM (NetWare Loadable Module).

NDS volume object name = Object Name of Server_Physical Volume Name

Therefore, if the NetWare Server object name is NW4CS, the first physical volume on it, which 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. If you bring a server down and then up again specifying a different name, new volumes will appear, as well as the old volumes. The old volumes become known as Unknown objects.

The Volume object is both an NDS object and a file system object. It has characteristics of both a file system object and an NDS object. As an NDS object, the volume is managed by NDS but its components consist of directories and files.

Table 2.3 summarizes the previous discussion and gives a brief description of each type of leaf object.

TABLE 2.3 Leaf Object Descriptions

Leaf Object Class	Meaning
AFP Server	An AppleTalk File Protocol server. Used for informational purposes.
Alias	A link to another object. This is a substitute name for an object that points to another object in the NDS tree.
Bindery	The object created when placing a NetWare 3.x server/service in the NDS tree as part of the upgrade process. NDS cannot manage internals of this object. 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.
Computer	An object that represents a computer: workstation, minicomputer, mainframe, and so forth. 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.
Distribution List	Represents a list of mailboxes or other distribution lists. This simplifies sending the same e-mail to a group of users. Distribution lists can contain other distribution lists.
External Entity	Represents a non-native NDS object/service that is imported into NDS or registered in NDS. 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.
Group	An object that has members that 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.
Message Routing Group	Represents a group of messaging servers that can transfer messages directly amongst themselves.
Messaging Server	A message transfer agent for e-mail applications.
NetWare Server	Represents a NetWare server on a network. This is the object that provides NetWare Core Protocol (NCP) 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 a 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 sharing of common actions that are performed during the LOGIN processing, regardless of whether the users are in the same container.
Unknown	Represents an NDS object whose object class cannot be determined because its NDS information has been corrupted. Running DSREPAIR can fix this problem.
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.

Object Properties

An object has attributes called properties that represent the types of information that can be stored 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 can be in a record.

Figure 2.36 shows the file server object which, in this figure, shows properties such as Name, Network Address, and Location. The actual value assigned for each of these properties is called the property value. A property value is an instance of the property type. Some of the properties of an object are mandatory and critical for the object to be used properly. Other properties are descriptive and used for informational and documentation purposes that enable NDS to be used as a database of management information. The critical values are filled out by the network administrator at the time of creating the object. The values used for information and documentation can be filled out at a later time by the network supervisor, who has write access to these properties. An example of properties for the User object which are for informational purposes is the list of telephone and fax numbers for that user, the postal address, and the job title of the user. The name property for a User object is mandatory.

Figure 2.36 An NDS object and properties.

NOTE: 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 can be queried by using tools such as NLIST.

Properties can be single-valued or multivalued. 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.

NDS Tree Case Study

Consider the organization MICROCON that makes advanced semiconductor devices. MICROCON has its manufacturing plants and research labs 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 users at that facility. Kirk is the overall network administrator. The SALES department is a department within the MARKETING group. Currently, the sales persons are Janice, Jane, and John. Ron works in the Marketing department, which at the moment is understaffed.

A diagram of the physical network for MICROCON is shown in figure 2.37. Figure 2.38 shows the NDS tree structure for this organization. Notice that 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 salespersons' 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. 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. London and New York both have two file servers and three network printers, while other locations have a single file server and two network printers. As the company grows, additional servers probably will need to 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 not provided here. For instance, you might have to invent names for users at each of the locations and decide which of the users are going to be network administrators.

Figure 2.37 The MICROCON physical network.

Figure 2.38 The MICROCON NDS tree.

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

1. Decide on the depth of the tree. How many container levels do you need?

2. List all container objects that you need. Justify why you need each container.

3. Give appropriate names for container objects. Should they correspond to departments or geographical locations?

4. Do you need one Organizational Unit, or more than one?

Understanding NDS Context

NDS context is a term used to describe the position of an object in the NDS tree. The position is described in terms of the container that contains the object.

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) before you can find it. (Commands are available, such as the NLIST command, to help you find the object's position in the NDS tree--if you know its name. These commands are discussed in Chapter 13, "Managing NDS.")

The context also can 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 for listing the container objects is to start with the immediate container and work your way up to the root.

NOTE: The context can never be set to a leaf object (because leaf objects cannot contain other objects).

A special type of context, called the current context, is 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 using the network.

When the network client software loads, it connects to the NDS tree. If DOS is used as the workstation software, it can maintain only one current context for each DOS session. The workstation's current context can only be set to container objects, not leaf objects, because a context is defined to be 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 current directory in a file system. Just as the current directory cannot be set to a filename, the current context cannot be set to a leaf object.

Objects that are in the current context of a workstation can be referred to by their leaf object names.

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, because the user does not have to type the full NDS name of the object. 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.39, must be referenced by their NDS path name.

TIP: Group the resources a user accesses frequently in the user's context to simplify access to these objects.

Figure 2.39 Referencing objects in another context.

Naming NDS Paths

In the previous section you observed that objects not in the current context of a workstation must be defined by their NDS path name. You have three ways to specify the NDS path names:

Complete name
Typeless name
Partial name

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, starting 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. 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 the object can be referenced by enumerating its path all the way to the root. The path is enumerated by 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 special meaning. The [] indicate that the contents between them are optional. The {} indicate that there can be 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].

The attribute_type_abbreviation is 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 starting with the most immediate container, and continuing all the way to the [Root] container are enumerated. Because there can be 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 are

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

.CN=leaf_object.O=org_unit

The following is an example of a typeless complete name:

The C=country has been left out in the preceding syntax example of the complete name, because the Country object is optional. The most general case of the complete name would list the Organizational Units, a single organization, and a country name as shown here:

.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.40, the complete names of the objects FS1, PS1, PRINT_1, PRINT_2, and PS2 are as follows:

.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.40 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, 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 a complete path name that lists all the directories starting from the root. The partial name is also called the Relative Distingished Name (RDN).

Resolving a Partial Name

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 follows:

Complete Name = .Partial Name.Current Context

An example might help clarify this rule. If the current context is OU=CORP.O=ESL, the partial name for object HP_PR1 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 is OU=CORP.O=ESL Partial Name is      CN=HP_PR1 Complete Name is: . concatenated with CN=HP_PR1 concatenated with  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.41, 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. That is, the partial name for FSP_1 is

CN=FSP_1.OU=CORP

Similarly, the partial name of ENG_FS_VOL, if current context is O=ESL, is

CN=ENG_FS_VOL.OU=ENG

and the partial name of Admin, if current context is O=ESL, is

CN=Admin

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

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 container above. In figure 2.42, 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.42 The partial name for an object when its current context is in a different branch of the NDS tree.

The trailing period at the end refers to the parent container of the current context, in this case, 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, not O=SCS), a trailing period must be added at the end.

If the current context in figure 2.42 were OU=OPERATIONS.OU=ENG.O=SCS, the same object CN=DEI_FS could be referred to by the partial name of

CN=DEI_FS.OU=CORP..

Two trailing periods mean 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.

Partial Name Example Exercise

The partial names for objects HP_PR1, FS1, VOL1, FS2, and BOB in figure 2.43 are listed in table 2.4 for different current context settings.

Figure 2.43 The NDS tree for partial name examples.

TABLE 2.4 Partial Name Examples

NDS Object	Current Context	Partial 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

Learning NDS Naming Rules

This section summarizes the naming rules discussed in many of the examples in this chapter. Next, two important concepts that deal with NDS are discussed: path and typeless naming.

NDS Path

The NDS path name consists of a list of object names written left to right, beginning with the referenced object and leading up to the [Root] object or the current context. If the object name is preceded by a period, it refers to the complete name and must lead up to the [Root]. If the NDS path name does not have a leading period, it refers to a partial name.

Typeless Name

The complete name of the object, in addition to beginning with a period, uses the attribute type names CN, OU, O, and C to designate the type of the object as a Common Name, Organizational Unit, Organization, and Country object, respectively.

Typeless names are NDS names that do not have the attribute type designators of CN, OU, O, or C. The following are examples of typeless names:

Mary.CORP.IBM .Lisa.CORP.ESL OPS.ICS.US .Linda.SALES.LONDON.UK

When NDS encounters a typeless name, it resolves it to a complete name and supplies the appropriate attribute types.

The use of typeless names involves less typing by the network administrator and can simplify the use of NDS names.

NOTE: Prior to NetWare 4.1, Novell did not recommend the use of the Country object because the NetWare 4 libraries and clients assumed that the top-level container was an Organization container. In the NetWare 4.02 release, it was possible to use Country objects in typeless names, if the current context included a Country object and had the same number of objects as the name being resolved. All of these complex rules of resolving typeless names have been removed in NetWare 4.1 and up.

In current releases of NetWare 4, NDS resolves the typeless name correctly regardless of whether it includes a Country object.

If your organization wants to interoperate with the AT&T NetWare Connect Services (ANCS) and other X.500 directories that use the North American Directory Forum (NADF), you should design your directory with the Country object at the top. You should also follow the NADF naming standards for X.500 environments.

Considering NDS Partitions

An NDS partition is a subset of the entire NDS database. The NDS global database must physically reside on one or more storage volumes. Consider the available options:

Should the entire NDS database be centralized?
Should you take subsets of the NDS database and distribute them? If the data- base is distributed, what factors should determine the method of distribution of the database?

If the database is centralized, then a failure in the network at the central location would make the NDS database unavailable to the entire network. For small LANs, the issue of centralization is not of as much concern. But for large networks that are separated by wide area network links, centralization can become a reliability problem.

It is best, then, to distribute the database in such a manner that a single failure does not disable the entire NDS service. The logical division (subset) of an NDS database is called a partition. The partition contains the resources (leaf objects) and the organizational structure of a portion of the NDS tree (container objects). The partition does not contain any information on the file system structure of a network volume.

When Novell introduced NetWare 4.0, it recommended that a partition should not contain more than 500 objects. Later releases have increased this limit to 100,000 objects per partition.

Partitions can help NDS performance by doing the following:

Dividing the NDS database so that each NDS database serves local users.
Reducing the need for NDS searches and look-ups to be performed over the slower wide area links.

Figure 2.44 shows an NDS database that is split into two partitions, with each partition residing on a LAN segment separated by a slow wide area link of 56 KBps. In this case, most NDS look-ups and searches are done against the local NDS partition, without requiring searches over the slow wide area link.

But a question concerning figure 2.44 is, what if the storage volume on which the NDS partition resides crashes? If the storage volume does crash, the portion of the NDS implemented by the NDS partition becomes unavailable. Users cannot access the resources represented by the failed NDS partition. To solve this problem, a technique called replication can be used.

Replication consists of keeping a copy of an NDS partition at another location. It is a copy of an NDS partition that is kept at a strategic location on another NetWare 4.x server. Figure 2.45 addresses the question, what if Location A kept a copy of the NDS partition for Location B on its NetWare 4.x server, and Location B kept a copy of the NDS partition for Location A on its NetWare 4.x server? If the remote server were temporarily unavailable or if the wide area link were down, the NDS queries for objects at the remote location could be serviced by the replica. Another advantage is that under normal conditions, NDS queries for objects at remote locations can be satisfied by the local replica. If the NDS partition at the remote location were to change as a result of new objects being added or old objects being deleted, for example, the NDS partitions can synchronize themselves by sending only the new information, which is a much more efficient way of doing NDS look-ups and maintaining consistency of the NDS database.

Figure 2.44 NDS partitions across a wide area link.

You can have an unlimited number of replicas for each partition. The replicas for the same partition form a replica ring. A replica ring is a set of servers that hold a replica of a given partition. In the example in figure 2.44, the replica ring of the [Root] partition consists of servers FS1 and FS2.

TIP: Limit replicas to no more than eight to ten per partition.

Figure 2.45 NDS replicas across a wide area link. Replicas provide the following advantages:

Increase NDS fault tolerance and minimize risk of any single point of failure.
Provide fast access to NDS services by avoiding slow wide area links.
Provide LOGIN access to network even when the storage volume for the partition is down.

Because a replica is a copy of the NDS partition, NDS makes the following distinctions for replicas:

Master replica
Read-only replica
Read/Write replica
Subordinate references

The master replica is the original partition created for representing a subset of the NDS database. The master replica contains the authority for the objects defined on it. All other replicas must defer to information contained in the master replica; that is, the master replica, by definition, contains the most recent information, and only one master replica can exist per partition. This replica is used by the NDS synchronization mechanism to update all other replicas. The master replica is used to create all other replicas. You need to access the server that holds the master replica if you want to redefine a partition boundary by performing operations like splitting or merging. Partition operations are done by using the Partition Manager option in the NetWare Administrator tool.

A read-only replica contains a copy of the master replica, but once created it cannot be modified. The read-only replica is used to represent information that you can search for and view but not change. It is similar to the concept of yellow pages on other directory systems. The read-only replica is used as a database that can be queried, but it cannot be used for logging onto the network, because the login process modifies the NDS tree. For instance, the network address property of the logged in user object is altered to contain the station address of the workstation that the user is using.

A read/write replica can be used to update the NDS database and provide information to NDS queries. NDS objects in the read/write replica can be modified, deleted, or created; these changes are propagated to all other replicas of the partition. This replica can be used to answer NDS queries and enable users to log in to the network. To improve reliability, you can have multiple read/write replicas of a partition. You cannot use a read/write replica to redefine a partition boundary; you need a master replica to perform this task. If the master replica is corrupted or the server that holds the master replica is down, you can make a read/write replica a master replica. When the original master replica comes back online, it is deleted automatically, thus ensuring that there can be only one master replica of a partition. Read/write replicas and master replicas can be used for user authentication.

Subordinate reference is another partition type NDS uses for its internal operations. NDS maintains subordinate references to enable "tree walking" operations. Tree walking is needed to access information on NDS objects that might be stored on another server. Tree walking refers to the process of accessing NDS objects stored in a replica on another server. Subordinate references do not contain NDS object data but point to the replica that does. A subordinate reference partition is automatically created on a server that holds the replica of a partition but not the child's partition. The subordinate reference points to the child's partition and acts as a pointer to the location (server) on which the child's partition exists. If you add a replica of the child partition to the server, you do not need to have a subordinate reference (pointer) to the child partition, because its replica exists on the server. In this case, the subordinate reference is automatically deleted from the server. Subordinate references are not managed or maintained by the network administrator--they are maintained by NDS itself. You cannot use subordinate references for user authentication, viewing, searching, or managing NDS objects.

NOTE: Subordinate reference partition types exist in the earliest releases of NetWare 4--they are not a new type of partition. Their uses have been documented more clearly starting with the release of NetWare 4.

NDS partitions can be managed by one of the following:

PARTMGR.EXE, a DOS-based menu utility
The Partition Manager option in the NetWare Administrator tool

You can use the Partition Manager to perform the following tasks on NDS partitions:

View existing NDS partitions
Split a partition
Merge partitions

Splitting a partition involves creating new partitions, and merging a partition results in deleting old partitions.

Figure 2.46 shows an NDS partition displayed using the Partition Manager GUI tool, and figure 2.47 shows the same partition using the PartMgr tool.

Figure 2.46 The Partition Manager used for viewing partitions.

Figure 2.47 The PartMgr used for viewing partitions.

Cost of Synchronizing Replicas

Many NetWare 4 administration activities involve making changes to NDS objects. Changes made to NDS objects in a replica are propagated to all replicas in the replica ring. As the number of servers in a replica ring increases, the amount of time required for synchronization increases. The time cost of synchronization is further compounded when the servers in the replica ring are separated by low-speed WAN links. The amount of time and network traffic needed for synchronization are the limiting factors that control the number of replicas you can have. Novell recommends three or more replicas in a ring--the actual number depends on the cost of synchronization for the network.

Default Partitions and Replicas

When a NetWare 4 server is installed in a container, whether a replica is created depends on how many servers already exist in the partition. The following rules summarize the creation of replicas:

First server in directory. The first partition is created on the first server that is installed. The master replica is stored on the server on the SYS: volume. If this is the first server on the network, a new NDS tree is created, and the server contains the master replica of the [Root] partition.
If a new server is installed in an existing NDS container, the server object becomes part of the existing partition. No new partitions are created.
The second and third new servers receive a read/write replica of the partition; the fourth and subsequent servers do not receive any replicas.

When you merge NDS trees, servers in the source tree that contain replicas of the [Root] partition receive a read/write replica of the new [Root] of the target NDS tree. These servers also receive the subordinate reference to the [Root] partition's child partition. The servers in the target tree that contain the replica of the [Root] partition receive subordinate references for the top-level partition of the source NDS tree.

When you upgrade a NetWare 3.x server to a NetWare 4 server, the upgraded server receives a read/write replica of all partitions that contain the server's bindery contexts.

Guidelines for Managing Partitions and Replicas

The following are some guidelines for managing partitions and replicas:

The [Root] partition is the most important of all the partitions. Consequently, you must create replicas of the [Root] partition to increase its reliability and availability. If the [Root] partition is lost, the NDS tree becomes inaccessible. You should not, however, create too many replicas of the [Root] and other high-level partitions, because these partitions have multiple child partitions. Creating a replica of a [Root] partition on a server implies that the server also will receive subordinate references of all the child partitions, which can increase the cost of synchronization.
Partition operations such as merging, creating, and deleting partitions affect subordinate references. You might, therefore, want to take into account the following:

a. Do not create subordinate references linked across unreliable WAN links. If you want to make a partition change and the subordinate reference is not available, you cannot complete the partition operation.

b. Reduce the number of subordinate references by observing the following:

1. Create fewer partitions at the top of the tree, with more partitions at the lower level, to minimize the number of subordinate references to the child partitions.

2. Do not create unnecessary partitions. In general, create partitions that follow workgroup boundaries because workgroup boundaries generally determine how network resources are used and located in the NDS tree.

3. Minimize the number of replicas of the [Root] and other parent partitions. This will create fewer subordinate references.
To meet fault tolerance needs, plan for three or more strategically placed replicas of each partition.
You might want to create replicas in strategically located servers to reduce login and access times for users.
Create partitions along workgroup boundaries. Place replicas of a partition physically close to the workgroup that needs the network resources in the partition.
If the network clients require bindery services, ensure that a local server contains the master or a read/write replica that contains the container specified in the bindery context. The bindery context is set using the SET BINDERY CONTEXT statement (usually kept in the AUTOEXEC.NCF file).

Designing an NDS Tree

This section covers the issues involved in designing an effective NDS tree. Although NetWare 4 does provide tools to change the structure of an NDS tree, designing the tree correctly in the first place saves you the time and trouble. You then can easily make incremental changes to the NDS tree to adapt it to the changing needs of your organization.

A properly designed NDS tree has the following benefits:

Provides fault tolerance for the network
Decreases unnecessary traffic
Simplifies network administration and maintenance
Enables users to access needed resources easily
Minimizes the impact on users and reduces the need for training

The design for the NDS tree depends on your organization's needs. You also must take into account the fact that an organization's needs can change over a period of time. The NDS design should, therefore, be flexible and should easily accommodate changes.

Novell recommends that NDS design be accomplished in two phases:

1. Structural design

2. Detailed design

The structural design phase determines the overall NDS tree structure without going into too much detail about the NDS objects that populate the NDS tree.

The detailed design phase focuses on how the NDS tree is accessed by users, how the tree is stored on servers, and how a common network time for directory operations is implemented. The remainder of this chapter discusses the structural design of the NDS tree.

Creating a Structural Design for the NDS Tree

The method for creating a structural design is described in figure 2.48. The three broad elements of the structural design method are as follows:

1. Determine the structural model.

2. Establish naming standards.

3. Select the implementation method.

Figure 2.48 Flowchart describing the structural design method.

Determine the Structural Model

Determining the structural model involves identifying the workgroup needs, determining the network topology, and organizing the NDS objects. Identifying the Workgroup Needs As part of identifying the workgroup needs, consider the following:

How network resources are accessed in a common fashion by a group of individuals.
How the users of an organization perceive themselves as belonging to a workgroup or a larger administrative domain within the organization.
How users perceive the network resources that they access. Do they perceive the network resources that they access as belonging to their workgroup, for example, or do they share it with other workgroups?

The purpose of identifying the proper level of workgroup structure is to assist users in accessing the resources they need and sharing information with others in their workgroup in a collaborative manner. The network should be easy to use for the users and easy to administer and maintain for the network administrators.

You can base your workgroups on the following:

Administrative division
Workgroups across divisions
Geographical locations

In the "Administrative Division" method, the workgroups are identified by the company's organization chart. This approach emphasizes the administrative and management structure of the organization. This method is particularly appropriate if the work performed by the users is strictly along the organization charts for the organization. Figure 2.49 illustrates this approach. The divisions Engineering, Accounting, Marketing, Sales, and Corporate form a natural workgroup.

Figure 2.49 Administrative division workgroup.

In the "Workgroups across Division" method, the workgroups are identified by identifying the common projects and functions performed in each division of the company. This approach emphasizes the project-oriented nature within an organization. This method is particularly appropriate if the work performed by the users is strictly along project lines and users from more than one division work on common projects, or perform similar tasks and access the same resources. Figure 2.50 illustrates this approach, in which the workgroups are identified by project and function.

Figure 2.50 Workgroups across division.

In the "Geographical" method, the workgroups are identified by their physical location, a particularly appropriate method if the work performed by the users at each location is distinct, and users in a particular location need to perform similar tasks. Figure 2.51 illustrates this approach in which the workgroups are identified by geographical location.

Figure 2.51 Workgroups based on geographical location.

In some organizations, a combination of the previously mentioned methods might be necessary. Workgroups using a combination of methods are called hybrid, or mixed environment, workgroups. Figure 2.52 illustrates the hybrid approach for workgroups.

Figure 2.52 Hybrid or mixed environment workgroups.

After you identify the workgroups, you can start determining the network topology. You need to understand the network topology before you can understand how the resources are going to be accessed. You need to determine how many WAN links are used, for example, as well as their cost and bandwidths. If the users and the resources to which they need access are far apart and separated by expensive and slow links, the network might be slow for the user and expensive to use.

After you determine the network topology, determine the number of container levels you need for your NDS tree. No practical limit applies to the number of container levels you can have in an NDS tree. Technically, you cannot enter more than 256 characters for the NDS object path name. You should decide on the number of levels that suits your needs.

NOTE: Novell documentation states that the Directory tree works well with approximately five to eight levels. Realistically speaking, two to five levels are adequate for most organizations.

You also should provide bindery services for those clients who need them.

Establish Naming Conventions

Before you create the Directory tree, have a naming standard that describes how objects should be named. Your naming standards should preferably be in written document. The NDS naming document standard should take into account the following:

Conventions used for NDS objects, such as containers and leaf objects
Property values that will be defined for NDS objects, such as a user's telephone number, fax number, postal address, and so on

Here is a partial example of a naming standard for user objects:

1. Login names are 8 characters so that DOS name home directories can be set up for users.

2. Login names should consist of first name letter plus first seven characters of last name. Other naming conventions also are possible.

3. Given Name property should have the user's first name.

4. Last Name property should have the user's full last name.

5. Title property should have the name of the user's title.

While devising naming conventions, try to keep the names short, descriptive, and easy to remember and identify. Easy-to-remember names make directory searches easier.

To ensure adherence to the naming standard, apply it consistently. Consistency in naming NDS objects provides the following benefits:

Provides a guideline for network administrators when creating, modifying, and renaming objects in the NDS tree.
Eliminates redundant planning for names when a new NDS tree or tree branch is to be designed.
Helps users and administrators quickly identify the network resources.

For NDS operations, NDS names in different containers need not be unique. If these containers are placed in the bindery context (which can have 16 containers) defined by the SET BINDERY CONTEXT server console command, however, the names visible to bindery clients should be unique. If duplicate names exist in the bindery context, only the first name is recognized.

Plan the Implementation Method

After you determine the naming conventions, you must decide on the implementation method, which involves taking the following considerations into account:

Whether you are upgrading from a NetWare 3.x network
Whether you are implementing NetWare 4 in one division and then upgrading the rest of the organization
Whether you plan to create individual NDS trees and then merge them

Whether you plan to create one NDS tree, and whether you want to upgrade or add other servers to the NDS tree. The answers to the preceding issues should contribute to determining which of the following implementation methods to use:

Departmental approach
Divisional approach
Organizational approach
Hybrid approach

The Departmental approach enables a group or department within an organization to implement NetWare 4 without waiting for the rest of the organization to agree on networking goals and an implementation strategy. This approach is useful under any of the following conditions:

There are no direct network communication links between the departmental networks.
Coordination of planners, implementers, and administrators is difficult and not practical.

In the Departmental approach, you end up with several NDS trees, one per department. When the time comes to link the departments using the network, you can use the DSMERGE tool to merge the NDS trees. The DSMERGE requires that the trees being merged have unique tree names. If the trees do not have a unique name, you can use DSMERGE to rename one of the trees. The Departmental approach enables smaller groups within an organization to reap the benefits of NetWare 4 networks while keeping open the option of having a combined NDS tree with other departments in the future.

If one of the NDS trees to be merged has only an Organization container, consider adding an extra Organizational Unit container so that the leaf objects are in their own separate container.

The Divisional approach is used for a large organization that has a separate division implemented by a separate tree in each location. If the needs of the organization require that divisions share network resources, the separate trees can be merged. The Divisional approach could be used with any of the workgroup models discussed earlier (administrative division, workgroups across divisions, geographical locations, hybrid, or mixed environment). The Divisional approach is similar to the Departmental approach, but is bigger in terms of the larger size and complexity of the divisional trees implemented.

The Organizational approach is a top-down approach in which a single NDS tree is created for the entire organization. This approach assumes that you have a clear understanding of the organizational approach and a common agreement on implementing the NDS tree.

To summarize, for the Organizational approach:

A single NDS tree should be used.
All NetWare 4 servers are connected to each other using LAN/WAN links.
A central group of administrators, such as the IS department, can manage the upgrade and implementation of the NetWare 4 network.
The network is small enough that you can perform a near simultaneous upgrade of the network without adversely affecting the organization's business.

If you use the Administrative model for identifying the workgroups, with the Organizational implementation, identification of workgroups might not be readily apparent to the central IS department. Identification of the workgroups requires an understanding of the organizational structure of a company, down to the workgroup level, which is not an easy task for a large company. To assist you with this endeavor, you need working organizational charts for the company, network layout maps, and key personnel to help you identify the workgroups. One approach is to identify the workgroups by the applications they use. This results in workgroups such as NFS, Unix, SAA, and so on. You might additionally conduct an analysis of how information flows in a company to identify the different functional roles. You can use the hybrid workgroup model, with geographic locations at the top of the NDS tree, to preserve the workgroup characteristics of each location. This is easier to do than to define a workgroup that combines the characteristics of all the geographic locations.

Understanding NDS Design Criteria

Proper design of an NDS tree must take into account the following design criteria:

Security of the NDS tree
Partitioning and replication of the NDS tree
Synchronizing time in the NDS tree

These design criteria are discussed in the following sections.

Security of the NDS Tree

Because the NDS tree is a repository of the descriptions of sensitive network resources, you must ensure that the network resources, represented by NDS objects, are properly protected. Users must have the necessary security permissions to access the network resources needed to perform their jobs. However, they should not have excessive rights to network resources (files, applications, printers, and so on) that would constitute a violation of other users' rights or be a potential threat to the organization.

You must, therefore, consider the following design issues that relate to the security of the NDS tree.

Decide between a centralized versus distributed network administration approach.
Determine the proper placement of groups in the NDS tree.
Properly plan inheritance and security equivalencies.
Assign appropriate rights to NetWare Server objects.
Provide appropriate access for traveling users.

These issues are discussed in Chapter 10. Though the default [rights] assignments are adequate for most users and most circumstances, they are summarized here for your reference.

Deciding between Centralized and Distributed Network Administration

The centralized approach is adequate for a small organization. In this approach, a single Administrator user can manage the NDS tree. This is the Admin user object created during installation of the the first server in the NDS tree.

For larger organizations, it is more practical for the functions of network administration to be carried out by a number of administrators, called the container administrators. This is called the distributed approach to network administration. In the distributed approach, the network administration tasks need to be divided among several network administrators. One way to do this is to assign an administrator per tree branch, by giving the administrator appropriate NDS rights to the root container (top-most container) of the tree branch.

Determining the Proper Placement of Groups in the NDS Tree

You can place small workgroup users that have the same needs in an appropriate container object, and use the natural grouping of the container objects to assign rights to the users. Remember that if a container is made a trustee, all User objects in that container and subcontainers have the rights assigned to the container.

In larger networks, User objects in the same container might need different sets of rights. In this case, consider using the NDS Group object. The NDS Group object is particularly useful for users who are in different containers, yet need the same permissions; for example, users working on a common project but in different departments might need a common set of rights. When assigning members to Group objects, take into account situations in which members of the Group object and the resources they access are separated by WAN links. In this case, authentication occurs across the WAN links and could lead to undesirable network traffic across the WAN link.

You also might consider use of the Organizational Role object for assigning permissions for well-defined tasks, such as backup operations.

Planning Inheritance and Security Equivalencies

The placement of User objects in groups and containers affects the rights that these objects inherit. User objects that are members of Group objects are security equivalents to the Group object. The Group object in which the User object is a member is listed explicitly in the Security Equal To property of the User object. Membership in a Group object is, therefore, called explicit security equivalence. Figure 2.53 shows that the Group object CN=Students.O=IBL is listed in the Security Equal To property of the User object Lisa. Figure 2.54 shows that Lisa is a member of the Group object CN=Students.O=IBL.

Each container above the user, all the way up to the [Root], can contribute to the rights that accrue to the user, even though these rights do not show up in the Security Equal To property of the User object. Figure 2.53 shows that the Security Equal To property of the user Lisa does not contain its parent O=IBL. Because the containers do not show up in the Security Equal To property of the User object, the User object has an implied security equivalence to its parent containers. For example, all users in an NDS tree have an implied security equivalence to the [Root]. Any right assigned to the [Root] is implied for all users in the NDS tree.

Figure 2.53 Explicit security equivalence of User to Group object.

Figure 2.54 User membership to Group object.

Assign Appropriate Rights to NetWare Server Objects

Be careful how you assign NDS rights to NetWare Server objects. The Write property right to the ACL of the Server object gives the user the Supervisor file system right to the root of all volumes attached to the server. If you assign a user the Supervisor object right to the Server object, for example, the user has Supervisor file system rights in the server's volumes--because assigning to a user the Supervisor object right to the Server object gives the user the All Properties right to the Server object. The All Properties Supervisor property right to the Server object gives the user the Write property right to the ACL of the Server object. The Write property right to the ACL of the Server object gives the user the Supervisor file system right to the root of all volumes attached to the server.

Providing Appropriate Access for Traveling Users

As traveling users try to use their time more efficiently by accessing their organization's network from remote locations, special considerations for NDS rights need to be given to such users. The following discussion is based on Novell's classifications of traveling users:

Users who divide their work time between home and office.
Users who need access from a temporary location while they are working on special projects.
Users who spend a considerable amount of their work time traveling and need access to the network regularly from remote locations.

For each type of user, consider the following issues:

Access to files on server volumes.
Access to applications.
Access to files from several remote locations.
Access to resources such as printers and e-mail accounts.
Authenticating NDS and NDS objects.
Number of traveling users.
Type of computers used by traveling users (portable versus desktop).

Partitioning and Replication of the NDS Tree

Recall that if the database is centralized, a failure in the network at the central location would make the NDS database unavailable to the entire network. For small LANs, the issue of centralization is not of as much concern. But for large networks that are separated by wide area network links, centralization can become a reliability problem.

It is best to distribute the database in such a manner so that a single failure does not disable the entire NDS service.

Consider the following design issues for partitioning and replication:

Plan partition boundaries.
Determine the appropriate replica assignments.
Determine accessibility and fault tolerance versus network traffic and performance.
Determine the effect of WAN links.
Assign administrators of partitions and replicas.

These design issues are briefly discussed next.

Plan Partition Boundaries

The logical subdivisioning of the NDS tree into partitions should be based on the following factors:

Geographic location
WAN topology
Access to directory information
Number of objects in containers
Needs of workgroups of users
Access to information on network
Reduction of unnecessary traffic on network
Elimination of single point of failure

Determine the Appropriate Replica Assignments

When a server is installed in an NDS tree, a default number and type of replica is created. These defaults are designed to prevent single points of failure. You might want to have additional replicas to make information in the replica more easily accessible.

Determine Accessibility and Fault Tolerance versus Network Traffic and Performance

To improve accessibility of information in the NDS tree, and the fault tolerance of a partition, you might want to create additional replicas. Creating additional replicas ensures that the NDS information is available even when the master replica and replicas in other locations are corrupted.

Ease of accessing information also requires that replicas are kept on local servers. However, as the number of replicas increase, so does the amount of network traffic and the time needed to keep the replicas synchronized. The additional network traffic also has an adverse effect on network performance. You must balance the requirements for accessibility and fault tolerance versus the requirements for minimizing network traffic and not degrading network performance.

Determine the Effect of WAN Links

If excessive network traffic results from replica synchronization on the WAN links, network performance of the WAN link is impacted. Many WAN links have relatively low bandwidths and are costly, so you might want to prevent saturation of these links.

Assign Administrators of Partitions and Replicas

Partitioning changes result in network traffic, particularly when several partition changes occur in a short time. To make partition changes such as splitting or merging partitions, you need Supervisor object rights to the roots of the affected trees. You must, therefore, assign the responsibility for making these changes to specific administrators. You must coordinate your efforts more closely if the changes will be propagated to servers in different geographical locations.

Synchronizing Time in the NDS Tree

Replica synchronization needs an accurate time reference that should be the same throughout the network to ensure that the NDS operations are timestamped accurately, regardless of where they are performed on the network. Timestamps are a unique code that records the time at which an event takes place, as well as the replicas that originate it.

Accurate timestamps on NDS operations are essential to ensure that the NDS database is updated and synchronized correctly. A change made to a replica of a partition is propagated to all servers that are part of the replica ring. The timestamps are used for ordering the directory events that occur.

The following are design issues to consider when assigning time synchronization:

Determine the time server types for the NDS tree.
Coordinate time sources.
Reduce WAN traffic for synchronizing time.
Determine the affect on time synchronization in case of directory tree merges.

Determine the Time Server Types for the NDS Tree

You must decide on the time server types that best suit your network needs. For small networks and for workgroup applications the default time server type setting is adequate. When the first NetWare server is installed in the NDS tree, it is set up as a single reference time server by default. Additional servers in the tree are set up as secondary time servers.

The single reference time server represents a single point of failure, and, on larger networks, you should increase the fault tolerance of the time source by providing multiple time sources. You might want to select a combination of primary time servers and reference time servers as time sources, for example. In any case, you must have a proper plan to coordinate the deployment of different server types. (See Chapter 13 for more on time synchronization.)

Time Provider Groups

If you have a large network, your design should take into account time provider groups. The time provider groups should be designed to provide local access to time sources and increase fault tolerance of the time sources. You should also try to minimize the affect of time synchronization traffic on the network.

If you use a distributed network management strategy, you must coordinate the addition or changes to the time provider groups with other container administrators.

Coordinate Time Sources

If your network design includes WAN topologies, try to avoid secondary time servers having to communicate with a time source across a WAN link. Secondary time servers should obtain network time from a local time source.

Reduce WAN Traffic for Synchronizing Time

Each NDS tree has its own sets of time sources. If you have to merge NDS trees (using the DSMERGE NLM, see Chapter 5), you must plan for the resulting tree to have appropriate time sources. If each NDS tree has its own single reference time server, for example, you cannot have two single reference time servers in the resulting tree because an NDS tree can have only one single reference time server.

Designing the NDS Tree

This section presents two case studies showing how you can design a proper NDS tree. As part of designing the NDS tree, you must consider the relevant design issues discussed in the previous sections.

NDS Design--Case Study 1

Sita Corp. has its corporate head quarters in New York. The New York headquarters also has the Finance, Marketing, and Administration departments for the entire organization. Each of these departments in New York has its own NetWare 4 server with the Administration department having two servers. All divisions of the organization share a common corporate server in New York.

Additionally, Sita Corp. has sales offices in London and Paris, each of which has its own server and at least one network printer.

Users in each location need to share information with the rest of the company and network connections exist between each location.

Draw a directory tree for Sita Corp. and show the partition boundaries, replica assignments to servers, and time server types.

Solution: One of the case study's requirements is that users in each location need to share information with the rest of the company, best accomplished by placing the network resources in a single NDS tree, possible because network connections exist between each location.

The different locations suggest the use of the Geographical location model for assigning workgroups. The workgroups can correspond to organizational units that are under the Organization object named SITA. The workgroups in London and Paris can be named after those locations. Because each of these locations only has the Sales office, additional subcontainers at these offices are not necesary. New York, on the other hand, has three departments: Finance, Marketing, and Administration, each of which can be modeled as an Organizational Unit object under the New York container. Figure 2.55 shows a possible NDS tree for this case study. The NDS tree shows the partial resources described in the case study. Because the Corporate server is shared by all departments, it falls directly under the O=SITA container.

Figure 2.55 NDS tree for case study 1.

The partition boundaries for this NDS tree are shown in figure 2.56. Each location has its own partition boundary that represents the subtree for that location. The [Root] partition is kept at New York because New York hosts the corporate head- quarters.

Figure 2.57 shows the replica assignments for the NDS tree. Notice that there are two Read/Write replicas of the OU=LONDON and OU=PARIS partitions kept in New York and another location. The [Root] partition, because it is the most critical, has two replicas kept in New York, and one Read/Write partition on the servers in London and Paris. Each location has a replica of the master partitions in other locations. The master replica for a partition is kept on a server at that location. If you want extra redundancy, you might want to keep an additional read/write replica of the OU=LONDON and OU=PARIS partitions on servers MKTG_FS and ADM_FS2, respectively.

Figure 2.56 Partition boundaries for NDS tree for case study 1.

Figure 2.57 Replica assign-ments for NDS tree for case study 1.

Figure 2.58 shows the time server types of each server. Each location has its own time source. New York has a reference time server, and the other locations (Paris and London) each have a primary time server. All other servers are secondary time servers.

Figure 2.58 Time server types for NDS tree for case study 1.

NDS Design--Case Study 2

Rama Corp. has corporate headquarters in Livingston, Montana, housed in a single building. The headquarters contains the Finance, Marketing, Sales, and Production departments, each of which has its own NetWare 4 server and at least one printer.

Users in each location need to share information with the other departments and network connections exist between each department.

Draw a directory tree for Rama Corp. and show the partition boundaries, replica assignments to servers, and time server types.

The different workgroups suggest the use of the Administrative division model for assigning workgroups. The workgroups can correspond to departments that are implemented as organizational units under the Organization object named RAMA. Figure 2.59 shows a possible NDS tree for this case study. The NDS tree shows the partial resources described in the case study.

The partition boundaries for this NDS tree are shown in figure 2.60. The simplest partition solution has only the [Root] partition.

Figure 2.61 shows the replica assignments for the NDS tree. Notice the two Read/Write replicas of the [Root] partition.

Figure 2.59 NDS tree for case study 2.

Figure 2.60 Partition boundaries for NDS tree for case study 2.

Figure 2.61 Replica assign-ments for NDS tree for case study 2.

Figure 2.62 shows the time server types of each server. The server on which the master replica of [Root] is kept acts as a single reference time server. All other servers are secondary time servers.

Figure 2.62 Time server types for NDS tree for case study 2.

This chapter discussed the structure of NDS and explained how to design an NDS tree for your network. NDS represents an exciting way to manage the network as a logical entity. Because NDS is a key service in NetWare 4.x, many details of its operations were provided in this chapter. One concept covered was NDS as a global database for network management. This global database is accessible from any point on the network. The nature of NDS objects was examined, and each different type of leaf and container object was described in detail. The NDS naming rules were discussed and several examples were given. Among the key concepts covered were current context, complete names, typeless names, partial names, and period rules.

The chapter concluded with procedures, recommendations, and case studies that described the process of NDS design.

Migrating to Netware 4.1 -- Ch 2 -- Designing Your NDS Tree