Appendix A - LDAP: Object Hierarchy Definitions

Many documents insist that the LDIF files that describe a DIT and its entries define the whole 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 its objectclass hierarchy. All the schemas, which MUST include 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.

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