mail us  |  mail this page

products  |  company  |  support  |  training  |  contact us


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 LDIF fragment below (there are other ways to define this structure):

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

The ObjectClasses Person, organizationalPerson and inetOrgPerson are all STRUCTURAL. 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 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). We now simply have a hierarchy of STRUCTURAL ObjectClasses. To illustrate, organizationalPerson contains the attribute title, when we define the ObjectClass inetOrgPerson (even if it appears alone) we can use the attribute title. We have inherited title from the parent ObjectClass.

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 {
    ::= {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 {
         MAY CONTAIN {
     ::= {objectClass 5}

    organization OBJECT-CLASS
         SUBCLASS OF top
         MUST CONTAIN {
         MAY CONTAIN {
     ::= {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
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.

Copyright © 1994 - 2015 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
Hosted by
web-master at zytrax
Page modified: January 06 2015.


tech info
guides home
1 objectives
big picture
2 concepts
3 ldap objects
4 install ldap
5 samples
6 configuration
7 replica & refer
8 ldif
9 protocol
10 ldap api
11 howtos
12 trouble
13 performance
14 ldap tools
15 security
notes & info
ldap resources
rfc's & x.500
ldap objects
change log

Creative Commons License
This work is licensed under a Creative Commons License.

If you are happy it's OK - but your browser is giving a less than optimal experience on our site. You could, at no charge, upgrade to a W3C STANDARDS COMPLIANT browser such as Firefox


Share Page

share page via facebook tweet this page submit page to stumbleupon submit page to

Page Features

Page comment feature Send to a friend feature print this page Decrease font size Increase font size

RSS Feed Icon RSS Feed



Debian Linux


GNU-Free SW Foundation


Open Source Initiative
Creative Commons


Ibiblio - Library
Open Book Project
Open Directory

SPF Resources

Draft RFC
SPF Web Site
SPF Testing
SPF Testing (member only)

Display full width page Full width page

Print this page Print this page

SPF Record Conformant Domain Logo