Structure of an LDAP Directory Tree

To get a deep background knowledge on how a LDAP server works and how the data is stored, it is vital to understand the way the data is 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 with respect to LDAP. 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 4.3, “Configuring an LDAP Server with YaST” or Section 4.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 the distinguished name or DN. A single node along the path to this entry is called relative distinguished name or RDN.

The relations within an LDAP directory tree become more evident in the following example, shown in Figure 4.1, “Structure of an LDAP Directory”.

Figure 4.1. Structure of an LDAP Directory

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 image. 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 can 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 relevant object must or can be assigned. The 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 4.1, “Commonly Used Object Classes and Attributes” 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 4.1. Commonly Used Object Classes and Attributes

Object Class

Meaning

Example Entry

Required Attributes

dcObject

domainComponent (name components of the domain)

example

dc

organizationalUnit

organizationalUnit (organizational unit)

doc

ou

inetOrgPerson

inetOrgPerson (person-related data for the intranet or Internet)

Geeko Linux

sn and cn


Example 4.1, “Excerpt from schema.core” shows an excerpt from a Schema directive with explanations (line numbering for explanatory reasons).

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