Objects that can contain other objects are called container objects or parent objects. Container objects are the branches of the NDS tree, are part of the Structure Rules of the schema, and provide a structure that is similar to a directory in a file system. Objects that cannot contain other objects are called noncontainer or leaf objects. Leaf objects represent the actual network resources that perform some function in the NDS tree, such as users, printers, modems, servers, or volumes.
The following topics contain additional information about containment classes:
For each object class, a list of containment classes specifies where an object of that class may appear in the hierarchical structure of the NDS tree. An object can be immediately subordinate to only those objects whose classes appear in the containment list of the object’s expanded class definition. An expanded class definition includes all the characteristics defined for the class plus all the characteristics that the class can inherit from super classes.
Effective classes can inherit containment classes from super classes only if the inheritance does not make containment ambiguous. If the inherited containment is ambiguous, the class must define containment. Class-defined containment overrides containment defined for super classes.
Effective classes are those object classes that can be used to create entries in the NDS database. Noneffective classes cannot be used to create entries and are used by the schema so that multiple object classes can inherit a common set of schema characteristics. Noneffective classes can have ambiguous containment.
Containment classes limit the possible locations of an object in the NDS tree, thus restricting the order and types of partial names that appear in the object’s complete name. Containment helps to ensure that the NDS tree expands in a consistent and logical fashion. For example, an Organization object can be either the topmost object of the NDS tree or subordinate to the Tree Root object. A User object can be subordinate to an Organization object but not to a Tree Root object. Before users can be added to an NDS tree, the tree must contain either an Organization object or an Organizational Unit object which are the containment classes for the User object.
While helping to control the structure of the NDS tree, containment classes must also be flexible enough to accommodate a variety of organizational situations. An example is the relationship between the Organization and Locality classes. Each class specifies the other as a containment class. This allows an administrator to decide which hierarchical order best represents the company’s organization.
The following table shows the classes that can contain other objects and the object types that they can contain.
Table 1-1 Containment Classes in the Base Schema
Object Class |
Contained Classes |
---|---|
Country domain Organization |
|
domain Locality Organization |
|
domain Locality Organization Organizational Unit |
|
domain Locality Organizational Unit Leaf objects |
|
domain Locality Organizational Unit Leaf objects |
|
domain Country Locality Organization Organizational Unit Leaf objects |
The ability for Country, Locality, Organization, and Organizational Unit objects to contain domain objects comes with the installation of NDS 8. The ability of domain objects to contain Country, Locality, Organization, and Organizational Unit objects does not come through installation. The schema must be expanded to this functionality with a schema option in DSRepair.
The following figure presents a graphical view of the NDS containment structure. This view shows the containment classes and the object classes that they can contain and that can contain them. Object classes that cannot contain other objects (leaf objects) are collectively shown as noncontainer classes. The object class Top is not shown in the graphical view because Top is used for schema hierarchy and inheritance but not for NDS tree hierarchy.
Figure 1-2 A Graphical View of NDS Containment
Tree Root, Organization, and Country are shown on the same level because they all can be the topmost object in the tree. Tree Root has arrows pointing to both Country and Organization because Country and Organization can be, but are not required to be, subordinate to Tree Root.
Lines that have arrows pointing up indicate that these objects can contain each other. For example, an Organizational Unit object can contain a Locality object, and a Locality object can contain an Organizational Unit object.
Objects with circular lines indicate that they can contain objects of the same type as themselves. For example, one Organizational Unit object can contain another Organizational Unit object.
The base schema in NDS 8 adds one new container object, domain. A domain can be contained by all the other containers in the base schema: Tree Root, Country, Organization, Locality, Organizational Unit, and domain. It can contain all the leaf objects that Organization Unit and Organization can.
The domain object can also contain all the other base container objects, except Tree Root. This containment is shown with a dotted red line with an arrow pointing up to these objects. The line is not solid because this functionality is not automatically added to the schema with an NDS 8 upgrade. This functionality must be added to the schema by running a schema option in DSRepair, and the other servers in the NDS tree must be running NDS 5.17, 6.01, or higher.
Most leaf classes and noneffective classes in the base schema are contained by the domain, Organization, and Organizational Unit classes. The following table lists the exceptions.
Table 1-2 Containmant of Leaf Objects
Object Class |
Classes Contained By |
Class Defined For |
---|---|---|
Special case |
Inherits containment from referenced object. Since an Alias can reference a container object, it can inherit the containment rules of the container object. |
|
Special case |
Inherits containment from the object that is the root object of the partition. In NDS 8, Partition becomes an Auxiliary class and no longer requires any containment rules. |
|
Special case |
Any. |
Noneffective classes cannot be used to create objects in NDS, but they are often used to define containment classes for other object classes to inherit. Effective classes can define containment for themselves and for subordinate classes.
The following figure is a graphical view of how the leaf objects obtain their containment classes. The arrows pointing up to the container objects indicate which object class declared the containment class. Arrows pointing down to a leaf object indicate the objects that inherit the containment classes. Effective classes are represented by shapes with solid lines and noneffective classes by shapes with dotted lines.
Figure 1-3 Graphical view of Leaf Objects and their Containment Classes
One effective object class is unique: Alias. It is shown at the bottom of the figure because Alias inherits its containment classes from the object that it references. Since all leaf objects have domain, Organization, and Organizational Unit as their containment classes, an Alias will usually inherit these containment classes. However, an Alias can reference a container class, and when it does, the Alias inherits the container’s containment classes.
The Partition class is like the Alias class. Since any container class can be the root object in a partition, the Partition class inherits its containment classes from that root object.
The ndsLoginProperties class is not shown because it is a noneffective class, defines no containment classes, and inherits no containment class from its super class, Top. Thus, ndsLoginProperties is like Top in that they both do not affect containment classes of any objects in the NDS tree.
Containment classes create the hierarchy of the NDS tree and determine where an instance of an object can be created in the NDS tree. Once an instance of an object (or an entry) is created in the NDS tree, the entry inherits rights from its container objects and the container objects are part of the entry’s Distinguished Name. However, the object classes in the schema do not inherit anything from their containment classes.
Object classes can inherit containment definitions, but such inheritances come from the schema’s super class structure.