[Date Prev][Date Next]
Re: object classes that can contain other objects
On 1/17/07, Brandon McCombs <firstname.lastname@example.org> wrote:
> On 1/15/07, Brandon McCombs <email@example.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
For example, with the default schema, can I create an instance of an
inetOrgPerson underneath an organizationalPerson entry as opposed to the
Yes, you should be able to create an inetOrgPerson entry under an
organizationalPerson entry. There aren't any rules that prevent this
sort of thing.
Kurt pointed out DIT structure rules in his initial post. DIT
structure rules do what you are talking about, but they are not