DIT structure rules apply not only to standard entries as demonstrated in the
previous section, but also to subentries -- entries that bear the subentry
STRUCTURAL class defined in
Section 2.4 of RFC 3672.
In cases where a directory server employs DIT structure rules in addition
to collective attributes, it is necessary to implement a new dITStructureRules
definition: one that enforces a suitable RDN attribute type (such as cn)
for subentries, while taking into account the superior structure rule(s) involved.
To begin, as was done in the previous section, a nameForms definition is required first.
nameForms: ( 1.3.6.1.4.1.56521.999.2.7.5
NAME 'subentryForm'
OC subentry
MUST cn )Here, we are stating that any entry bearing the subentry
STRUCTURAL class MUST ONLY utilize the cn attribute type for
its RDN, as it represents the most common naming strategy for subentries.
Next, we need to create the DIT structure rule, but first we need to identify the appropriate superior integer identifiers for the SUP clause.
Determining these identifiers is a simple matter. First off, subentries are never
created below entries that are not parents themselves (or expected to be parents). In
the spirit of the previous section, this allows us to strike two (2) candidates from
the list: inetOrgPerson entries (accounts), and groupOfNames
entries (groups).
This leaves domain (20) and organizationalUnit
(21) entries. Thus:
dITStructureRules: ( 24
NAME 'subentryStructure'
FORM subentryForm
SUP ( 20 21 ) )Because subentries themselves do not allow for subordinate entries, we need not worry about rule recursion in this instance.
When implemented (and with respect to the parameters of the previous subsection),
the definitions defined in this subsection will correctly allow for the addition of
entries bearing the subentry STRUCTURAL class, thus allowing use
of dependent constructs, such as collective attributes, to be used unfettered.
