mail us  |  mail this page

products  |  company  |  support  |  training  |  contact us

ZYTRAX OPEN LOGO

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.

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:

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 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 obectClass is defined in this manner it 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 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 {
                    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.

In practice OpenLDAP 2.x+ versions can process the objectclass hierarchy so the following LDIF fragment 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 last 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 some typing else...

Copyright © 1994 - 2014 ZyTrax, Inc.
All rights reserved. Legal and Privacy
site by zytrax
Hosted by super.net.sg
web-master at zytrax
Page modified: September 17 2013.

Contents

tech info
guides home
intro
contents
1 objectives
big picture
2 concepts
3 ldap objects
quickstart
4 install ldap
5 samples
6 configuration
7 replica & refer
reference
8 ldif
9 protocol
10 ldap api
operations
11 howtos
12 trouble
13 performance
14 ldap tools
security
15 security
appendices
notes & info
ldap resources
rfc's & x.500
glossary
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

web zytrax.com

Share Page

share page via facebook tweet this page submit page to stumbleupon submit page to reddit.com

Page Features

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

RSS Feed Icon RSS Feed

Resources

Systems

FreeBSD
NetBSD
OpenBSD
DragonFlyBSD
Linux.org
Debian Linux

Applications

LibreOffice
OpenOffice
Mozilla
SourceForge
GNU-Free SW Foundation

Organisations

Open Source Initiative
Creative Commons

Misc.

Ibiblio - Library
Open Book Project
Open Directory
Wikipedia

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