Classes are templates for storing information in Novell Directory Services (NDS). All NDS objects must belong to a class, which is defined by the following components:
Because classes are organized into an inheritance hierarchy, a class inherits flags and attributes from parent classes. The complete definition of a class is derived from the components of the class itself plus the components of all of the classes in the class's inheritance.
NDS Schema Manager displays a class's inheritance as an inverted hierarchy. The inheritance hierarchy is inverted because a class can inherit characteristics from multiple classes. However, parent classes are not recursive--that is, parent classes do not inherit attributes from their child classes.
In general, the classes at the top of the inheritance hierarchy provide general characteristics, and the classes at the bottom of the hierarchy are more specialized. Figure 1 shows the inheritance hierarchy of the standard schema that ships with NDS.
Because the Top class is the parent class of all other classes, the Top class has no parent class. The Top class is also unique because you cannot use it to define an NDS object. The Top class is used by the [Root] object in the NDS tree.
Classes are defined by the following flags. You can set only two flags when you create a class; NDS sets the other three flags.
If you do not set the Effective flag, the class is flagged as non-effective, which means it cannot be used to define NDS objects. A non-effective class is used to define information that can be used by a number of similar classes. Thus, a non-effective class is essentially a building block that defines information associated with various effective classes.
Structure rules determine how NDS objects are named and where they can reside in the NDS tree objects. A class's structure rules define the possible relationships between objects in the NDS tree. These structure rules can be inherited from a parent class or explicitly defined in the class itself.
Naming Attributes. An NDS object is identified by its own name and the name of the container objects in which the object resides. An NDS object's name is referred to as its partial name, or Relative Distinguished Name (RDN). An NDS object's naming attributes determine its RDN.
Structure rules control the formation of an NDS object's Distinguished Name (DN). An NDS object's RDN and the names of all of its parent objects form its complete name, or DN. However, in defining a class for an NDS object, you need to specify only the immediate parent object's class as a container class.
Each class should have one or more attributes designated as naming attributes. If you do not assign a naming attribute to a class, NDS sets the Ambiguous Naming flag.
A naming attribute must be a mandatory or optional attribute. If you select only an optional attribute as the naming attribute, the optional attribute becomes, in effect, a mandatory attribute.
A naming attribute may be multivalued and must follow NDS inheritance rules. For example, Organization objects are named using the Organization Name (O) attribute, which is the only attribute that can be used for an organization's RDN because O is the naming attribute. Some classes specify more than one naming attribute. For example, the Locality class is named by the Locality Name (L) attribute and the State or Province Name (S) attribute. Thus, an RDN for a Locality object might be L=Chicago+S=Illinois.
A naming attribute does not necessarily reflect the class to which an object belongs. Many classes, such as Computer, Server, and User are named by their Common Name (CN) attribute. In this case, the naming attribute itself does not indicate the class to which the NDS object belongs. However, the naming attribute might suggest the nature of the object.
On the other hand, some naming attributes are closely tied to specific classes. For example, the Country object is named by the Country Name (C) attribute.
Container Classes. Each class has a container list, which specifies where an object can reside in the NDS tree. An NDS object can be subordinate only to the NDS objects using classes in this container list. By limiting the possible location of an object in the NDS tree, a container list restricts the order and types of RDNs that appear in the object's DN.
Container lists control the structure of the NDS tree through inheritance properties and ensure that the NDS tree expands in a consistent and logical manner. For example, a Country (C) object can be subordinate only to the [Root] object in the NDS tree.
In addition to controlling the structure of the NDS tree, container lists must also be flexible enough to accommodate a variety of organizational situations. For example, in the relationship between the Organization and Locality classes, each class specifies the other as a container class. As a result, you can decide which hierarchical order best represents your company.
Attributes describe the data used to define an object in the NDS tree. A class organizes a group of attributes in a meaningful way and specifies matching rules and directives for retrieving data in the NDS tree.
Mandatory Attributes. Mandatory attributes are required. When you create an NDS object, you must assign a value to every mandatory attribute. A class's mandatory attributes are inherited from its parent classes.
Optional Attributes. Optional attributes are not required. When you create an NDS object, you are not required to assign a value to optional attributes. There is one exception, however: If an optional attribute has been selected as the naming attribute, you must assign this attribute a value.