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, respectively.

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 26-1.

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 operate.

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.

Example 26-1 shows an excerpt from a Schema directive with explanations (line numbering for explanatory reasons).

#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 Schemas can be found in the documentation of OpenLDAP. When installed, find it in /usr/share/doc/packages/openldap2/admin-guide/index.html.