Understanding NetWare Directory Structures

A database's architecture determines the naming and organization of network resources and dictates the kinds of features the directory or domain service offers. The architectural foundation of a directory or domain service is the namespace structure, which determines how the database is organized. Namespaces have one of two types of organizational structures: hierarchical or flat.

Within the Novell family are representatives of each of these structures. The bindery database of NetWare 3.x and earlier used a flat structure, whereas the NDS database of NetWare 4.x (and later versions) uses a hierarchical structure. In the following sections, you will learn about each of these structures.

Reviewing the Bindery Structure

The bindery is a flat network database that the early versions of NetWare 3.x and NetWare 2.x used for the primary purpose of security and access control. When we say that the bindery files are flat , that means the entries in the bindery do not have an explicit relationship to any of the other entries. Although you could add users to groups, unless you looked up each specific user, the relationship was not apparent. The bindery is server-centric, which means that each file server contains and maintains a unique bindery that contains settings for the printers, usernames, object IDs, passwords, and security. In this structure, if a user needs access to two bindery servers, that same user must have one account on each server, because different servers do not communicate with each other to exchange security information. The NetWare Name Service (NSS) utility synchronizes user account and user security information between multiple servers to try to create a semblance of a hierarchical structure prior to the release of NDS.

In a bindery structure, each entity on the network, such as a user, printer, or workgroup, constitutes a single object definition in the database. Each object connects directly to the root directory of the server, keeping in mind that the root does not branch beyond itself and the list of objects it contains. Figure 33.1 provides graphical representation of the bindery structure. In the bindery, the network supervisor can design, organize, and secure the network environment based on each entity's requirements. The following three components make up the bindery:

• Objects ” These represent any physical or logical entities, such as users, user groups, workgroups, file servers, print servers, or any other entity that has an assigned name in the database.

• Properties ” The characteristics of each bindery object. This includes passwords, account restrictions, account balances , internetwork addresses, lists of authorized clients , and group members .

• Property data sets ” These represent the type of data stored in the bindery. The data type can be text, number, table, date/time, network address, and stream.

Figure 33.1. The Novell bindery has a flat structure.

Reviewing the NetWare Directory Service Structure

Like the bindery, NDS is an informational directory of objects that represent the resources on the network. These objects, just as in the bindery, are users, groups, printers, servers, and other organizational units. However, unlike the bindery, the objects are represented in a hierarchical structure, meaning that you have one root structure and then branches from the root that contain other branches and leaves . Compare this to the flat file structure of the bindery. NDS shows you the relationships among different objects in the directory.

Note

Chapter 31, "Using the Active Directory," covers Microsoft's implementation of directory services based on LDAP, and Chapter 34, "Expanding and Enhancing NDS: NetWare's eDirectory," explores the newest version of NetWare's directory, as well as some of the new features found in NetWare 6 that are integrated with the eDirectory.

NDS uses a hierarchical tree structure that organizes objects in a multilevel, object-oriented, directory tree, loosely based on the X.500 standard developed by ISO. An X.500-standard directory structure looks like an upside-down tree (thus the nomenclature directory tree ), with the trunk at the top and the branches extending below it. X.500 defines users and resources as objects and uniquely identifies them by their locations and a distinguished name. Figure 33.2 illustrates the NDS structure.

Figure 33.2. The Novell Directory Service is a hierarchical structure based upon the X.500 standard.

For more on the X.500 standard protocols and its replacements , see Appendix D, "The Lightweight Directory Access Protocol."

However, the directory does not force you to conform to a hierarchical structure. Underneath a single organization (O), you can define all objects into a flat structure, something like a super-bindery. The directory hierarchy enables you to take advantage of the natural organization of information.

Most of the time, an organization will configure its directory tree according to the way users access and use company resources. In this way, NDS acts as a repository of information based on the specific needs of the organization. Because this method makes resources easy to locate, use, and manage, network administrators can log in as the Admin user from any workstation on the network and manage the entire directory tree.

In addition, whether your NDS servers are running NetWare, Unix, or Windows, NDS can keep all resources in the same directory tree. That means you do not need to access a specific server or domain to create objects, grant rights, change passwords, or manage applications. This open access is available due, in large part, to a Novell product that allows a single network login across multiple platforms.

NDS maintains information about every resource on the network and stores this information in a single, logical database that lets the users see a global view of all services and resources on the network. In an NDS environment, users log in to a multiserver network and view it as a single system instead of as a collection of individual servers. The most important benefit of this scenario is that users can access network services and resources through a single login, regardless of where the user or the resource is located on the network. This access also is conditional on whether the user has the requisite rights to use that resource.

Objects in the NDS Directory Tree

Resources you will see in an NDS environment include users, groups, printers, volumes , applications, fax servers, computers, and nearly any other device or application that attaches to the network. When you log in, you will see one global view of the entire network and all its resources, as opposed to seeing a group of servers, as you would with the bindery.

The network resources appear in the NDS directory tree as one of several types of objects, called object classes, which have distinct properties. The schema defines the containment rules for object classes and their properties. The main types are leaf objects and container objects. Table 33.1 defines what each type of directory structure can contain.

Table 33.1. NDS Object Composition

Directory Object	Object Composition
[Root]	Contains Country, Organization, and Alias objects.
Country	Contains Organization, Application, and Alias objects.
Organization	Contains Organizational Units and Leaf objects.
Organizational Unit	Contains other Organizational Units and Leaf objects.
Leaf	Cannot contain any other objects.

Figure 33.3 shows you the NDS object containment. The following are the container objects you will see in NDS:

• [Root] ” Located at the topmost level of the directory tree, which allows trustee assignments that grant rights to the entire directory tree.

• Country objects ” Enable you to perform one task on one container object, and those changes will apply to all objects within that container.

• Organization objects ” Usually are the first container class under [Root] and typically bear your company name. Small companies can simplify management by having all other objects directly under the Organization object.

• Organizational Units ” Fall under the Organization to represent separate geographic or functional divisions. You also can create organizational units under other organizational units to further subdivide the tree.

Figure 33.3. NDS object containers can be the root, as well as Country objects, Organization objects, and Organizational Units.

Leaf objects represent actual network resources, such as users, groups, file servers, printers, and network applications. The following are the Leaf object classes:

• Alias objects ” Provide a quick way to access objects in another context. Alias objects do not contain any other objects, but point to other permitted objects in another context besides the user's own.

• Bindery objects ” Represent objects that an upgrade or migration utility has placed in the directory. NDS uses them only to provide backward compatibility with bindery-oriented utilities.

• Bindery Queue objects ” Represent a queue that an upgrade or migration utility has placed in the directory tree. NDS uses them only to provide backward compatibility with bindery-oriented utilities.

• Computer objects ” Represent a nonserver computer on the network, such as a client workstation or a router. This object stores information about the computer, such as its network address, serial number, or the person to whom you have assigned the computer.

• Directory Map objects ” Represent a particular directory in the file system. They can be useful in login scripts by pointing to directories that contain applications or other frequently used files. If you want to avoid making changes to many login scripts as application locations change, you can create a Directory Map object, reference it in the login script, and change it when the application location changes.

• Group objects ” Assign a name to a list of User objects that are located anywhere in the directory tree. Use a Group object to assign rights to a group rather than to individual users. The individuals that belong to a group will inherit the rights that you assign to that Group object, no matter their location in the directory tree.

• NetWare Server objects ” Represent a network server running NetWare. Whenever you install a NetWare server in the tree, NDS automatically creates a NetWare Server object. This object stores information about the server, including the following: the server's location on the wire, the server's physical location, and the different services that the server provides.

• Organizational Role objects ” Define a position or role within an organization, such as a department manager or vice president of sales. You can assign any User object as an occupant of the Organizational Role object, and the occupants inherit the same rights granted to the Organizational Role object.

• Print Queue objects ” Represent a print queue on the network. You must create a Print Queue object for every print queue on the network.

• Print Server objects ” Represent a network print server. You must create a Print Server object for every print server on the network.

• Printer objects ” Represent a physical printing device on the network. You must create a Printer object for every printer on the network.

• Profile objects ” Contain a profile script (a type of login script) that appears as part of the User object properties and executes whenever a User object logs in to the network. The Profile object executes after the system login script, but before the user login script. You can 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. In addition, Profile objects will suit any users who are a subset of users in the same container.

• Unknown objects ” Represent an NDS object that has been invalidated and cannot be identified as belonging to any other object class.

• User objects ” Represent a person who logs in and uses the network. You must create a User object for every network user. When you create a User object, you can create a file-system home directory for that user that includes default rights assignments. You also can determine which default rights you want the User object to have, and customize a USER_TEMPLATE object, which you will assign to new users.

• Volume objects ” Represent a physical volume on the network. The INSTALL program automatically creates a Volume object for every physical volume on a server at installation time. The properties of the Volume object store information about the NetWare server where the physical volume is located. It also specifies which name the operating system gave the server after initializing the volume during installation (such as SYS). If you create a Volume object during installation, NDS places this information in the properties of the Volume object by default. NDS also uses Volume object properties to map drives .

• Container objects ” Organize network resources into branches and can contain Leaf objects and other Container objects in the directory tree. Container objects enable you to manage other objects in sets, rather than individually.

Bindery Services

The dilemma for many administrators, after they upgrade to an NDS operating system, is how they can tie in their legacy bindery system. For this express purpose, Novell provides bindery services, which enable NDS to emulate a bindery database.

Bindery services provide NDS-based networks (NetWare 4.x and NetWare 5.x) with backward compatibility to NetWare versions that used the bindery. This enables clients that are using older software to access the network. In addition, when you have enabled bindery services, NDS objects, bindery-based servers, and client workstations can access all objects within the specified container's bindery context.

Bindery services do this by simulating a flat (nonhierarchical) structure for the objects within a set of Organization (O) and Organizational Unit (OU) objects, representing only the leaf objects of the container. Consequently, bindery service users have limitations that other NDS users do not have.

Bindery Context

The bindery context is the Container object in which bindery services are set. It appears as a branch of the NDS tree that serves as a simulated bindery and allows bindery-based servers, clients, and utilities to coexist on an NDS network.

In early versions of NetWare, you could set the bindery context in only one container (Organization or Organizational Unit) within the directory tree, and all bindery objects had to be located in that container. However, later NetWare versions have a bindery context path that allows multiple containers to contain bindery objects ”as many as 16 bindery contexts for each server. In addition, recent NetWare versions support NetWare Loadable Module (NLM) programs that rely on bindery services to access objects in multiple containers.

However, you might experience problems when you use a bindery context path. Although you cannot have more than one object of the same name in the same container, you can have objects with the same name in the different containers of a bindery context path. The problem is that users see only the objects in the first container of a path. The visible name overrides other objects of the same name in the other containers, regardless of whether these objects are of the same type. The only way to prevent this is to avoid having objects of the same name in different containers if these containers are in the same bindery context path.

When you install any NetWare server into the directory tree, the operating system automatically creates a NetWare Server object in the Container object. Figure 33.4 illustrates a bindery context in an NDS structure. By default, NetWare activates bindery services and sets the bindery context for that container object.

Figure 33.4. Bindery services let you establish a bindery context within an NDS structure.

Bindery Emulation Drawbacks

Because bindery emulation is necessary in some networks, you must understand how it affects overall network use and performance on an NDS directory.

For every NetWare server that must perform bindery emulation, you must have a replica of the NDS partition that contains the network entities that are requesting bindery access. In this case, servers that normally would not have required a replica now must have one to maintain the server-centric bindery database.

Because this means that the replica ring is larger than it would have otherwise been, your network now has more traffic as these servers synchronize. Additionally, events such as user login cause servers to verify authentication with other servers in the replica ring, which can cause significant delays. This is especially true when many users are doing the same tasks at once, such as initial login first thing in the morning.

Bindery emulation also leaves less bandwidth available for data transmission. This means that the server can delay user requests while the servers perform functions they otherwise could have avoided if the network was strictly NDS.

In addition, server processor use is a factor where bindery use is prevalent . Although bindery is single-threaded, NDS is multithreaded. This means that every time an application, or the operating system, initiates an execution path, it must wait in a queue until the CPU can process that command. Because bindery is single-threaded, only one thread handles all the bindery requests made to a server. While the CPU handles another thread, it puts all bindery requests on hold. When the CPU does address the bindery thread, it may monopolize the CPU while other vital functions are on hold. In comparison, each NDS request creates its own thread that the CPU can handle separately with less risk of CPU monopoly.

Contrasting and Comparing Bindery and NDS

Although Novell had a step in the right direction with its bindery database, the bindery structure had a lot of room for improvement. In this section the attributes of the bindery will be compared to the new and improved attributes of NDS. Additionally, you'll see how NDS picks up where bindery left off to form a more complete and efficient database structure.

Most modern networks contain multiple servers. This makes managing the network on a server-by-server basis time-consuming , often redundant, and not very efficient, especially when it comes to fault tolerance, network security, and data synchronization. In addition to the administration workload, network performance also suffers. Table 33.2 outlines the most important differences between the bindery and NDS, and the following sections provide details on those differences.

Table 33.2. Comparing Bindery and NDS

Feature	Bindery	NDS
Group Accounts	Users must be assigned on each server	Group assignments are networkwide
Logical Structure	Flat	Hierarchical
Network Printing	Has no friendly printer map	Provides user-friendly access to network printers
Network Volumes	On the local server only	Volumes extend across the network as global objects
Partitions	None	Distributed database
Queues	Only local objects will queue	Queues form for systemwide objects
Replication	Does not replicate	Replicates partitions
Synchronization	No replicas to synchronize	Synchronizes replicas
Trustees	On the local server only	Global objects
User Accounts	Users must have separate accounts on each server	Users have one global account for the network
User Login and Authentication	Users must have one password per server	Sponsors networkwide authentication

Administration

In a bindery environment, the administrator must maintain separate servers that are, in effect, their own complete network environment. This includes setting up specific user accounts on specific servers so that the user could access the resources there. Therefore, if a user needs access to resources on five file servers, the administrator must create an account for that user on each of the five file servers. In addition, the administrator also must synchronize individual files and relationships between the servers.

NDS eliminates this redundant administration by requiring only one user account per user for the entire network. In addition, NDS also does away with the redundant administration that is typical in multiserver, non-NDS environments.

Centralized Login

In a bindery environment, users log in to their own context and must access new contexts on other servers by signing in to those servers as well. This means that each user must have a distinct account on each server. In addition, the bindery maintains Login scripts separately on each server, instead of centrally , meaning that the administrator must update and maintain those scripts separately.

NDS requires only one user account per user for the entire network. This simplifies life for ordinary users, because they need only one login, and one password, for all subsequent security authentications during the network session.

Directory Structure

The most distinctive difference between bindery and NDS is the directory structure. In the bindery, you could see only the main organization and then all the individual components of that organization, which branched directly off from the root directory. If you looked at the directory tree in this scenario, you could not tell the vice president of the company from the printer, except by name.

Whereas the bindery was very limited in how it could represent divisions, departments, and groups, an NDS tree can encompass an entire network. In so doing, it can closely resemble the corporate structure, wherein a top-level root branches into various functional or geographic departments or groupings.

As a corporation grows, the number and size of its departments grow and are further subdivided, in addition to the number of network resources (that is, users, printers, and servers) and the relative entries in the NDS database. NDS can represent this growth by adding and expanding the administrative designators, such as organization and organizational unit containers corresponding to the actual organizational charting.

Object Recognition

In addition to a limited organization structure, the bindery recognizes only the following object types:

• User

• Group

• Queue

• Print Server

• Bindery objects

This limits the way clients can use the directory service because they are limited to those objects, and administrators are limited in their ability to alter and improve user access to network resources. Administrators are so limited because the bindery objects are limited to the server on which they are located, as opposed to the NDS security structure of network access. In addition, administrators cannot use any new features and products by Novell or third-party companies that leverage the directory to create new objects or add new attributes to existing ones.

In contrast, NDS can recognize a full range of directory objects, which the structure breaks down into logical sequence and division. Divisions in an NDS tree increase the efficiency and responsiveness of NDS ”particularly for users in branch offices ”as well as decreasing server load and making the tree more manageable. NDS, therefore, is a distributable database that the administrator can place where he or she sees fit.

Access to Resources

In a non-NDS environment, users must know on which specific server the desired resource resides. Even after yet another login, that user must also have access rights to both the server and the resource. The bindery resources are server-centric and NDS resources are network-centric. The bindery resource is made available to NDS users by setting a bindery context so that the resource can be accessed from the NDS. You can log in totally as a bindery user and you will have access only to the resources in the bindery context and can use only bindery tools such as SYSCON and PCONSOLE.

NDS allows users to access a more global view in which objects exist individually and can access other entities, regardless of physical or logical location. The NDS database resides on a server, or servers, that users can access from anywhere on the network without having to know on which specific server the resource resides.

Partitions

Although the bindery does not support partitions, NDS can break the database into separate pieces at the container level to manage large numbers of network resources. When the operating system originally creates a directory tree, that tree has one partition. In this case, the NDS database exists in its entirety wherever it physically resides. However, network administrators can divide the tree into any number of smaller pieces to give logical structure to the partitions. One reason to partition the tree is to place that portion of the tree closer to the user. You would want to partition the NDS tree on a WAN and place the NDS objects closest to the users.

Replicas, Synchronization, and Fault Tolerance

Another feature that bindery does not support is replicas. You can set NDS to copy one server's partition of the directory database to other NetWare servers in the tree ”a process called replication . In this manner, NDS creates a distributed database system, employing a concept that is similar to disk mirroring.

Replication reduces possible data loss if the server holding the database fails. You can copy any partition onto any other server for fault tolerance. Three replicas of an NDS partition on the network should provide enough fault tolerance for almost any server failure scenario. However, you do not need to put replicas on all your NDS servers, because the servers on the network know which servers have replicas and which do not. If a client requests a server's resources, the network can check with the other servers that have replicas to authorize access. In this way, servers can be more efficient with their resources and do their specific, assigned tasks with less overhead.

NetWare 4.x servers with replicas participate in a replica ring, which should be no more than 10 servers and no fewer than 3 servers. All the servers in a replica ring automatically synchronize changes to the NDS database and update the partitions. The smaller the replica ring, the less time the servers spend synchronizing.

With NetWare 5, server replication no longer occurs within a replica ring or list as it has in the past. Transitive synchronization works through a migration agent server that checks the replica list and each target server's ReplicaUpto vector. If the source server's ReplicaUpto vector is more recent than a target server's vector, the source server does not need to synchronize with that target server. This procedure uses both the IPX and the IP protocols and reduces synchronization traffic to free up bandwidth.