Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

openSUSE 11.1 Reference Guide
Previous Page Home Next Page

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.

Table 26-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 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 (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.

openSUSE 11.1 Reference Guide
Previous Page Home Next Page

 
 
  Published under the terms fo the GNU General Public License Design by Interspire