34.2 Structure of an LDAP Directory Tree
An LDAP directory has a tree structure. All entries (called objects) of
the directory have a defined position within this hierarchy. This hierarchy
is called the directory information tree (DIT). The
complete path to the desired entry, which unambiguously identifies
it, is called distinguished name or DN. A single
node along the path to this entry is called relative
distinguished name or RDN. Objects can generally be assigned to
one of two possible types:
- container
-
These objects can themselves contain other objects. Such object
classes are root (the root element of the directory
tree, which does not really exist), c (country),
ou (organizational unit), and dc
(domain component). This model is comparable to the directories (folders)
in a file system.
- leaf
-
These objects sit at the end of a branch and have no subordinate
objects. Examples are person,
InetOrgPerson, or
groupofNames.
The top of the directory hierarchy has a root element
root. This can contain c (country),
dc (domain component), or o
(organization) as subordinate elements. The relations within an LDAP
directory tree become more evident in the following example, shown in
Figure 34-1.
The complete diagram is a fictional directory information tree.
The entries on three levels are depicted. Each entry corresponds to one box
in the picture. The complete, valid distinguished name
for the fictional SUSE employee Geeko
Linux, in this case, is cn=Geeko
Linux,ou=doc,dc=suse,dc=de. It is composed by adding the RDN
cn=Geeko Linux to the DN of the preceding entry
ou=doc,dc=suse,dc=de.
The types of objects that should be stored in
the DIT are globally determined following a scheme. The
type of an
object is determined by the object class. The object
class determines what attributes the concerned object
must or can be assigned. A scheme,
therefore, must contain definitions of all object classes and attributes
used in the desired application scenario. There are a few common schemes
(see RFC 2252 and 2256). It is, however, possible to create custom schemes
or to use multiple schemes complementing each other if this is required by
the environment in which the LDAP server should operate.
Table 34-1 offers a small
overview of the object classes from core.schema and
inetorgperson.schema used in the example, including
required attributes and valid attribute values.
Table 34-1 Commonly Used Object Classes and Attributes
dcObject |
domainComponent (name components of the
domain) |
suse |
dc |
organizationalUnit |
organizationalUnit (organizational
unit) |
doc |
ou |
inetOrgPerson |
inetOrgPerson (person-related data for the
intranet or Internet) |
Geeko Linux |
sn and cn |
Example 34-1 shows an excerpt from a scheme
directive with explanations (line numbering for explanatory reasons).
Example 34-1
Excerpt from schema.core
#1 attributetype (2.5.4.11 NAME ( 'ou' 'organizationalUnitName')
#2 DESC 'RFC2256: organizational unit this object belongs to'
#3 SUP name )
...
#4 objectclass ( 2.5.6.5 NAME 'organizationalUnit'
#5 DESC 'RFC2256: an organizational unit'
#6 SUP top STRUCTURAL
#7 MUST ou
#8 MAY (userPassword $ searchGuide $ seeAlso $ businessCategory
$ x121Address $ registeredAddress $ destinationIndicator
$ preferredDeliveryMethod $ telexNumber
$ teletexTerminalIdentifier $ telephoneNumber
$ internationaliSDNNumber $ facsimileTelephoneNumber
$ street $ postOfficeBox $ postalCode $ postalAddress
$ physicalDeliveryOfficeName
$ st $ l $ description) )
...
The attribute type organizationalUnitName and the
corresponding object class organizationalUnit serve as an
example here. Line 1 features the name of the attribute, its unique OID
(object identifier) (numerical), and the abbreviation
of the attribute.
Line 2 gives a brief description of the attribute with
DESC. The corresponding RFC on which the definition is
based is also mentioned here. SUP in line 3 indicates a
superordinate attribute type to which this attribute belongs.
The definition of the object class
organizationalUnit begins in line 4, like in the
definition of the attribute, with an OID and the name of the object class.
Line 5 features a brief description of the object class. Line 6, with its
entry SUP top, indicates that this object class is not
subordinate to another object class. Line 7, starting with
MUST, lists all attribute types that
must be used in conjunction with an object of the type
organizationalUnit. Line 8, starting with
MAY, lists all attribute types that are permitted in
conjunction with this object class.
A very good introduction to the use of schemes can be found in the
documentation of OpenLDAP. When installed, find
it in
/usr/share/doc/packages/openldap2/admin-guide/index.html.