Lightweight Directory Access Protocol (LDAP)
To understand Lightweight Directory Access Protocol (LDAP) you must first understand directory services. This article defines directory services and how LDAP structures the entries in a directory service. Pay attention to the basic LDAP components such as attributes, entries, and data information trees (DITs). How does LDAP organize data, and what is LDAP inheritance? Note that there are some variations in LDAP protocols.
LDAP Inheritance
ObjectClass Inheritance
Each objectClass is a class that describes the characteristics of objects of that type.
However, unlike simple inheritance, objects in LDAP can be and often are instances of multiple classes (some programming languages provide similar functionality through multiple inheritance). This is possible because LDAP's conception of a class is simply
a collection of attributes that it MUST or MAY have. This allows multiple classes to be specified for an entry (although only one STRUCTURAL objectClass can and must be present), resulting in the object simply
having access to the merged collection of attributes with the strictest MUST or MAY declaration taking precedence.
In its definition, an objectClass can identify a parent objectClass from which to inherit its attributes. This is done using SUP followed by the objectClass to inherit from. For instance, the organizationalPerson objectClass
begins like this:
objectclass ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL . . .
The objectClass following the SUP identifier is the parent objectClass. The parent must share the objectClass type of the objectClass being defined (for instance STRUCTURAL or
AUXILIARY). The child objectClass automatically inherits the attributes and attribute requirements of the parent.
When assigning an objectClass in an entry, you only need to specify the most specific descendent of an inheritance chain to have access to the attributes all the way up. In the last section, we used this to specify inetOrgPerson as
the sole objectClass for our John Smith entry while still having access to the attributes defined in the person and organizationalPerson objectClasses. The
inetOrgPerson inheritance hierarchy looks like this:
inetOrgPerson -> organizationalPerson -> person -> top
Almost all objectClass inheritance trees end with a special objectClass called "top". This is an abstract objectClass whose only purpose is to require that objectClass itself be set. It is used to indicate the top of the inheritance chain.