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