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 or, for short, DIT. The complete path to the desired entry, which unambiguously identifies it, is called distinguished name or DN. The single nodes along the path to this entry are 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 29.1, “Structure of an LDAP Directory”.
The complete diagram comprises 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 global determination of which types of objects should be stored in the DIT is done 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 29.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 29.1. Commonly Used Object Classes and Attributes
Object Class | Meaning | Example Entry | Compulsory 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 29.1, “Excerpt from schema.core (line numbering for explanatory reasons)” shows an excerpt from a scheme directive with explanations.
Example 29.1. Excerpt from schema.core (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 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
.