Lightweight Directory Access Protocol

The Lightweight Directory Access Protocol [ laɪtweɪt daɪrektəri: ækses prəʊtəkɒl ] (LDAP; German Lightweight Directory Access Protocol ) is an application protocol from the network technology. It allows the retrieval and modification of information in a directory service ( in the network, a distributed hierarchical database ) over an IP network. The current version is specified in RFC 4510 / RFC 4511.

• 5.1 LDAP server
• 5.2 LDAP and database models 5.2.1 Potential Problems
• 5.2.2 Strengths and Main applications of LDAP

Overview

LDAP is based on the client -server model and is used in so-called directory services (English directories or directory services ) are used. It describes the communication between the LDAP client and the directory ( Directory ) Server. From such a list, object- related data such as personal data or computer configurations are read. The communication is based on queries.

The directory can contain, for example an address book: In his e -mail client, a user triggers the action Find the email address of Joe User to. The e -mail client formulates an LDAP query to the directory, which provides the address information. The directory formulated the answer and send it to the client: joe.user @ example.org.

In the meantime, has become naturalized in administrative parlance, that is called an LDAP server. This means you use a directory server whose data structure of the LDAP specification corresponds to and is able to exchange data via the LDAPv3 protocol.

The protocol provides all the functions that are necessary for such communication: Login to the server (bind ) the search query ( search me all the information about the user named "Joe User" ) and the modification of the data ( Change the password for the user Joe User).

Newer implementations that go beyond RFC 2251 and subject to a possible extension of the present Protocol shall take into account the replication of data between different directories.

History

LDAP was developed at the University of Michigan ( UMich ) and first proposed in RFC 1487 in 1993. At the same time introduced the UMich before the first server implementation, which is known as " UMich LDAP" today. LDAP is a simplified alternative to the Directory Access Protocol (DAP), which is specified as part of the X.500 standard. The X.500 standard is very comprehensive and is based on a complete ISO / OSI stack, which made implementation difficult and hardware intensive. LDAP was developed with the goal to make directory services simpler and thus more popular. LDAP is based on a TCP / IP stack and implements only a selection of the DAP functions and data types. As a result, LDAP could be implemented on workstations in the early nineties and gained a wide application base.

LDAP and X.500

X.500 requires strict implementation of the directory data and, with DAP a larger operation and control scope as LDAP. This hinders the wider distribution in many companies. The decision to implement a "lightweight " version of the DAP protocol, led to a high flexibility in the networks, so that those directories for the first time found a wider distribution.

Operation

To get an overview of how an LDAP architecture, it is necessary that a distinction between the organization of the LDAP directory and the LDAP protocol.

LDAP directory

The data structure of an LDAP directory is given by a hierarchical tree with roots, branches and leaves. This tree is also called the Directory Information Tree (DIT ). The root (root, suffix ) is the central data object under it to branch the higher structures. Example: If an LDAP directory used in a company named ACME, the organization can be defined as root, o = acme.

People can be deposited in branches below this root: ou = people, o = acme

Groups can be stored in other branches below the root: ou = groups, o = acme

In order for the organization of the data is not done arbitrarily, used each LDAP directory a certain standard and possibly wider structure. The structure is defined by the schema used. An LDAP schema defines each object classes and their attributes, organization such as the person class or the class.

The directory entries are called LDAP objects. Every object belongs to at least one, but usually several classes. So rather than three objects are required for the data of a person, their email address and their passwords, but the same object is one of three classes. This could mean in this example, person, inetOrgPerson and POSIX account.

There are three types of object classes: Since an object must belong to at least one structural class, which is the default. There are also helper classes which can be used to assign the same attributes various objects. Last but not least, there are abstract base classes from which no objects but only subordinate base classes can be generated.

Each object is composed of independent and attributes. A single object is uniquely identified by the distinguished name ( DN) such as uid = juser, ou = People, ou = webdesign, c = de, o = acme. This is made up of individual relative distinguished names (RDN ). Another notation for the DN is the canonical name that does not contain the attribute tags as ou or c, and wherein the separation between the RDNs done by slashes. In addition, the sequence starts, as opposed to dn, with the first entry, so for example acme / en / webdesign / People / juser.

Each attribute of an object has a type and one or more values ​​. The type designations of the attributes are usually easy to remember shortcuts such as cn for common name, ou for organizational unit, st for state, c for country or mail address for e-mail. The allowed values ​​of an attribute are dependent on its type. So could a mail attribute the address hans.wurst @ example.com contain a jpegPhoto attribute, however, would save a photo as binary data in JPEG format. The defined in the object class attributes can be either mandatory (mandatory) or optional.

The objects are stored in a hierarchical structure that reflects political, geographic or organizational boundaries. The largest units are placed on the top of the directory tree, the ever- fans out downwards. While objects that themselves contain objects that are referred to as container objects, called the "ends" of the tree leaf objects.

If individual LDAP servers are responsible for certain parts of the directory tree, it is called partitions. If a client sends a request for which the server does not have jurisdiction, the server can refer the client to another server. LDAP server can be configured redundantly. For this purpose, a master-slave configuration is used often. If a client attempts to change data on a slave server, it will be referred to the master. The changes on the master server are then passed on to all slave servers.

Since many different schemes are available in different versions in use, the idea of ​​a "global" all-encompassing LDAP directory is not real. LDAP server can be used as a central directory service for various purposes in different sizes, the object hierarchy, however, remains limited to an organization generally.

Protocol

LDAP is a protocol of the application layer (application layer ) to the DoD four-layer model used for TCP and works by means of precisely -specified access processes:

• Bind: The bind directive is conveyed to the Directory Server over a dn who wants to perform the access ( either anonymously via password authentication, or otherwise)
• BaseDN: The baseDN defines where in the directory tree down to search for specific objects to be started. This search can be set to do a search on exactly this object ( base)
• This object and everything underneath ( sub)
• One level below the BaseDNs ( one)

Otherwise, the necessary search specifications as search operator apply (example (& ( mail = joe *) (ou = People ))), server name ( for example ldap.acme.com ) or port designation.

Example of an LDAP search with a simple command line program:

Ldapsearch -h ldap.acme.com -p 389- s sub -D " cn = Directory Manager, o = acme" -W -b " ou = people, o = acme" " (& ( mail = joe *) ( c germany = ) ) "mail

Explanation: The command line program contacted via LDAP to the Directory Server ldap.acme.com (port 389) and logs on the account of the Directory Manager in this system. The request is aimed at all users of this forum ( below the branch ou = people, o = acme ) and is looking for persons from Germany, whose email address begins with joe ( (& ( mail = joe *) (c = germany ))). If people found that match this filter, so their mail will be returned (mail).

Applications

LDAP is today in many areas, such as:

• Address as the Apple Address Book, IBM Lotus Notes, Microsoft Outlook, Mozilla Thunderbird, Novell Evolution, the OpenOffice.org and LibreOffice mail merge and The Bat
• User management, such as Novell eDirectory, Apple Open Directory, POSIX accounts, Microsoft Active Directory Service
• Authentication such as PAM
• Management of user data for SMTP, POP, and IMAP servers, and in the following mail servers: postfix, qmail, exim, Lotus Domino, sendmail, Cyrus, Courier. Even in the corresponding anti-spam essays: SpamAssassin and Amavisd

LDAP

Many manufacturers offer LDAP server, for example:

• Apache Software Foundation ( FLOSS - variant Apache Directory)
• Apple ( by Open Directory )
• IBM / Lotus ( IBM Tivoli Directory Server or Lotus Domino server with LDAP task )
• Microsoft ( through Active Directory or ADAM) (Service is installed when Windows is the domain controller)
• Novell ( by eDirectory)
• OpenLDAP ( FLOSS version for a number of different platforms)
• Oracle ( Oracle Internet Directory)
• Red Hat ( FLOSS variant 389 Directory Server )
• Atos ( by DirX Directory Server; acquired by Siemens IT Solutions and Services)
• Sun ( Sun Java System Directory Server; taken over by Oracle)
• Univention ( by Univention Corporate Server (UCS ) with OpenLDAP )

LDAP and database models

LDAP acts as a front end to hierarchical databases. This form of data storage is designed for completely different problems than the relational model. LDAP itself is no database, only the protocol for communications.

Potential Problems

• No normal forms: LDAP acts as a front end to hierarchical databases. This structure does not enforce normal forms, for example, may be multivalued attributes allowed.
• Query Language: From the relational operations projection ( column selection ), selection ( line selection ), cross product ( JOIN), renaming columns (Rename, AS) and aggregation (GROUP BY) supports LDAP only projection without generation of computed attributes and selection. Analogous operations to join, or an " Dereferenced this DN " operator does not exist, a Rename and thus a Selfjoin does not exist, and aggregation must be coded out with loops in the client. Unlike SQL is the LDAP query language is not algebra, it lacks the seclusion. Query results of LDAP queries are not LDAP trees, but sets of nodes, and the LDAP query language is not re- apply to LDAP results to refine the results.

Strengths and main applications of LDAP

• Authorization and authentication: The LDAP protocol and LDAP servers are optimized for authentication (password is checked ), authorization ( permission checking ) and address searches. The fast connection establishment and termination, the simply structured protocol and concise query language ensure quick processing.
• Fast Read Access: Due to its non-normalized data storage can be accessed very quickly to all data of an LDAP data set, because all the data can be read with a single read access immediately.
• Distributed Data Management: LDAP provides distributed data management such as local redundant data storage in distributed locations, loosely coupled replication for synchronizing data between sites and extremely high availability without complex configuration or high costs.
• Flexible, fully object -oriented data model: LDAP inherits from the X.500 standard object-oriented data model. This LDAP directories can be flexibly adapted to volatile requirements without already lost implemented in the directory functionality.
• Broad Application Support: LDAP is the industry de facto standard for authentication, authorization, and user and address directories. Most software products that have to deal with user data and have market relevance, LDAP support as the protocol.

RFC documents

LDAP is described in the following RFC documents.

• LDAPv2 ( obsolete): RFC 1777, RFC 1778, RFC 1823, RFC 1959, RFC 1960
• LDAPv3: RFC 2251, RFC 2252, RFC 2253, RFC 4510, RFC 4511, RFC 4512, RFC 4513, RFC 4514, RFC 4515, RFC 4516, RFC 4517, RFC 4518, RFC 4519