Part III. Services / Chapter 29. LDAP—A Directory Service | ||||
|---|---|---|---|---|
 | 28.3. Configuring an NTP Client with YaST | 29.2. Structure of an LDAP Directory Tree |  | |
Part III. Services / Chapter 29. LDAP—A Directory Service | ||||
|---|---|---|---|---|
| 28.3. Configuring an NTP Client with YaST | 29.2. Structure of an LDAP Directory Tree | | |
Table of Contents
Abstract
The Lightweight Directory Access Protocol (LDAP) is a set of protocols designed to access and maintain information directories. LDAP can be used for numerous purposes, like user and group management, system configuration management, or address management. This chapter provides a basic understanding of how LDAP works and how to manage LDAP data with YaST.
It is crucial within a networked environment to keep important information structured and quickly available. This can be done with a directory service that, like the common yellow pages, keeps information available in a well-structured, quickly searchable form.
In the ideal case, a central server keeps the data in a directory and distributes it to all clients using a certain protocol. The data is structured in a way that allows a wide range of applications to access it. That way, it is not necessary for every single calendar tool and e-mail client to keep its own database—a central repository can be accessed instead. This notably reduces the administration effort for the information. The use of an open and standardized protocol like LDAP ensures that as many different client applications as possible can access such information.
A directory in this context is a type of database optimized for quick and effective reading and searching:
To make numerous (concurrent) reading accesses possible, write access is limited to a small number of updates by the administrator. Conventional databases are optimized for accepting the largest possible data volume in a short time.
Because write accesses can only be executed in a restricted fashion, a directory service is employed for administering mostly unchanging, static information. Data in a conventional database typically changes very often (dynamic data). Phone numbers in a company directory do not change nearly as often as, for example, the figures administered in accounting.
When static data is administered, updates of the existing data sets are very rare. When working with dynamic data, especially when data sets like bank accounts or accounting are concerned, the consistency of the data is of primary importance. If an amount should be subtracted from one place to be added to another, both operations must happen concurrently, within a transaction, to ensure balance over the data stock. Databases support such transactions. Directories do not. Short-term inconsistencies of the data are quite acceptable in directories.
The design of a directory service like LDAP is not laid out to support complex update or query mechanisms. All applications accessing this service should gain access quickly and easily.
Many directory services have previously existed and still exist both in Unix and outside it. Novell NDS, Microsoft ADS, Banyan's Street Talk, and the OSI standard X.500 are just a few examples. LDAP was originally planned as a lean flavor of DAP, the directory access protocol, which was developed for accessing X.500. The X.500 standard regulates the hierarchical organization of directory entries.
LDAP is a trimmed down version of the DAP. Without losing the X.500 entry hierarchy, profit from LDAP's cross-platform capabilities and save resources. The use of TCP/IP makes it substantially easier to establish interfaces between a docking application and the LDAP service.
LDAP, meanwhile, has evolved and is increasingly employed as a
stand-alone solution without X.500 support. LDAP supports
referrals with LDAPv3 (the protocol version in package
openldap2), making it possible to
realize distributed databases. The usage of SASL (simple authentication and
security layer) is also new.
LDAP is not limited to querying data from X.500 servers, as it was originally planned. There is an open source server slapd, which can store object information in a local database. There is also an extension called slurpd, which is responsible for replicating multiple LDAP servers.
The openldap2 package
consists of:
A stand-alone LDAPv3 server that administers object information in a BerkeleyDB-based database.
This program enables the replication of modifications to data on the local LDAP server to other LDAP servers installed on the network.
slapcat, slapadd, slapindex
The Unix system administrator traditionally uses the NIS service for name
resolution and data distribution in a network. The configuration data
contained in the files in /etc and the directories
group, hosts,
mail, netgroup,
networks, passwd,
printcap, protocols,
rpc, and services are distributed
by clients all over the network. These files can be maintained without major
effort because they are simple text files. The handling of larger amounts of
data, however, becomes increasingly difficult due to nonexistent
structuring. NIS is only designed for Unix platforms, which makes its
employment as a central data administrator in a heterogeneous network
impossible.
Unlike NIS, the LDAP service is not restricted to pure Unix networks. Windows servers (from 2000) support LDAP as a directory service. Novell also offers an LDAP service. Application tasks mentioned above are additionally supported in non-Unix systems.
The LDAP principle can be applied to any data structure that should be centrally administered. A few application examples are:
Employment as a replacement for the NIS service
Mail routing (postfix, sendmail)
Address books for mail clients, like Mozilla, Evolution, and Outlook
Administration of zone descriptions for a BIND9 name server
This list can be extended because LDAP is extensible, unlike NIS. The clearly-defined hierarchical structure of the data eases the administration of large amounts of data, because it can be searched better.
