26.2 Structure of an LDAP Directory Tree
To get a deep background knowledge on how a LDAP server works and how the
data are stored, it is vital to understand the way the data are organized
on the server and how this structure enables LDAP to provide fast access
to the data you need. To successfully operate an LDAP setup, you also
need to be familiar with some basic LDAP terminology. This section
introduces the basic layout of an LDAP directory tree and provides the
basic terminology used in an LDAP context. Skip this introductory
section, if you already have some LDAP background knowledge and just want
to learn how to set up an LDAP environment in
openSUSE. Read on at
Section 26.3, Configuring an LDAP Server with YaST or Section 26.7, Manually Configuring an LDAP Server,
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:
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.
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 26-1 Structure of an LDAP Directory
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 employee
Geeko Linux, in this case, is
cn=Geeko Linux,ou=doc,dc=example,dc=com. It is
composed by adding the RDN cn=Geeko Linux to the DN of
the preceding entry ou=doc,dc=example,dc=com.
The types of objects that should be stored in the DIT are globally
determined following a Schema. 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 Schema, therefore, must contain definitions of all object classes and
attributes used in the desired application scenario. There are a few
common Schemas (see RFC 2252 and 2256).
The LDAP RFC defines a few commonly used Schemas (see e.g.,
RFC4519). Additionally there are Schemas available for many other use cases
(e.g., Samba, NIS replacement, etc.).
It is, however, possible to
create custom Schemas or to use multiple Schemas complementing each other
if this is required by the environment in which the LDAP server should
Table 26-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 26-1 Commonly Used Object Classes and Attributes
domainComponent (name components of the domain)
organizationalUnit (organizational unit)
inetOrgPerson (person-related data for the
intranet or Internet)
sn and cn
Example 26-1 shows an excerpt from a Schema
directive with explanations (line numbering for explanatory reasons).
Example 26-1 Excerpt from schema.core
#1 attributetype (184.108.40.206 NAME ( 'ou' 'organizationalUnitName')
#2 DESC 'RFC2256: organizational unit this object belongs to'
#3 SUP name )
#4 objectclass ( 220.127.116.11 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
$ 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 Schemas can be found in the
documentation of OpenLDAP. When installed, find it in