An Introduction to NetWare Directory Services
Articles and Tips: article
Senior Technical Editor
Systems Research
01 Apr 1993
NetWare Directory Services (NDS) is a globally distributed network database that replaces the bindery used in previous versions of NetWare. This AppNote introduces the basic concepts behind NDS, discussing NDS objects and properties and telling how Root, Container, and Leaf objects form the Directory tree. It also explains about NDS partitions and replicas, bindery compatibility, and time synchronization.
- Introduction
- Overview of NetWare Directory Services
- NDS Objects
- How Objects Form the Directory Tree
- Managing the NDS Database
- Bindery Compatibility
- Network Time Synchronization
- To Plan Your Tree
Introduction
The most noticeable new feature of NetWare 4.0 is its globally distributed Directory. NetWare Directory Services (NDS) is more than just a global naming service; it also provides an easily managed and more secure network environment. With NDS, it is now possible to integrate a diverse network of resources into a single, easy-to-use environment.
Note: The term "Directory" (with a capital D) refers specifically to the global, distributed database provided in NetWare 4.0. The NDS Directory is different from the file system directory and its structure.
This AppNote introduces the basic concepts behind NetWare Directory Services. After giving a quick overview of NDS, it discusses NDS objects and properties and explains how these objects form the Directory tree. It also explains about NDS partitions and replicas, bindery compatibility, and time synchronization.
The next AppNote in this issue builds on these concepts and provides guidelines for planning your own Directory tree. It also gives detailed examples of setting up a small, medium-sized, and large Directory tree.
Overview of NetWare Directory Services
NetWare Directory Services is a global, distributed, and replicated database. As part of NetWare 4.0, NDS maintains information about all network resources (users, groups, servers, volumes, printers, and so on) in a hierarchical tree structure. Network resources can be organized in the tree independent of their physical location. Thus network users can access any network resource they have rights to, without having to know the exact location of that resource.
The Directory replaces the NetWare bindery, which served as the system database for previous versions of NetWare. Rather than supporting a single server (as the bindery did), NDS supports an entire network of servers. Distributing the network database allows all servers to easily access all network information. It also allows the database to be replicated, thus minimizing the risk of a single point of failure.
NetWare 4.0 provides compatibility with bindery-based versions of NetWare through the bindery emulation feature of NDS.
NDS is based on parts of the CCITT X.500 standard. By not locking NDS strictly into this proposed standard, Novell allows for future expansion of the Directory and of the possible services it can provide.
Network-Wide Login
With NDS, users no longer need to login or attach to specific servers. Instead, they can login to the network. For example, a user could log in to the network by typing:
LOGIN GHERBON
instead of
LOGIN servername/GHERBON
Once logged in to the network, users can access any service or resource they have rights to, without having to explicitly login or attach to other servers. The users will be transparently attached to the server on which the specified service resides. NDS handles all of the address resolution issues in the background, so users are shielded from the complexity of having to understand the network topology, protocols, media, and communication links.
Because the NDS database is replicated, multiple copies of users' required login information are spread throughout the network. This replication allows users to login to the network whether or not their "home" server is on-line. As long as the servers which provide the necessary data or services are operational, the user can access them. In this sense, when a user is logged in to the network, servers become "transparent" to the process of actually using the network.
Authentication
In NetWare 4.0, users' access to network resources is restricted by the rights they are assigned in the Directory. When a user accesses network resources (such as servers, volumes, and printers), authentication occurs in the background. The authentication process verifies that the user has sufficient rights to use the requested resource.
The network-wide login and background authentication that NDS provides effectively locks out unauthorized users and makes using the network and accessing resources easier for authorized users. Users need only one password to gain access to all network resources available to them. Of course, the available resources will be limited to those the user has been granted rights to.
A New Mindset
For years, NetWare has relied on the bindery to store and provide all information necessary for the operating system and applications. The bindery contained information about users and groups, valid passwords, rights, attached printers, and other network resources. However, adding new users to a server (or especially to several servers) was a tedious, time-consuming process.
If you use NDS with NetWare 4.0, you have at your disposal a powerful yet easy-to-use computing environment, complemented by enhanced security and network management capabilities. However, before you can simplify network administration through the use of NDS, you need to adjust to a completely new mindset. You need to view the network as a unified information system rather than a fragmented collection of computers. This new mindset will take some getting used to, but it will make enterprise networking feasible and desirable - even among those from the mainframe world who have argued against the use of PC-based networks.
NDS provides for easier management of the network resources listed in the Directory. However, it is important to remember that the Directory does not directly control the NetWare file system (volumes, directories, and files). NetWare 4.0 provides text-based and graphical utilities to manage both NDS and the file system.
NDS Objects
The NDS Directory tree is formed by placing "objects" in a hierarchical tree structure. NDS objects consist of categories of information, known as properties, and the data included in those properties. This information is stored in the Directory database.
The NDS database can contain three types of objects:
Physical objects (such as users and printers)
Logical objects (such as groups and print queues)
Other objects (such as Organizational Units) designed to help organize and manage the physical and logical objects
It is important to understand that NDS objects are structures that store information, not the actual entity represented by the object. For example, a Printer object stores information about a specific printer and helps manage how the printer is used, but it is not the physical printer itself.
Object Properties
As mentioned above, properties are categories of information stored in the database for NDS objects. Each NDS object has properties that contain information about that object. For example, this information may include a user's telephone number and physical address, or the physical location of a printer.
You enter the information, or values, about the object into data fields for each property. For example, a User object includes the following properties:
Login Name
Telephone Number
E-mail Address
Password Restrictions
Group Membership
Address
And others ...
Figure 1 shows the relationship between objects, properties, and values.
Figure 1: An NDS object (such as a user) consists of numerous properties with corresponding values.
|
Object |
Property |
Value |
|
User |
Login NameEMailAddressTelephone NumberAddress |
GHerbonGHerbon@Novell800-555-4321123Oak StreetAnywhere, USA xxxx |
In many cases, you can enter more than one value for a property. An example is the Telephone Number property for User objects. In this property, you can enter values for a user's office phone number, home phone number, cellular phone number, and pager number.
Once the values are entered in the object properties, you can perform a search for objects with specific values. For example, if you request information that specifies a certain area code, the Directory database could return all telephone numbers that contained the specified area code in their properties.
You can also request information on a specific object and receive information on all properties of that object which you have access to.
Object and Property Rights
Before we discuss how NDS objects form the Directory tree, we need to explain a little bit about rights. In NetWare 4.0 there are four different kinds of rights:
File system directory rights
File system file rights
NDS object rights
NDS property rights
Previous versions of NetWare had file system directory and file rights, and very limited "access levels" to bindery objects. NetWare 4.0 adds NDS object and NDS property rights, which determine what you can do within the Directory. For brevity, we'll simply call these object and property rights. Since this AppNote deals only with NDS, we won't discuss file system rights here.
The concepts about NDS object and property rights summarized here are discussed in greater detail in the "Understanding Directory Services Rights" AppNote in this issue.
Because the Directory is a hierarchical tree structure, rights assigned in the Directory flow down through the tree. This is an important concept to understand when you are designing your Directory tree.
To provide better access control to the pieces of information (properties) contained in NDS objects, object and property rights are assigned separately.
Object rights control what a trustee is allowed to do with the object. These rights include Browse, Create, Delete, Rename, and Supervisor.
Object rights control access to an NDS object as a single piece of the Directory tree, but they do not allow access to information stored within that object (its properties). The only exception is the Supervisor object right, which applies to an object's properties as well as to the object itself.
Property rights control a trustee's access to information associated with the object (in the object's properties). These rights include Compare, Read, Write, Add or Delete Self, and Supervisor.
Property rights apply only to NDS object properties, not to the objects themselves. For example, if you include a telephone number as a property fora User object, you can prevent anyone else from seeing the specified telephone number by not granting them the Read right to that particular property. At the same time, you can still allow the person to view other properties, such as the user's address. This allows flexibility in deciding what information others can access.
Access Control List. The information about who can access object information is stored in the object itself, in a property known as the Access Control List (ACL). The ACL property contains the trustee assignments and the Inherited Rights Filter (explained below).
An object's ACL defines which objects can access that object and its properties. For example, an object listed in a Printer object's ACL is a trustee of that Printer object and therefore has some rights to the printer. To change the trustee's access to the Printer object, you would change the trustee's entry in the Printer object's ACL. Only trustees with the Write right for the ACL property can change the trustee assignments or the Inherited Rights Filter.
Each object listed in an ACL can have different rights to that object's properties. For example, if ten users are listed in the Modem object's ACL as trustees, each of those ten users can have different rights to that Modem object and to its properties. However, in actual use, it is likely that at least some of the users will have the same rights (or at least similar rights) to the Modem and its properties.
Inherited Rights Filter. While trustee assignments grant access to an object, the Inherited Rights Filter (IRF) prevents rights from automatically propagating from one object to another. In the Directory tree, an object can automatically receive, or "inherit," rights from its parent objects. The IRF can be used to block any or all of these inherited rights so that no objects can receive them. Every object and property in the Directory can have an Inherited Rights Filter.
Effective Rights. The combination of inherited rights, trustee assignments in an ACL, and security equivalences are known as effective rights. An object's effective rights are what control its access to another object and that object's properties.
How Objects Form the Directory Tree
NDS operates in a logical organization called the Directory tree. This is so named because objects are stored in a hierarchical tree structure. By time-honored computer science convention, this structure has the tree growing upside down starting with the [Root] object at the top of the tree and branching downward.
The Directory tree is made up of three types of objects:
The [Root] object
Container objects
Leaf objects
The [Root] object is automatically placed at the top of the tree by the NetWare 4.0 installation program. Branches of the Directory tree consist of container objects and all of the objects they hold. These container objects can also contain other container objects. Leaf objects are at the ends of the branches and do not contain any other objects.
Figure 2 illustrates how objects can be laid out to form the Directory tree.
Figure 2: The Directory tree is formed by container objects and leaf objects branching down from the [Root] object.
The sections which follow discuss the three types of objects in greater detail.
[Root] Object
The [Root] object can only be created by the NetWare 4.0 installation program, which automatically places it at the top of the tree. The [Root] object cannot be renamed or deleted.
Note: The [Root] object of a Directory tree should not be confused with the root directory in the file system. In the file system, the root directory is the first directory on a volume. It bears no relation to the [Root] object of a Directory tree.
The [Root] object can have trustees, and the [Root] object trustees' rights flow down the tree. One example is the User object Admin, which is created automatically during installation. By default, Admin receives a trustee assignment of Supervisor rights to the [Root] object of the Directory tree. This gives Admin all rights to all objects and properties in the tree, so that it can be used to initially log in and set up the tree.
(For more information about Admin, refer to the "User Object Admin" section later in this AppNote.)
The [Root] object can also be a trustee. However, you should give careful consideration before making [Root] a trustee of another object. If you do, every object in the tree has the same rights as the [Root] object by virtue of ancestor inheritance. In effect, you will have made all users security equivalent to [Root].
Container Objects
Container objects hold (or contain) other Directory objects. Container objects are provided as a means of logically organizing all other objects in the Directory tree. Just as directories are used to group related files together in a file system, container objects are used to group related items in the Directory tree.
There are two kinds of container objects: Organization and Organizational Unit. These are explained below.
Note: The NDS Directory also supports Country and Locality as container objects. In normal usage, however, these container objects should not be necessary as they can add unnecessary complexity to your Directory tree. For this reason, we do not cover these options.
Organization (O). An Organization object helps you organize other objects in the Directory tree. It also allows you to set defaults for User objects you create in the Organization container.
You can use an Organization object to designate a company, a division of a company, a university or college with various departments, or a department with several project teams.
Important: Use of the Organization object is mandatory. Every Directory tree must contain at least one Organization object. Organization objects must be placed one level below the [Root] object.
Organizational Unit (OU). An Organizational Unit object helps you to organize leaf objects in the Directory tree. It also allows you to set defaults in a login script, and create a user template for User objects you create in the Organizational Unit container.
You can use an Organizational Unit object to designate a business unit within a company, a department within a division or univeristy, a project team within a department, and so on.
Important: Use of Organizational Unit objects is optional in a Directory tree. If used, Organizational Units must be placed one level below an Organization or another Organizational Unit.
In the initial NetWare 4.0 release, you cannot easily change the name of a container object once it is named. To avoid possible problems, you should carefully plan the names of your container objects before implementing your Directory tree.
Leaf Objects
Directory leaf objects are objects that do not contain any other objects. These represent actual network entities such as users, servers, printers, computers, and so on. The sections below list and describe the different types of leaf objects available in NDS.
User-Related Leaf Objects. The following leaf objects deal with network users and groups.
User
A User object represents a person who logs in to and uses the network. You must create a User object for every user who needs to login to the network. When you create a User object, you can create a file system "home" directory for that user which includes default rights assignments. You can also define a USER_TEMPLATE object to provide new users with default settings that you have already decided on.
Users with NetWare 4.0 workstations (those who use NDS rather than bindery emulation) can be created anywhere in the Directory tree. They must know their exact NDS context in order to log in. To make this easier, enter users' context in their workstation NET.CFG file when you install their NetWare 4.0 workstations. This setting automatically places them in the correct context every time they login from their workstation.
Users with non-4.0 workstations must be created in the container where the bindery emulation context is set for their primary server. Remember that bindery emulation is set (by default) for every NetWare 4.0 server that is installed. Non- 4.0 users do not need to know their context because they are logging in to a server rather than the Directory tree. (For more information, see the "Bindery Compatibility" section of this AppNote.)
Group
A Group object assigns a name to a list of User objects located anywhere in the Directory tree. Use a Group object when you want to assign rights to a group as a whole, rather than just individual users. The rights assigned to a Group object are granted to individual users who are members of the group, no matter where they are located in the Directory tree.
Profile
A Profile object contains a profile script (a type of login script). The Profile object listed as a property in a User object is executed when that User objects logs in to the network. The Profile object is executed after the system login script, but before the user login script.
Create a Profile object for any set of users who need to share common login script commands, but who are not located in the same Directory container, or for any users who are a subset of users in the same container.
Organizational Role
An Organizational Role object defines a position or role within an organization. An example might be a department manager or vice president of sales, and so on. You can assign any User object to be an occupant of the Organizational Role object. Any occupant receives the same rights that were granted to the Organizational Role object.
You create an Organizational Role object to assign rights to a particular position in the organization where the person holding the position might change frequently, while the actual responsibilities of the position do not change often. It can also be used when you have a job where you want different people to handle the same job at different times of the year.
For example, suppose you wanted a Print Manager for the Sales department, but you do not want the same person to do the job for more than a one- month period. You could create an Organizational Role object called PRINT MANAGER and grant that object all object rights to the Printer, Print Queue, and Print Server objects in that part of the Directory tree. You might also grant the PRINT MANAGER object the property rights to the Print Job Configuration property of users. This allows the PRINT MANAGER Organizational Role object to manage all printing in the SALES container, without having to grant these rights to individual users.
Server-Related Leaf Objects. The following leaf objects are related to NetWare servers and volumes.
NetWare Server
A NetWare Server object represents a server running NetWare on your network. Whenever you install a server in the tree, a NetWare Server object is automatically created.
Use this object to store information about the server in the NetWare Server object's properties. This can include such information as the server's location on the wire, the server's physical location, what services the server provides, and so on.
In addition to storing information about the NetWare server, this object affects the network in that it is referred to by several other objects in the Directory. One example is the NDS Volume object, which points to the NetWare Server object to find a physical volume on the network. Another example is the Directory Map object, which points to the NetWare Server object to find the file system directory it needs.
The NetWare Server object is also used to tie the physical server on the network to the Directory tree. Without this object you cannot access file systems that reside on the server's volumes.
For informational purposes, you can also create NetWare Server objects for servers not in the Directory tree (such as 3.11 servers not in the tree).
Volume
A Volume object represents a physical volume on the network. INSTALL automatically creates a Volume object for every physical volume on a server at installation time.
In the Volume object's properties, you store information about which NetWare server the physical volume is located on, and the name given when the volume was initialized at installation (such as SYS). If you create a Volume object during installation, this necessary information is placed in the Volume object's properties by default.
Properties in the Volume object are also used for mapping drives.
In the NetWare Administrator (GUI utility version), you can click on the Volume object icon to display information about the file system directories and files located on that volume.
Directory Map
A Directory Map object represents a particular directory path or file in the file system of a given server. This is currently used only by the MAP utility. Directory Map objects are especially useful in login scripts, because they can be set to point to directories that contain applications or other frequently used files.
For example, if you have a directory that contains DR DOS 6.0, you will probably map a search drive to that directory in all login scripts you create. If you later decide to upgrade to a newer version of DR DOS and rename the directory, you have to change the mapping in every login script that contains that search mapping.
By using the Directory Map object, you avoid the necessity of making all these login script changes. Instead, you just change the Directory Map object, and all the search mappings in your login scripts are updated to find the new version automatically.
Printer-Related Leaf Objects. The following leaf objects are related to NetWare's print services. These objects are created and controlled using the NetWare print utilities.
Print Queue
A Print Queue object represents a print queue on the network. You must create a Print Queue object for every print queue on the network.
Print Server
A Print Server object represents a network print server. You must create a Print Server object for every print server on the network.
Printer
The Printer object represents a physical printing device on the network. You must create a Printer object for every printer on the network.
Informational Leaf Objects. The following leaf objects have no effect on network operation; their sole purpose is to store information about network resources.
AFP Server
AFP Server represents an AppleTalk Filing Protocol (AFP)-based server on your NetWare network. Currently, the AFP Server leaf object provides no functionality. It can only be used to store information about the server, such as its network address, operators, and users.
If you have more than one AFP server on your network that you want to store information about, create a separate object for each one. For example, if you have three AFP servers on your network, you would create three separate leaf objects (one for each server), which you might name AFP_ServerName1, AFP_ServerName2, and AFP_ServerName3.
Computer
A Computer object represents a non-server computer on the network. This object can represent such things as a workstation or a router. Use this object to store information about the computer, such as its network address, serial number, or even the person the computer is assigned to.
Miscellaneous Leaf Objects. This section lists the remaining types of NDS leaf objects.
Alias
An Alias object refers to another object in the Directory tree and makes it appear as if the object that it names actually exists in the Directory tree at the point where the Alias is created.
Bindery Object
A Bindery Object represents a non-NDS object placed in the Directory tree by an upgrade or migration utility. It is used by NDS only to provide backward compatibility with bindery- oriented utilities.
Bindery Queue
A Bindery Queue object represents a non-NDS queue placed in the Directory tree by an upgrade or migration utility. It is used by NDS only to provide backward compatibility with bindery-oriented utilities.
Unknown
An Unknown object represents an NDS object that has been invalidated and cannot be identified as belonging to any of the other object classes.
Possible Directory Tree Configurations
In a Directory tree, you can place container objects and leaf objects in different configurations according to what best suits your needs. Figure 3 shows several possible configurations.
Figure 3: Sample configurations for a Directory tree.
You are not limited to using only one container object in a Directory tree. Most Directory trees will have at least several container objects. Figure 4 shows a sample Directory tree with several container objects at each level of the tree.
Figure 4: Sample Directory tree with multiple container objects at different levels.
Although you can have numerous container objects in a Directory tree, you can have only one level of Organization objects.
The number of levels of Organizational Unit objects you can have is unlimited. However, consider carefully how many levels of container objects you need in your Directory tree. The number of levels you have can potentially affects how easily your users can login from locations other than their own computer. (This and other important considerations are discussed in the "Planning a NetWare 4.0 Directory Tree" AppNote in this issue.)
Figure 5 summarizes what we have discussed so far about NDS objects and how they form the Directory tree.
Figure 5: NDS Directory tree at a glance.
NDS Context
In NDS, the term "context" refers to your current location in the Directory tree. This context is important for the Directory to locate specified network resources. Figure 6 shows some examples of Directory contexts.
Figure 6: An object's Directory context indicates its current location in the tree.
The complete context, or path, from an object to the [Root] of the tree forms the object's complete name. Thus, in Figure 6, the complete name of leaf object "WHarding" in Organizational Unit "Sales PV" in Organizational Unit "Sales" in Organization "Novell US" would be denoted as:
WHarding.Sales PV.Sales.Novell US
The complete name of each object must be unique.
The name context is also important when logging in. When you log in to the network, you automatically request authentication services. Based on your current context and the login name you provide, authentication services must find a User object that matches your user name. NDS can then use the property values associated with your object to validate your password and other user account restrictions you might have. When this process is successfully completed, you are authenticated as a valid network user and have full access to all network resources you have access (through rights) to use.
For more information about NDS context and logging in, see the "Using the DOS Requester with NetWare 4.0" AppNote in this issue.
Common Names. Most leaf objects in the Directory will have a common name (CN). For User objects, the common name is the login name that is displayed in the Directory tree. For example, in Figure 7 the common name for Gamal Herbon's User object is GHerbon.
Figure 7: Sample Directory tree showing common names and name types.
Other leaf objects also have common names displayed in the Directory tree, such as a Printer object name, Server object name, and so on.
Name Type. Remember that an object's complete name is a bottom-up transversal of the Directory tree from the object up to (but not including) the [Root]. In certain cases, you might need to include the name type of the object in the complete name of the object. A name type distinguishes the specific class of object you are referring to, such as a User object or an Organizational Unit object.
In most cases, you do not need to use name types. However, if you do need to use them, the following example shows how you can express the typeless name as a name using name types. To use the previous example, you could express
GHERBON.SRD.SERVICES.NOVELL
as
CN=GHERBON.OU=SRD.OU=SERVICES.O=NOVELL
where CN is the common name of the leaf object, OU is the Organizational Unit name(s) (two in this case), and O is the Organization name.
If you are simply referring to an object that is in the same container object as your User's object, you can simply refer to the specified object by its common name instead of its complete name. For example, if the User object named GHerbon located in SRD.SERVICES.NOVELL (as shown in Figure 7) wants information about User object KNeff (which is also located in SRD.SERVICES.NOVELL), then GHerbon need only refer to the User object as KNeff.
Any time you move from one container object to another, your Directory context is changed. Whenever you change contexts, you must indicate the complete name of the object you are changing context to. You may have to include the name type of the object in the context.
For more information about Directory contexts, refer to the NetWare 4.0 Documentation.
Making Object Names Unique. As mentioned, all complete names must be unique within a Directory tree. In addition, all container and object names must be unique within that container.
Important: In order for User object names to be unique, we recommend that you use E-mail naming conventions (or actual E-mail names, if possible) to ensure that each user has a unique common name.
If you had two users with the same object name residing in the same container, you would have a problem because the Directory only recognizes unique names within any container.
For example, suppose you have assigned user Jane Ann Doe the Directory name of JDOE in the SALES container. If you then assign user Jane Marie Doe the name JDOE in the same container, this would preclude the two users from having unique rights and access to Directory resources. The Directory only recognizes one JDOE in that container.
In cases like this, we recommend that you include the user's middle initial (or some similar unique feature) to create distinct user names. For Jane Ann Doe and Jane Marie Doe, you could create unique users JADOE and JMDOE.
The same is true for Directory containers, resources, and all other objects. To prevent Directory conflicts, give each user, resource, and container that resides in the same container a unique name.
Managing the NDS Database
An important factor to consider in NetWare 4.0 is management of the NDS database. NDS management includes the creation and management of objects, and distribution of the database partitions and replicas. This section provides an overview of the main tasks involved in managing the NDS database.
User Object Admin
The very first time the network supervisor logs in, it is as the User object Admin. A single Admin object is created by default during NetWare 4.0 installation. However, NetWare 4.0 does not require you to limit yourself to one network supervisor. (We use the term "network supervisor" to refer to the person responsible for setting up NetWare 4.0.)
When the User object Admin is created on the first NetWare 4.0 server you install, it is granted all rights (including the Supervisor right) to every object and property in the Directory tree. This gives Admin complete control of the tree (initially) for management purposes.
As part of this rights assignment, Admin receives the Supervisor object right to the NetWare Server object. This in turn gives Admin the Supervisor right to the root directory of all volumes attached to the server, so it can be used to manage all directories and files on every volume in the Directory tree.
However, user Admin does not have any special significance like that of SUPERVISOR in previous versions of NetWare. Admin is granted rights to create and manage all objects simply because it is the first object created.
In addition, the following rights are granted by default to provide basic network functionality:
[Public] has the Browse object right to the [Root] object. This means that all users can browse the entire Directory tree. [Public] is the equivalent of "attached but not logged in" in bindery-based NetWare.
The SYS Volume object's container object is granted Read and File Scan rights to the volume's SYS:PUBLIC directory. This means that when users are created in that container, they can access all utilities located in the SYS:PUBLIC directory.
Users are granted Read rights to all attributes and Write rights to their login scripts.
As other User objects are created in the Directory, you can grant the Supervisor object right to selected objects or to entire Directory subtrees. Other objects that receive the Supervisor object right are allowed to create and manage other container objects and their leaf objects. This allows network control and management to be as centralized or as dispersed as you want to make it.
After you have assigned another User object the Supervisor object right to the [Root] object, you can rename or delete the User object Admin.
Warning! Never delete User object Admin without having previously assigned the Supervisor right to the [Root] object. The results can be disastrous, as you will have no Supervisory control of the Directory tree. This warning also applies to other sections of the Directory tree where you have a User object Admin defined, not just the [Root]. At each level of the tree where you have Admin defined, be sure you also have a User object with Admin rights (not equivalences). If this situation should occur and you lose control over all or part of your tree, contact Novell Technical Support.
NDS Partitions
NDS partitions are logical divisions (or portions) of the Directory's global database that can be replicated. An NDS partition forms a distinct unit of data in the Directory tree used to store and replicate Directory information.
Note: NDS partitions are in no way related to the logical disk partitions which are created on server hard disks during installation. Do not confuse the two types of partitions.
The [Root] object (at the top of the tree) is always included in the first partition created, which is known as the Root partition.
Figure 8 shows an example of the default partition created for the first NetWare 4.0 server installed, as well as the partitions created for the new Organizational Units created in subsequent installations of NetWare 4.0 servers.
Figure 8: Example of default partitions created during installation of three NetWare 4.0 servers.
Replicas
For NDS to be distributed across a network, portions of the database should reside on many servers. Rather than keep a copy of the whole database on every server, copies of each partition can be stored on many servers throughout the network. This distribution minimizes the risk of any single point of failure for the Directory.
A replica is a copy of a partition. You can create an unlimited number of replicas for each partition and store them on any servers on the network. However, we recommend you have no more than 8 to 10 replicas of any one partition (unless necessary to cut down on WAN link traffic).
Replicas serve two purposes:
To provide Directory fault tolerance to minimize the risk of any single point of failure.
To provide faster access to Directory information for users across a WAN link.
Directory Fault Tolerance. If a disk crashes or a server goes down, a replica on a server in another location can still authenticate users to the network and provide information on objects in the disabled server's partition.
With the same information distributed on several servers, you are not dependent on any single server being up to authenticate you to the network or to provide services to you. You can store a replica of one partition with a replica of another partition on the same server.
Figure 9 shows an example of the maximum amount of replica-tion and distribution possible for a four-server network. In reality, this example would probably be overkill. It is used here as an illustration only.
Figure 9: Example of Directory fault tolerance.
Important: Directory replication does not provide fault tolerance for the file system. Only information about Directory objects is replicated. To provide fault tolerance for your files, you must mirror or duplex your hard disks and enable the Transaction Tracking System (note that TTS must be enabled for NDS to work). For more information, refer to the NetWare 4.0 documentation.
Faster Access Across a WAN Link. If users currently use a WAN link to access particular Directory information, you can decrease access time and WAN traffic by placing a replica containing the needed information on a server that users can access locally. Figure 10 shows an example of this.
Figure 10: Example of providing faster information access through placement of partition replicas.
Distributing replicas among servers on the network allows quick and reliable access, as information will be retrieved from the nearest available server containing the specified information.
Types of NDS Replicas. The three types of NDS replicas are:
Master
Read/Write
Read Only
Although many replicas of a partition can exist in the Directory, there can be only one Master replica of each partition. The Master replica is special in that it is used to change the structure of the Directory in relation to that specific partition.
You can create a new partition in a Directory database only from the Master replica. Use the Partition Manager tool (GUI utility) or the PARTMGR (text utility) to manage all partitions and replicas.
(For more information about default replication and its possible limitations, see the "Planning for NetWare 4.0 Installation, Server Migration, and Coexistence" AppNote in this issue.)
Bindery Compatibility
For compatibility with bindery-based utilities and clients that may coexist with NDS on the network, NetWare 4.0 provides bindery emulation. This feature also allows NetWare 3.x and 2.x servers to be on the same network with NetWare 4.0 servers running NDS.
With bindery emulation, NDS imitates a flat structure for leaf objects within an Organization or Organizational Unit object. Thus, when bindery emulation is enabled, all objects within the specified container can be accessed by both NDS objects and bindery-based servers and clients. Bindery emulation applies only to leaf objects in the specified container object.
The container object where bindery emulation is set is called the bindery context. Every time you install a NetWare 4.0 server into the Directory tree, a NetWare server object is created for that server in the specified container object. By default, bindery emulation is enabled when you install the server, and the server's bindery context is automatically set for that container object. (You can change the bindery context by using the SET BINDERY CONTEXT server utility with the appropriate parameters.)
Figure 11 illustrates bindery emulation in a Directory tree when the bindery context is enabled on an Organizational Unit object.
Figure 11: Through bindery emulation, NetWare 4.0 imitates a flat structure for all leaf objects within a container.
On each new server that you install into an existing bindery context, NetWare (by default) stores a Read/Write replica of the partition that the bindery context is located in. When you install a server into a new context, a Master replica is stored on that server by default.
Although bindery emulation is enabled by default during NetWare 4.0 installation, you can disable it by entering "SET BINDERY CONTEXT =" (with no parameters) at the server console.
Note: You cannot disable dynamic bindery emulation. The dynamic objects are always available unless the "bindery" is closed through bindery emulation.
Bindery emulation is server-centric. If a client does a bindery login, the login script comes from the user's MAIL directory on the server the user is logging in to. Changes to the user's bindery login script will not be propagated to any other servers.
Directory Services-based client software is not yet available for Macintosh computers. Macintosh clients in a NetWare 4.0 network must log in under bindery emulation.
For more information about bindery emulation and its limitations, see the "Planning for NetWare 4.0 Installation, Server Migration, and Coexistence" AppNote in this issue.
Network Time Synchronization
NetWare 4.0 allows time synchronization between servers. Time synchronization is important to the operation of NDS, as it establishes the order of Directory events that take place.
Whenever an event occurs in the Directory, such as when an object is renamed or a password changed, NDS requests a time stamp. A time stamp is a unique code that includes the time an event took place and identification of the replica that initiated the event. Every NDS event is assigned a time stamp so that replicas can be updated in the proper order.
To enable time synchronization during the installation process, you need to specify the type of time server you are installing. You also need to specify the time zone your server resides in, as well as the Daylight Savings Time rules for your server.
During the NetWare 4.0 installation, you can choose the default setting, Single Reference (or Secondary, if this is not the first server installed in the Directory), to establish the type of time services the server will provide. Or, you can designate the server as a Reference, Primary, or Secondary time server. Each designation performs a particular time synchronization function (these are explained later in this section).
If you choose not to use the defaults, you must know which time server function to designate for the server you are installing in order to implement an effective time synchronization plan for your network.
Before you install NetWare 4.0, decide the following (based on your network topology and network time synchronization needs):
What type of time servers do you need?
Where should the various time servers be located on your networkin order to provide fault tolerance and keep network traffic (generated by time servers) to a minimum?
Once you decide on answers to these questions, provide your network time synchronization plan to all supervisors that will install NetWare 4.0 on servers within the network so they can designate the proper time synchronization function on each server they install.
Types of Time Servers
Below are definitions of the different types of time servers and their functions. Consider these carefully.
Secondary Time Server. A Secondary Time Server (STS) obtains the time from a Single Reference, Primary, or Reference time server and provides the time to clients (such as workstations or applications). A secondary time server does not vote to determine the correct network time.
If you have designated a server on the network as a Single Reference time server, designate all other servers on the network as Secondary time servers.
If you have designated several servers on the network as Primary or Reference time servers, then designate all other servers on the network as Secondary time servers. Have Secondary time servers contact Primary or Reference time servers that are physically close in order to keep network traffic between the time servers to a minimum.
For optimal time synchronization, require each Secondary time server to contact a Primary, Reference, or Single Reference time server with as few intervening routers and slow LAN segments as possible.
Primary Time Server. A Primary Time Server (PTS) synchronizes network time with at least one other Primary or Reference time server, and provides the time to Secondary time servers and clients. A PTS polls other Primary or Reference time servers, and then votes with them to synchronize the time.
Primary time servers adjust their internal clocks to synchronize with the decided on common network time. Because all Primary time servers adjust their clocks, network time may drift slightly during this process.
A PTS is used primarily on larger networks to increase fault tolerance by providing redundant paths for Secondary time servers. If a Primary time server goes down, the Secondary time server can get the time from an alternate Primary time server. On a large network, use at least one Primary time server for every 125 to 150 Secondary time servers.
Reference Time Server. A Reference Time Server (RTS) provides a time to which all other servers and clients synchronize. Reference time servers should be synchronized with an external time source, such as from a radio clock that receives time signals from the Naval Observatory or some other accurate time source.
An RTS polls other Primary or Reference time servers, then votes with them to synchronize the time. Because the Reference time server does not change its clock, the Primary time servers must reach consensus with the time provided by the Reference server.
An RTS is used when it is important to have a central point to control network time.
Note: Reference and Single Reference time servers are two distinctly different types of time servers. Do not confuse the two.
Single Reference Time Server. The Single Reference Time Server (SRTS) provides time to Secondary time servers and clients. When a Single Reference time server is used, it is the sole source of time for the entire network. The network supervisor sets the time on the Single Reference time server.
The SRTS can be used for all networks, regardless of size, but is primarily recommended for small networks. This is the default when installing NetWare 4.0.
Important: Because the Single Reference Time Server is the sole source of time on the network it is installed on, all other servers on the network must be able to contact it. When the Single Reference Time Server is used, you cannot have any Primary or Reference time servers on the network.
Single Reference, Reference, and Primary time servers are all time source servers. Time source servers provide time to the network. Secondary time servers do not provide time to the network; they only receive the time from a time source server and pass the received time along to clients.
SAP vs. Custom Configuration
Time source servers find each other by using one of two available methods: by using the Service Advertising Protocol (SAP), or by using a custom configuration.
Service Advertising Protocol Method. By default, all Single Reference, Primary, and Reference time servers use NetWare's Service Advertising Protocol (SAP) to announce their presence on the network:
Secondary time servers use the SAP information to find and choose a time server to get the network time from.
Primary and Reference time servers use the SAP information to find other servers to poll in order to determine the network time.
The SAP method allows for quick installation without regard to the network layout. It also allows quick reconfiguration if operating modes are changed or if new time servers are added to the network.
However, the SAP method also generates additional network traffic. This can create a problem in large networks where "test" servers come and go, especially if the test server is configured as a time source (Single Reference, Reference, or Primary time server). This may cause time to be disrupted. The larger the network, the more network traffic is generated by the time server SAP broadcasts.
Important: Bringing up a time source server in this environment can cause problems if you do not carefully set the server time. Never set a time source server's time to a future time. If anything, set the server's clock a minute or two behind the network synchronized time. If you do set a new time source server to a time in the future, no updates made on your network will be accepted. This can cause major problems. Using the Custom Configuration method provides some protection against this situation accidentally taking place.
Custom Configuration Method.
This method allows you to assign specific time source servers that a particular server should contact for time information or polling.
Using custom configuration also allows you to specify that a server should not listen for SAP information from other time source servers, nor should it advertise its presence using SAP. This eliminates nonessential network SAP traffic, as well as errors associated with accidental reconfiguration.
The custom configuration allows the network administrator to maintain complete control of the network time synchronization environment.
However, the custom configuration method requires more time for planning and installation. It is also more difficult to install or remove Single Reference, Primary, or Reference time servers from the network. Using this method, you must manually change the approved server list maintained on each server. However, this does provide you with a means of preventing accidental synchronization with a new server (see the Important under the SAP section above).
To Plan Your Tree
This AppNote has introduced the basic concepts necessary to understanding what NetWare Directory Services is, what NDS can offer in a NetWare 4.0 network, and what is involved in creating and managing a Directory tree.
More detailed information about the actual planning of your Directory tree is given in other AppNotes in this issue. The next Appnote, entitled "Planning a NetWare 4.0 Directory Tree," takes you through the actual planning process for small, medium-sized, and large networks.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.