The Hierarchical Directory Tree

NetWare Directory Services (NDS) was developed as a hierarchical design with multiple levels of organizational units, users, groups, and network resources. This hierarchical structure is referred to as the Directory tree. The Directory tree is formed by organizing objects in a multilevel structure.

NDS and the X.500 Specification

NetWare Directory Services is consistent with the emerging international standard, X.500. The X.500 specification was developed by the CCITT (Consultative Committee for Telegraphy and Telephony) to provide a standard method for organizing information that is accessed transparently on a global basis.

Information such as telephone directories, corporate organizational structures, and directories of available services are all accessible through products compatible with this specification.

Much of the current development for accessing services on the global internetwork is being done according to the X.500 specification.

Directory Schema

The NDS Directory tree is defined by a set of rules called the Directory schema. The schema defines the specific way information is stored in the Directory database.

The following information is defined by the schema:

Object classes. Provide the basis for all entries in an NDS database. The set of defined object classes is referred to as the base schema. For example, servers, users, and print queues are some of the base object classes defined by the base schema.
Attribute information. Describes the additional information an object can or must have associated with it. Attribute types (or properties) are defined within the schema by specific constraints and a specific syntax for their values.
Inheritance. Determines which objects inherit the properties and rights of other objects.
Naming. Determines the structure of the Directory tree, thus identifying and showing an object's reference name in the Directory tree.
Subordination. Determines the location of objects in the Directory tree.

For a complete list of the base object classes, as well as other Directory information, Appendix B for more information.

Directory Objects

Directory 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 Directory database contains three general types of objects.

[Root] object (Directory tree name)
Container objects
Leaf objects

The following figure illustrates the hierarchy of Directory objects in NetWare Directory Services. (The icons represent the objects as they appear in the NetWare Administrator graphical utility.) Please note that the AFP Server is not supported in NetWare Services.

Figure 2-1 Hierarchy of Directory Objects

These objects represent both physical and logical resources on the network, such as users and printers or groups and print queues.

Directory 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 actual printer itself.

This Directory tree structure has the tree growing upside down, starting with the name of the tree or [Root] object at the top of the tree and branching downward. Once the [Root] object is named, you reference that object by its given name.

The following figure illustrates how objects can be laid out to form the Directory tree.

Figure 2-2 Objects Used in a Directory Tree

The Directory tree name ([Root] object) is automatically placed at the top of the tree during installation. Branches of the Directory tree consist of container objects and all of the objects they hold. Container objects can hold other container objects. Leaf objects are at the ends of the branches and do not contain any other objects.

The following figure illustrates that the Directory tree is formed by container objects and leaf objects branching down from the tree name or [Root] object.

Figure 2-3 Objects Formed from [Root] in a Directory Tree

[Root] Object

The [Root] object represents the name of the Directory tree. It resides at the top of the tree and branches downward. Once the [Root] object is named, you reference that object by its given name.

The [Root] object can be created only by the NetWare Directory Services installation program, which automatically places it at the top of the tree. Once the [Root] object is named, it 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 Directory tree name or [Root] object can have trustees, and rights granted to these trustees flow down the tree. A trustee is an object that is granted rights to work with another NDS object or with components of the file system, such as directories or files. One example is the User object ADMIN, which is created automatically during installation.

By default, ADMIN receives a trustee assignment including the Supervisor right to the [Root] object of the Directory tree. This gives ADMIN all rights to all objects and properties in the tree. Thus, ADMIN is used to initially log in and set up the tree. See "User Object ADMIN" in chapter 3 for more information.

The [Root] object can also be a trustee. Most likely, however, you will not assign trustee rights to the [Root] object. If you do, every object in the tree has the same rights as the [Root] object by virtue of inheritance. In effect, you assign every user that logs in rights to the [Root] object. See "Security Equal To" in this chapter for more information.

Container Objects

Container objects hold (or contain) other Directory objects. Container objects are 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 objects in the Directory tree.

A container object that contains other Directory objects is known as a parent object.

There are four types of container objects, defined as follows:

Country (C) . The Country object designates the countries where your network resides and organizes other objects within the country. Country objects can be placed only immediately below the [Root] object and their names are limited to two characters.
Country objects are optional. They are typically used only if your organization spans multiple countries or if you must include a Country object to interact with other X.500 specification compliant directory services. For more information, see"NDS and the X.500 Specification" in this chapter.
You can use a Country object to designate the country where your organization headquarters reside or, if you have a multinational network, to designate each country that is part of your network.
Because of the following considerations, you should plan to use a Country object only if your environment requires one:
Country objects add an extra organizational level to the name of each object in your Directory tree. For more information, see"Context and Names" in this chapter.
Country objects require you to use typeful names instead of typeless names when referring to contexts within your Directory tree.
Locality (L). The Locality object designates the location where this portion of your network resides and organizes other objects within the location.
Locality objects are optional. You can use them to designate the region where your organization headquarters reside or, if you have a multinational network, to designate each area that is a part of your network.
Locality objects can reside under Country, Organization, and Organizational Unit objects. They can also hold Organization and Organizational Unit objects.
NOTE: The Locality object is not part of the NetWare default server installation. You can create a Locality object during the server installation.
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 object.
You can use an Organization object to designate a company, a division of a company, a university or college with various departments, a department with several project teams, etc.
Every Directory tree must contain at least one Organization object.
Organization objects must be placed directly below the [Root] object, unless a Country or Locality object is used.
Organizational Unit (OU) . An Organizational Unit object helps you organize leaf objects in the Directory tree. It allows you to set defaults in a login script and to create a user template for User objects you create in the Organizational Unit.
You can use an Organizational Unit object to designate a business unit within a company, a department within a division or university, a project team within a department, etc.
This object is optional. When used, Organizational Units must be placed directly below an Organization, another Organizational Unit, or a Locality object.

Leaf Objects

Directory leaf objects are objects that do not contain other objects. These represent actual network entities such as users, servers, printers, computers, etc.

You create leaf objects within a container object. The following figure lists the leaf objects you can create. (The icons represent the leaf objects as they appear in the NetWare Administrator graphical utility.) Please note that the AFP Server object is not supported in NetWare Services.

See appendix B for more information.

Object Properties

Each type of object (such as a User object, Organization object, or Profile object) has certain properties that hold information about that object. For example, a User object's properties include a login name, E-mail address, password restrictions, group memberships, etc. A Profile object's properties include profile name, login script, and volume.

Some objects require values for specific properties before setup of that object is complete. Other properties are optional and can be added later as the need arises.

The following figure shows the relationship between object, property, and value.

Figure 2-4 Title not available (Object Properties)

In many cases, you can enter more than one value for a property. For example, you could enter a home, mobile, and work telephone number for a User object.

NetWare utilities allow you to search for objects that have specific property values. For example, you could search for all users who have a certain area code in their telephone number. The utility returns a list of all the objects with that area code in their telephone number property.

You can also request information on a specific object. The utility searches only for that object, and you receive information on that object's properties, provided you have the appropriate access rights.

To make searching for an object property easier, you can enter information for the optional properties when you create objects. This information can help you track and manage those objects.

Also, if you create objects or assign property values using a consistent format, you can use the NetWare Administrator, NETADMIN, or NLIST utilities to search for objects or property values.

For example, you might want to search for all User objects at a certain location, such as building M1. You cannot easily list all objects located in building M1 if you have entered "Bldg. M1," "M1 Bldg," and "M-1" as values in the Location property of various User objects.

Standardizing the value for the Location property for all User objects at the site (such as M1, M2, and M3) makes it easier to search for objects located in each building.

Object and Property Rights

NetWare 4™ software uses four different categories 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 some access control to bindery objects in bindery-based NetWare networks. NetWare 4 replaces bindery control with NDS object and NDS property rights. These rights determine what you can do within the Directory tree.

Because the Directory tree is a hierarchical structure, rights assigned in the Directory tree flow down through the tree. This is an important concept to understand and consider when designing your Directory tree.

The concept of rights flowing down through the tree is referred to as inherited rights. This functionality is controlled by the Inherited Rights Filter (IRF). An IRF is a list of rights that can be assigned to objects in containers beneath a parent container within the tree hierarchy. It controls the rights that a trustee can inherit from container objects. See "Inherited Rights Filter, NDS Object" in Concepts for more information.

To allow you to better control access to NDS objects and their properties, object and property rights are assigned separately.

Object Rights

Rights that control access to an object as an entity are called object rights. Object rights control what trustees of an object can do with that object. Object rights do not allow the trustee to access information stored in that object's properties unless the trustee has the Supervisor object right, which includes the Supervisor property right.

The following table describes object rights you can assign to a trustee.




	NOTE: All object rights of a subordinate object can be blocked by an Inherited Rights Filter (IRF) initiating at the point where the object right is granted.

Table 2-2 Object Rights

Right	Description
Supervisor	Grants all rights to the object and to all its properties.
Browse	Grants the right to see the object in the Directory tree. Also allows a user performing a search to see the object if it matches the search value. (This is true only when comparing the base object class or Relative Distinguished Name; otherwise, the Compare right is required.)
Create	Grants the right to create a new object within a container object in the Directory tree. This right applies only to container objects, because leaf objects cannot contain other objects.
Delete	The Write right for all existing object properties is also needed to delete objects. Grants the right to delete an object from the Directory tree. However, a container object cannot be deleted unless all the objects in the container are deleted first.
Rename	Grants the right to change the Relative Distinguished Name of the object, in effect changing the naming property. This changes the object's Distinguished Name. See "Object Naming Rules" in this chapter..

Property Rights

To see the information in an object's properties, trustees must have the correct property rights. Property rights control access to each property of an object.

Keep in mind the distinction between object rights and property rights. While object rights control access to an object as an entity, property rights control access to the information stored as an object's property values. The only exception is the Supervisor object right. The Supervisor object right includes the Supervisor property right.

Property rights apply only to NDS object properties (and their values), not to the objects themselves. NDS allows you flexibility in deciding what property information others can access.

For example, if you include a telephone number as a property for a User object, you can prevent others from seeing the value associated with that property-that is, the actual telephone number-by using an Inherited Rights Filter to disable the Read right to that particular property (see "Inherited Rights Filter" in this chapter). At the same time, you can still allow the person to view other properties and their values, such as the user's address.

The following table describes property rights you can assign to a trustee.

Table 2-3 Property Rights

Right	Description
Add or Delete Self	This right is included in the Write right; that is, if the Write right is given, Add or Delete Self operations are also allowed. This right is only used for properties where your User object can be listed as a value, such as group membership lists or mailing lists. Allows you to add or remove yourself as a value of the property, but you cannot change any other values of the property.
Compare	Allows you to compare a value with the existing value of the property. The comparison can return True or False, but cannot give the value of the property.
Read	Allows you to read the values of the property. This right includes the Compare right; that is, if the Read right is given, Compare operations are also allowed.
Supervisor	Gives you all rights to the property. The Supervisor property right can be blocked with an Inherited Rights Filter. See "Inherited Rights Filter" in this chapter for more information.
Write	The Write right to the Access Control List (ACL) property is the same as giving the Supervisor right to the object—it allows you to grant rights. This right includes the Add or Delete Self right; that is, if the Write right is given, Add or Delete Self operations are also allowed. Allows you to add, change, or remove any values of the property.

Access Control List

The information about who can access object properties is stored in a property known as the Access Control List (ACL). An object's ACL lists all trustees of the object. The ACL property also stores the object's Inherited Rights Filter.

To modify a trustee's access to an object, you change the trustee's entry in the object's ACL. Only trustees with the Write right for the object's ACL property can change trustee assignments or the Inherited Rights Filter.

Each trustee listed in an ACL can have different rights to that object's properties. For example, if ten users are listed in a Modem object's ACL as trustees, each of those ten users can have different rights to that Modem object and to its properties. One trustee might have the Read right, another might have the Delete right, etc.

See "Access Control List (ACL)" in Concepts for more information.

Inherited Rights Filter

While trustee assignments grant access to an object, the Inherited Rights Filter (IRF) prevents rights from automatically flowing from a container object to the objects it contains.

In the Directory tree, a child object automatically receives, or inherits, rights granted to its parent objects. The IRF can be used to block any or all of these inherited rights so that no child objects receive them.

Through inheritance, every object and property in the Directory tree can have an Inherited Rights Filter.

See "Inherited Rights Filter, NDS Object" in Concepts for more information.

Security Equal To

The Security Equal To property lists other objects that you want a given object to have security equivalence to. The object is granted the same rights the objects in its list are granted, both to NDS objects and to files and directories.

Use the Security Equal To property to give a user access to the same information or rights another user has access to.

When a user is added to the membership list of a Group object or to the occupant list of an Organizational Role object, the Group or Organizational Role is listed in that user's Security Equal To list.

By using the Security Equal To property, you avoid having to review the whole directory structure and determine which rights need to be assigned to which directories, files, and objects.

See "Security Equivalence" in Concepts for more information.

Effective Rights

The combination of inherited rights, trustee assignments in an ACL, and the Security Equal To property are known as effective rights.

An object's effective rights control its access to another object and that object's properties.

See "Effective Rights" in Concepts for more information.