Appendix A - LDAP: ObjectClass Hierarchy Definitions

Many documents insist that LDIF files that describe a DIT and its entries define the whole ObjectClass hierarchy as in the LDIF fragment below:

dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: jimbob@example.com
ou: sales
....

The objectclass definition includes any objectclass hierarchy (its SUPerior objectcClass). All the schemas, which contain ALL the objectclasses in the hierarchy, must be visible to the LDAP server (in OpenLDAP using the include directives of slapd.conf). The LDAP server can, in theory, figure the hierarchy stuff out itself and certainly a lot faster that you can type it. The above definition can also confuse by apparently having more than one STRUCTURAL Objectclass in an entry - see additional notes on ObjectClass Inheritance.

In practice OpenLDAP 2.x+ version can process the objectclass hierarchy so either the LDIF above or the following LDIF fragment works perfectly including being able to access both objectclasses and attributes that are contained in the SUPerior hierarchy, for instance you can access street which is an attribute of organizationalPerson:

dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: jimbob@example.com
ou: sales
....

Caution: If you export the last definition from OpenLDAP it will return precisely what you defined in the original LDIF that created the entries. Not all LDAP servers will process the object hierarchy automatically. If you then try to load this exported LDIF into a non-hierarchy processing LDAP server it may not produce the desired results. If you use only LDAP severs that support hierarchical processing (for example only OpenLDAP) then you can save some typing else...