X.500 Standard status
X.509 Related activities
How to be involved
Tutorial section 1
Tutorial section 2
Other PKI organizations
As discussed in the section on object classes, an entry is created based on one and only one structural object class and possibly one or more auxiliary object classes. The structural object class gives the basic definition of what attribute types shall and what attribute types may be represented in the entry.
If more attributes are required than those specified by the structural object class, additional attributes can be included by use of auxiliary object classes as also explained in the section on object classes. However, before this can be done, a content rule has to be associated with the structural object class.
The content rule includes the following specifications:
Content rules for different structural object classes are stored in a multi-valued operational attribute called dITContentRules. This attribute is stored in the subentry for the subschema specific administrative area. This is illustrated in the figure, where each row in the figure is an attribute value that holds the specification of a content rule. Such a value is a sequence of data items each specifying an aspect of the content rule.
An entry may have an operational attribute (subschemaSubentry) that point to the subentry that holds the content rules. From the entry is therefore possible to access the content rule for that entry. An implementation may provide other means for locating subentries made available to the local administrator.
All the above are mechanisms that to some degree are handled automatically by the implementation. However, the administrator has in some way to define the content rules to the system.
According to the X.500 specifications, auxiliary object classes included in a structure rule do not necessarily have to be reflected when entries are created according to that structure rule. However, administrators should be aware that when adding entries using local administrative tools, the implementation might take object class information from the applicable structure rule instead of requiring the administrator to supply that information for each individual entry. If that is the case, auxiliary object classes may specify some mandatory attribute types not relevant for all entries. When loading such entries, the load will fail. For the same reason it advisable that auxiliary object class should not specify any mandatory attribute types, but to define all attribute types as optional.
When an administrator is to include attribute types, e.g. locally defined attribute types that are not reflected by existing object classes, then there are two choices:
It is recommended to define a new auxiliary object class.
It may be considered cumbersome to define new auxiliary object classes just to include a few new special attributes required in special situation, and it may therefore be tempting to tamper with existing specifications to avoid this. Typically, a directory implementation has not hard-coded the object class and attribute type definitions, but has provided them in a definition file. Such a definition file could in principle be changed without having the system objecting.
Such tampering should not be done!
Such tampering will impede interworking with other DMDs and may cause much reworking later to accomplish such an interworking. More details on this are given in the following: