[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: object classes that can contain other objects

TechnoSophos wrote:
On 1/15/07, Brandon McCombs <bmccombs@ma.rr.com> wrote:
Hello all,

Is there a published list somewhere or something in the schema that will
allow me to determine all object classes that are or are not able to
contain other objects?  For example, inetorgpersons, printers, and
ntusers are "leaf" nodes and therefore can never have anything below
them (as far as I know; maybe some specialized objects like policies may
be allowed to be under them).

Any pointers to information?



I'm interpreting your question a little differently than Kurt, in
hopes that one or the other of us is interpreting your question

You might want to read RFC 4512 to get a better idea for how object
classes work, particularly the sections on the types of object
classes. inetOrgPersons, printers, and ntusers are "leaf nodes" only
because they are structural object classes that have no subclasses. A
new object class could be defined (let's call it myCustomClass) that,
for example, had inetOrgPerson as its superior. Then the object class
attribute values for such an entry would look like this:

objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: myCustomPerson

But then there are auxiliary object classes that can be "mixed in"
with structural object classes. The simpleSecurityObject is an

The ditcontentrule directive in slapd.conf can be used to explicitly
set which auxiliary object classes an object of a particular
structural object class can have.


Does everything you say above still apply if I said that when I meant "leaf" nodes I meant with respect to the DIT and not to the schema structure itself?
For example, with the default schema, can I create an instance of an inetOrgPerson underneath an organizationalPerson entry as opposed to the usual organizationalUnit?