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?

thanks Brandon

Brandon,

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

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 example.

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.

Matt

On 1/17/07, Brandon McCombs bmccombs@ma.rr.com wrote:

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?

thanks Brandon

Brandon,

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

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 example.

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.

Matt

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?

thanks

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 implemented, yet.

Matt