LDAP

Overview of the protocol

The session of LDAP begins with the fact that the client is connected to the LDAP server - by default it is TSR port 389. the client sends a request for transaction then he receives the answer from the server. In most cases the client should not wait for the answer before sending the following request, the server sends answers in random order.

Request for transactions

• Start of TLS (Transport Layer Security) using LDAPv3 expansion for ensuring reliable connection.
• Authentication and indication of the version of the LDAP protocol.
• Search of entries in the directory.
• Whether comparison contains record required attribute.
• Adding of new record.
• Removal of record.
• Record modification.
• Modification of distinguished name (Distinguished Name, DN) - movement or renaming of record
• Canceling of the previous request.
• Expanded transactions
• Connection closing.

Besides, the server can send not requested notification which is not reply to the request. For example, before disconnecting.

Structure

The protocol of access to the LDAP directories corresponds to model X.500 accepted as the standard in 1993:

• The directory represents a catalog tree of records.
• Record consists of a set of attributes.
• The attribute has a name (a type attribute or attribute of the description) and one or several values.
• Each record has a unique identifier - distinguished name (Distinguished Name, DN). Which consists of relative distinguished name (Relative Distinguished Name, RDN) made of attribute(s) of record which parent record of distinguished name follows. So DN is the complete file name, and RDN a relative name in the folder.

Keep in mind that DN can change during record existence. On an example when record moves in a directory tree. That reliably and unambiguously define record positions in a set of its operational attributes UUID can be included.

In LDAP record can look approximately so:

dn: cn= Ivan Ivanov, dc=example, dc=com cn: Ivan Ivanov givenName: Ivan sn: Ivanov telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1232 mail: ivan@example.com manager: cn= Asya Alexandrova, dc=example, dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top

Here: dn is a record name which should attribute, not a part of record. "cn= Ivan Ivanov" are RDN records, a "dc=example,dc=com" - DN of parent record in which dc designates a domain component. In other lines attributes of record are shown.

The server stores the subdirectory (subtree) since specific record, for example, "dc=example, dc=com" and its expansions. On the server links to other servers can be also stored, thus, the attempt to find "ou=department, dc=example, dc=com" can return the offer or the permanent link on the server which stores this part of the folder of the directory. The client can be connected to this server. Some servers are united in chains, i.e. the separate server contacts other server and returns the result to the client.

Transactions

The client provides to each request a positive message ID, and the answer of the server has the same message ID. The answer includes the resulting number code which can be successful, point to errors or provide other data. Before the answer the server can send other messages with other resultants this - for example, in this message all records found during search transaction can be sent.

The LDAP protocol is defined in the following RFC:

• RFC 4510 — Lightweight Directory Access Protocol (LDAP) Technical Specification Roadmap (заменяет RFC 3377)
• RFC 4511 — Lightweight Directory Access Protocol (LDAP): The Protocol
• RFC 4512 — Lightweight Directory Access Protocol (LDAP): Directory Information Models
• RFC 4513 — Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
• RFC 4514 — Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names
• RFC 4515 — Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters
• RFC 4516 — Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator
• RFC 4517 — Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
• RFC 4518 — Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation
• RFC 4519 — Lightweight Directory Access Protocol (LDAP): Schema for User Applications
• RFC 4520 (aka BCP 64) — Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) (заменяет RFC 3383)
• RFC 4521 (aka BCP 118) — Considerations for Lightweight Directory Access Protocol (LDAP) Extension

Server part

LDAP is one of the most widespread standards of access to directory services. From freely extended open implementations the OpenLDAP server, from paid directory services which support the protocol is most popular, it is possible to select the Active Directory from the Microsoft company intended for centralization of management of Windows networks. The implementations of directory services supporting LDAP as the protocol of access offer also other large companies, for example, of Novell and Sun.

Client part

Both address directories of e-mail clients, and back-end'a of different network services act as clients of LDAP (the servers DNS, SMTP, Samba, UTS, etc.). LDAP also got broad support from such companies as:

• Apache (on the basis of the server of directories Apache)
• Apple (on the basis of Open Directory/OpenLDAP)
• AT & T
• Banyan
• HP
• IBM / Lotus
• ISODE (via the M-Vault-server)
• Microsoft (using the Active Directory)
• Netscape (now in products from Sun Microsystems and Red Hat)
• Novell (through eDirectory)
• OctetString (via the VDE server)
• Oracle (on the basis of Oracle Internet Directory)
• Radiant Logic (через RadiantOne Virtual Directory Server)
• Red Hat (via the server katalogovred Hat)
• SiemensAG (through DirX the server)
• SGI
• Sun (via the server of the iPlanet and Sun ONE directories)
• Symlabs (through the Extender directory)

And also in implementations open source and in the free software, such as OpenLDAP and Fedora the server the directory. Apache HTTP Server used as the proxy server (with the module mod_proxy) also supports LDAP.