NetWare Directory Services, Part One

One of the most eagerly awaited aspects of NetWare 4.x is its directory services scheme. It's also one of the most complex to describe. This discussion is necessarily a simplification of NetWare Directory Services (NDS). Since NDS comes from Novell, the NetWare 4.x documentation should be considered the definitive source on the subject. If you're installing NetWare 4.x, follow the 4.x documentation for specifics on NDS. For those wondering whether to make the jump to NetWare 4.x (and hence don't yet have the documentation), here's a brief overview of NDS.

Beyond The Bindery

Versions of NetWare prior to 4.0 built and maintained , on each file server, a special database called the bindery to store information on each user, group , or other object the file server had to track. For example, when the supervisor of a NetWare 3.11 file server wants to give a new user access to the server, he or she uses Novell's SYSCON utility to create a new user, entering a new user name (the account name for that user) and telling SYSCON whether or not a password is required.

The fact that each NetWare file server, running NetWare versions prior to 4.0, maintains its own bindery can create a lot of administrative work in organizations with dozens or hundreds of file servers. If a supervisor wants to give a new user access to, say, six servers, he or she must log on to each server and follow the preceding steps. Wouldn't it be nice to be able to say simply: "Here's the account name for this user. Give her access to these six file servers"? What's needed is some sort of "global" directory, so users and other objects are known to the entire internetwork rather than to a specific file server. NetWare Directory Services has that orientation.

In the NetWare 4.0 Concepts manual, Novell defines NetWare Directory Services as a " global, distributed, replicated database that maintains information about, and provides access to, every resource on the network." The key words are global, distributed, and replicated. Global refers to the fact that entries in the NetWare Directory database are known to the entire network. Distributed means that portions of the NetWare Directory are replicated (a copy is kept) on various file servers. This setup ensures that, in the event of a file server crash, the NetWare Directory isn't lost. It also means that users won't be locked out of the network because one file server happens to be turned off or is otherwise inaccessible (if a wide-area link is down, for example).

While the bindery is a simple flat-file database, the newer NetWare Directory is hierarchical; it's logically organized in an inverted tree structure, with all key components branching out from the "root" at the top of the tree (see Figure 1). This tree structure also closely mimics the organizational charts of most companies, which permits network administrators to build a structure of account names that closely matches the company's organizational chart.

Figure 1: As the dotted lines imply, a directory tree is extensible in breadth and depth.

Cataloging Resources

Network resources such as users, groups, printers, print queues, and volumes , are cataloged in the Directory as objects. Objects can be either physical or logical. Some examples of physical objects are users and printers. Groups and print queues are logical objects.

Objects can also be classified in another way: as container objects or leaf objects. Container objects are so named because they contain one or more other objects. Leaf objects don't contain any other objects; they're at the ends of branches, hence the "leaf" designation. Some examples of leaf objects include users, NetWare servers, volumes, and print queues.

An object consists of categories of information, called properties . Some properties of a user object, for example, include login name, password restrictions, and group membership.

The container objects can be categorized into three types: the country object, the organization object, and the organizational unit. The country object is the highest-level container object ( next to the root object) in the Directory (see Figure 2). The country object is optional, and it is not automatically created as part of the NetWare 4.x default server installation.

Figure 2: The relationship between various object types.

The organization object is one level below the country object (if country objects are used; otherwise it's directly below the root object). There must be at least one organization object in the directory-it's not optional. You would typically use the organization object to designate your company or organization (university or government agency, for example).

A level below the organization object is the organizational unit. It can be used to represent a division within your company or organization. There can be several levels of organizational units, so you can use them to designate departments or workgroups.

Note that there can be only one level of country objects (if you use country objects) and one level of organization objects. As mentioned earlier, there can be several levels of organizational unit objects.

Figure 3 shows part of a directory tree for a hypothetical organization, the Acme Auto Company. In this example, the country object is not used, so the organization object occupies the level just below the root object. Acme has operations in Germany and the United States, and the creators of the directory tree chose to use two organization objects: Acme_Germany and Acme_US. Acme_US has three divisions-Engineering, Sales, and Accounting-so organizational unit objects are used to represent them.

Figure 3: A portion of the NDS directory tree for Acme Auto Co.

Each organizational unit can have subgroups. For example, in the figure, Sales is divided into truck and car departments, so another level of organizational unit objects is used for these. Finally, we get to the users in these departments, who are represented by leaf objects. Each user's login name, which on many NetWare networks is made up of the user's first initial and last name, is listed.

An object's position within the directory tree is known as its context. In Figure 3, the context for user John Doe is TRUCK.SALES.ACME_US. Most leaf objects have a common name, and for user objects, the common name is the login name.

What Novell refers to as an object's complete name is formed by concatenating the object's common name with its context. In our example, John Doe's complete name is JDOE.TRUCK.SALES.ACME_US.

This tutorial, number 67, by Alan Frank, was originally published in the March 1994 issue of LAN Magazine/Network Magazine.