Appendix A - LDAP: ObjectClass Inheritance

LDAP has many rules but one of the most basic is that an entry may have only one STRUCTURAL ObjectClass. Confusion can arise when it appears this rule is broken as illustrated below.

Note: Many documents insist that the LDIF files that create a DIT and its entries define the whole ObjectClass hierarchy as in the first LDIF fragment below, alternatively only the highest objectClass that is required (containing attributes that will be used) need be defined for most modern LDAP servers as shown in the second fragment which is functionally identical to the first(there are some implication from using this structure):

# explicit definition of all objectClasses used in the entry
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
title: super hero
...

# only the highest objectClass used in the entry
# need be defined for most modern LDAP systems
dn:cn=Jim Bob,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Jim Bob
sn: Bob
mail: jimbob@example.com
ou: sales
title: super hero
...

The ObjectClasses Person, organizationalPerson and inetOrgPerson are all STRUCTURAL (shown explicity defined in the first fragment, but implicit in the second fragment). We appear to have broken the rule than an entry can contain only one ObjectClass of the STRUCTURAL type.

We have not.

ObjectClasses may be part of a hierarchy indicated by use of a SUP name in the objectClass definition which is not top. When an objectClass is defined in this manner each child objectClass MUST be of the same type (STRUCTURAL or AUXILLIARY) as its SUP parent and inherits all the attributes of its parent (or parents). In the fragment above (however defined) we simply have a hierarchy of STRUCTURAL ObjectClasses. To illustrate, the objectClass organizationalPerson contains the attribute title. However, when we add the ObjectClass inetOrgPerson, which has SUP organizationalPerson in its objectClass definition thus showing that its parent is organizationalPerson (and even if inetOrgPerson appears alone as shown in the second fragment above), we can use the attribute title. We have inherited title (and all the other attributes) from the parent ObjectClass. organizationalPerson in turn has SUP Person and thus we can also access any attribute contained in its definition.

Multiple Inheritance

While LDAP may not, in the true sense of the term, support multiple inheritance, ObjectClasses can have multiple SUP names and can inherit from multiple parents under special circumstances:

# from RFC 1274
objectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'
  SUP ( organization $ organizationalUnit ) STRUCTURAL
  MAY buildingName )

The definition of pilotOrganization defines two SUPerior ObjectClasses organization and organizationUnit both of which are STRUCTURAL. Now we really have blown our single STRUCTURAL Objectclass rule to bits. Not quite. Now we need to look in a bit more detail at how Objectclasses are defined. The following shows the ASN.1 definition of pilotOrganization:

    pilotOrganization OBJECT-CLASS
        SUBCLASS OF organization, organizationalUnit
        MAY CONTAIN {
                    buildingName}
    ::= {pilotObjectClass 20}

The ASN.1 definition shows that pilotOrganization is a SUBCLASS OF both oganization and organizationalUnit whereas if we look at the ASN.1 definitions of organization and oganizationalUnit:

   organizationalUnit OBJECT-CLASS
         SUBCLASS OF top
         MUST CONTAIN {
             organizationalUnitName}
         MAY CONTAIN {
             organizationalAttributeSet}
     ::= {objectClass 5}

    organization OBJECT-CLASS
         SUBCLASS OF top
         MUST CONTAIN {
             organizationName}
         MAY CONTAIN {
             organizationalAttributeSet}
     ::= {objectClass 4}

Both are a SUBCLASS OF top, meaning they are the highest level on their hierarchy. Thus, where the OBJECT-CLASS definition defines multiple parents, it is permissible to use multiple inheritence but not otherwise. Almost no OBJECT-CLASS definitions provide this capability - we could find none, other than pilotOganization.

Note: RFC 1274 which defined pilotOrganization was obsoleted by RFC 4524 and the above ASN.1 definitions are now missing from this RFC. The cosine.schema file (OpenLDAP 2.4.11) however still contains pilotOrganization.

Using the LDAP ObjectClass Hierarchy

In practice OpenLDAP 2.x+ versions can process the objectclass hierarchy so the following LDIF fragment, which is functionally identical to the one at the top of the page, works perfectly (and may be slightly less confusing):

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 above definition from OpenLDAP as an LDIF file it will return precisely what you defined in the original LDIF that created the entry. 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 lots of typing, else...

Problems, comments, suggestions, corrections (including broken links) or something to add? Please take the time from a busy life to 'mail us' (at top of screen), the webmaster (below) or info-support at zytrax. You will have a warm inner glow for the rest of the day.