Front cover - IBM Redbooks

For example, consider an LDAP object that is defined with the following object
classes:
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: eDominoAccount
The order shown for the object classes indicates a hierarchical relationship
between these object classes, but not necessarily. The “top” objectclass is of
course at the top of the hierarchy. Most other objectclasses that are not intended
to be subordinate to another class should have “top” as its superior. Not all LDAP
directories expect a user record to have the “top” object class assigned to it,
while others require it for using Access Control Lists (ACLs) on the object. The
“person” class is subordinate to the “top” class, and requires that the “cn”
(Common Name) and “sn” (Surname) attributes be populated, and allows several
other optional attributes. The “organizationalPerson” class inherits from the
“person” class. The “inetOrgPerson” class inherits from “organizationalPerson”
class. Now here is the tricky part: the “eDominoAccount” is subordinate to the
“top” class and requires that the “sn” and “userid” attributes be populated. Notice
this overlaps with the “person” object class requirement for the “sn” attribute.
Does this mean we need to store the “sn” attribute twice? No, because it is a
standard attribute. We talk more about attributes a little later in this section. This
example illustrates that you cannot necessarily tell the hierarchical relationship of
object classes by the order they appear in a list.
So then, how do we tell? We tell (or in reality, your LDAP directory interface
shows you) by looking at the object class definitions themselves. The methods
for defining object classes for LDAP V3 are described in RFC-2251 and
RFC-2252. The following object class definitions are taken from IBM Directory
Server, which uses the same syntax as OpenLDAP server.
objectclass: top
objectclasses=( 2.5.6.0 NAME 'top' DESC 'Standard ObjectClass' ABSTRACT
MUST ( objectClass ) )
objectclass: person
objectclasses=( 2.5.6.6 NAME 'person' DESC 'Defines entries that
generically represent people.' SUP 'top' STRUCTURAL MUST ( cn $ sn ) MAY (
userPassword $ telephoneNumber $ seeAlso $ description ) )
objectclass: organizationalPerson
objectclasses=( 2.5.6.7 NAME 'organizationalPerson' DESC 'Defines entries
for people employed by or associated with an organization.' SUP 'person'
STRUCTURAL MAY ( title $ x121Address $ registeredAddress $
Chapter 8. Directory strategies 317