LDAPWiki: EdirectoryContainmentRules

Containment Class Rules#

The following table shows the default classes that can contain other objects and the object types that they can contain. The container class domain can be contained by all previous container classes and can contain all these classes except for Tree Root.

Object Class	Contained Class
Tree Root	Country domain Organization
Country	domain Locality Organization
Locality	domain Locality Organization OrganizationalUnit
Organization	domain Locality OrganizationalUnit Leafobjects
OrganizationalUnit	domain Locality Organization OrganizationalUnit Leafobjects
domain	domain Country Locality Organization OrganizationalUnit Leafobjects

Containment Class Inheritance for Leaf Objects#

Most leaf classes and noneffective classes in the operational schema are contained by the domain, Organization, and Organizational Unit classes. The following table lists the exceptions.

Object Class	Classes Contained By	Class Defined For
Alias	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.
Partition	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.
Unknown	Special case	Any.

Noneffective (Abstract) classes#

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 (Structural) classes#

Effective classes can define containment for themselves and for subordinate 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.

NOTE: The object classes in the schema do not inherit anything from their containment classes, only from their Superior ObjectClasses.

Auxiliary classes#

Auxiliary classes cannot define containment.

Best Practice - Define Inclusive Containment#

If containment is defined for a class, make it as inclusive as possible (domain, locality, country, OU, O). If it is restricted, consider the reasons for doing so. Inclusive containment provides flexibility for a number of different configurations and makes your classes more adaptable.

LDIF Containment Flag X-NDS_CONTAINMENT #

The following example LDIF file adds the person objectClass to the schema:

version: 1
dn: cn=schema
changetype: add
objectClasses: ( 
   2.5.6.6 
   NAME ’person’ 
   DESC ’Standard ObjectClass’ 
   SUP ndsLoginProperties 
   STRUCTURAL 
   MUST (cn $ sn) 
   MAY (description $ seeAlso $ telephoneNumber $ fullName $ givenName $ initials $ uid $ userPassword) 
   X-NDS_NAMING (’cn’ ’uid’) 
   X-NDS_CONTAINMENT (’organization’ ’organizationalUnit’ ’domain’) 
   X-NDS_NAME ’Person’ 
   X-NDS_NOT_CONTAINER ’1’ 
   X-NDS_NONREMOVABLE ’1’
)

The X-NDS_CONTAINMENT line shows the containers that this ObjectClass maybe contained within.

More Information#

There might be more information for this subject on one of the following: