Containers and Leaves

Active Directory is a hierarchy of objects in which every object instance (except the root of the directory hierarchy) is contained by some other object. But the structure of this hierarchy is more flexible than a file system where you just have directories and files. Instead, there are rules (in the Active Directory Schema) that determine which object classes can contain instances of which other object classes. For example, the default schema definition of the User object class includes the Organizational-Unit and Container object classes as possible superiors (that is, possible parents or containers) of a User object instance. This means that an Organizational-Unit object can contain a User object, but a User object cannot contain another User object (unless the schema definition of the User class is changed).

Except for schema objects (that is, the classSchema or attributeSchema objects that define the classes and attributes that can exist in an Active Directory forest), any object in Active Directory may be a container. Specifically, any object class that appears in the possSuperiors or systemPossSuperiors attribute of an object class definition is potentially a container. To find out the possible superiors of a predefined object class, see the reference page for the class in the Active Directory Schema Reference of the Active Directory Reference. Programmatically, you can bind to the abstract schema and use the IADsClass::get_Containment or IADsClass::get_PossibleSuperiors methods to get the classes that a given class can contain or be contained by (see Reading the Abstract Schema). You can also read the possibleInferiors attribute of any object instance to determine the object classes that the object can contain. Note that possibleInferiors is a constructed attribute, which means it's calculated from the possSuperior/systemPossSuperiors values of the other class definitions and is not actually stored in the directory.

Notice that the Active Directory Schema defines a Container class. As you can see from the discussion above, an object does not have to be an instance of the Container class to be a container. There's also a Leaf class, and although subclasses of this class are typically not containers, there's no reason why they couldn't be.

Finally, you can set a flag on the display specifier associated with an object class to indicate that user interfaces should always display instances of the class as leaves rather than containers. This helps prevent the user interface from being cluttered by too many containers. For more information, see Viewing Containers as Leaf Nodes.