Lightweight Directory Access Protocol

Lightweight Directory Access Protocol ( LDAP ) is in the beginning a protocol allowing the interrogation and the modification of the services of Annuaire. This protocol rests on TCP/IP. It however evolved/moved to represent a standard for the systems of directories, including a data model, a model of naming, a functional model based on protocol LDAP, a model of safety and a model of replication. A directory LDAP generally respects the model X.500 enacted by UIT-T: it is a tree structure of which each node makes up of attributes associated with their values.

The naming of the elements constituting the tree (root, branches, sheets) often reflects the political, geographical or organisational model of the structure represented. The current trend is to use the naming DNS for the basic elements of the directory (root and first branches). The deeper branches of the directory can represent people ( people ), organisational units ( organizational units ), groups ( groups ),…

dc=org | dc=example /\ ou=people ou=groups

The last version on protocol is LDAPv3. This version is defined by IETF in several RFC while starting with the RFC 4510.

Origin and influences

LDAP was initially conceived to be a light alternative to reach the X.500 directories. These directories were traditionally questioned through the protocol X.500 Directory Access Protocol (DAP) which required the use of the pile of protocols of OSI model. The use of a footbridge LDAP/DAP gave access a waiter DAP while being on a network TCP/IP. This model of directory is derived from DIXIE and Directory Assistance Service.

The appearance of native directories LDAP ( standalone LDAP directory ) followed quickly, just like that of waiters dealing with at the same time DAP and LDAP. The directories became popular in the companies because it was not necessary any more to deploy a network OSI. Nowadays, the access protocols to the X.500 directories (including DAP) can be directly used on TCP/IP.

The protocol was created by Tim Howes of the Université of Michigan, Steve Kille of the ISODE and Wengyik Yeong de Performance Systems International in 1993. The developments which followed, were undertaken by the Internet Engineering Task Force (IETF).

Initially the protocol had as a name Lightweight Directory Browsing Protocol ( LDBP ), because it allowed only the data retrieval. It was famous at the time of the addition of new possibilities (addition, modification).

LDAP influenced a certain number of protocols of Internet, including the last versions of X.500: XML Enabled Directory (XED), Directory Services Markup Language (DSML), Service Provisioning Markup Language (SPML), and Service Protocol Hiring (SLP).

Overall picture

A customer begins a session LDAP while connecting himself on port TCP 389 from the waiter. The customer sends then requests of operation to the waiter. The waiter sends answers in return. Besides some exceptions, the customer does not need to await answer of the waiter to send new requests, and the waiter can send its answers in any order.

Once connection to the waiter established, the traditional operations are:

Bind : indicate the version of the protocol used, and authenticates the user. It is possible to make an anonymous bind by not providing neither name of user nor password;
Start TLS : use of the layer Transport To bush-hammer Security (TLS) to make safe connection;

Search : seek in the directory and repatriation of the data;
Compares : test which given if an entry contains an attribute with a given value;
Add : addition of a new entry;
Delete : removal of an entry;
Modify : modification of an entry;
Modify DNN : displacement or renaming of an entry;
Abandonment : cancellation of a preceding request;
Extended Operation : operation which makes it possible to define other operations;

Unbind : enclose connection.

Moreover, the waiter can send not requested notifications " Unsolicited Notifications" which is not answers to requests, for example before enclosing an inactive connection.

A method to make safe communications LDAP is to use a tunnel SSL. This use is visible during the use of URL starting with " ldaps" . Standard port TCP/IP for ldaps is 636. However the use of TLS is recommended because protocol SSL is known to have some weaknesses.

Protocol LDAP is defined with ASN.1 and the messages are encodés with the binary format BER. However it uses a textual representation for a certain number of attributes and types of ASN.1.

Structure of the directory

Directories LDAP follow the X.500 model:

A directory is a tree of entrées.
An entry consists of a whole of attributs.
An attribute has a name, a type and one or more valeurs.
The attributes are defined in diagrams .

The fact that the attributes can be multi-valués is a major difference between directories LDAP and the SGBDR. Moreover, if an attribute does not have value, it is purely and simply absent entry.

Each entry has a single identifier, the Distinguished Name (DNN). It is made up starting from its Relative Distinguished Name (RDN) follow-up of the DNN of his relative. It is a recursive definition. One can make the analogy with another tree structure, the sytèmes of files; the DNN being the absolute way and the RDN the way relative to a repertory. In general the RDN of an entry representing a person is the attribute uid :

dc=org | dc=example /\ ou=people ou=groups | uid=toto

The RDN of louse is rdn: uid=toto , its DNN is DNN: uid=toto, ou=people, dc=example, dc=org .

An entry can resemble the following representation when it is formatted in LDIF:

DNN: cn=John Doe, dc=example, dc=org Cn: John Doe givenName: John Sn: Doe telephoneNumber: +1 555 6789 telephoneNumber: +1 555 1234 email: john@example.com to manage: will cn=Barbara Doe, dc=example, dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: signal

DNN is the name of the entry, it is not an attribute of the entry. " cn=John Doe" is the RDN of the entry and " dc=example, dc=org" is the DNN of his/her relative. The other lines show the attributes of the entry. The names of the attributes are sometimes the mnemonic ones for most current: " cn" for common name , " dc" for domain component , " sn" for surname .

A waiter contains a under-tree of which the root is a specific entry and all its children, for example: " dc=example, dc=org". The waiters can also contain references towards other waiters, thus the access to an entry (" ou=un service, dc=example, dc=org") can turn over a reference ( referral ) to another waiter which contains the desired under-tree. The customer can then contact (automatically or not) the other waiter. Certain waiters deal with the chaining ( chaining ) which makes it possible the waiter to question other waiters to return information wanted to the customer.

The results returned by the waiter are not sorted, that it is for the entries, the attributes of the entries or the values of the attributes.

Operations

The customer gives to each request an identifier Message ID , the waiter answers the request with the same identifier. The answer includes a numerical code of result indicating the state of the request (success, failure,…). The answer also includes the possible data which can result from a research.

Bind (authentification)

The operation bind authenticates the customer within the waiter. The simple bind sends the DNN of the user and his password in light, this is why connection must be protected by TLS. The waiter checks the password by comparing it with the attribute userPassword (in general) of the corresponding entry. The value of the attribute containing the password starts with the name between accodances of the algorithm used to code the password (for example: userPassword: {md5} aGZh5…)

The anonymous bind , i.e. without providing of identifier nor of password, puts connection in an anonymous state. Consequently the customer will not be able to carry out certain operations any more on all or part of the directory, according to ACL installation.

The SASL bind makes it possible to use other mechanisms of authentification: Kerberos, certificate customer, etc

The stage of bind also allows the customer and the waiter to agree on the version of the protocol to be used. In general version 3 is used. It is even possible with the waiter to refuse to communicate with customers in a protocol lower than his.

StartTLS

The operation StartTLS establishes a connection protected between the customer and the waiter by using the technique TLS, heir to SSL. This security operates on two points: confidentiality (a third cannot include/understand the exchange) and integrity of the data (the data are validated by a signature). During negotiation TLS, the waiter sends its certificate X.509 to the customer to prove his identity. The customer can answer by sending his certificate but the identification of the customer is optional. It is generally possible to configure customers and waiters to know if the certificates are optional or essential.

The waiters generally deal with the protocol nonstandard " LDAPS" ( LDAP over SSL ). This protocol uses port 636 contrary to the TLS which uses port 389 (the same one as the nonprotected LDAP). Protocol LDAPS differs from the LDAP on two points: 1) with connection, the customer and the waiter establish a connection TLS before any other order LDAP is not sent (without sending operation StartTLS ), 2) connection LDAPS must be closed at the time of the fence of TLS (whereas with StartTLS , it is possible to pass from a connection protected to a nonprotected connection, and conversely).

Search and Compare

The operation Search is used at the same time to make a research and to repatriate entries. Its parameters are:

baseObject : the DNN (Distinguished Name) of the entry from which to carry out research;
scope : bases for the entry baseObject itself, one to carry out a research on the level of the entries immediately attached to the baseObject , sub for a research in the under-tree of the entry;
filter : the criteria which determine if an entry belonged to the results or not, for example (& (objectClass=person) (|(givenName=John) (mail=john*))) - research the people who have as a John first name or whose email starts with John;
derefAliases : indicate if research must follow alias in the entries (entered which refer to other entries);
attributes : list attributes to be brought back at the conclusion of research;
sizeLimit : limitation of the number of entries brought back at the conclusion of research;
timeLimit : limitation of the time of research, expressed in seconds;
typesOnly : return only the types of attribute and not the values.

The waiter returns the entries which correspond, followed by the code return of the order (code of return).

The operation Compare takes in argument a DNN, a name of attribute and a value of attribute, then checks if the corresponding entry contains an attribute well having this value.

Remark : There does not exist of operation of the type Read . It is the operation Search which is used for the direct access with an entry. In this case, the parameter baseObject is the DNN of the entry which one wants to read, and the parameter scope is used with the value bases .

Update

The operations of update Add (addition), Delete (suppression), Modify (modification) take in argument the DNN of the entry to be updated.

The modification needs in addition to the list of the attributes to modify as well as the modification to be made: suppression of the attribute or certain values of the attribute (the attributes can be multi-valués), addition of a value, replacement of a value.

The addition of an entry can also contain a list of attributes and values to be associated with the entry.

The modification of DNN (displacement/renaming) takes in argument the RDN of the entry and, in an optional way, the DNN of the new relative, as well as a marker who indicates if the old RDN should or not be erased. The assumption of responsibility of the renaming of a under-tree in entirety depends on the waiters.

An operation of update is atomic, i.e. the other operations will see either the new entry or the old one. However, protocol LDAP does not define a principle of transaction, which makes it possible several customers to modify an entry at the same time. However, the waiters can use extensions to support it.

Wide operations

The operation wide are generic operations which make it possible to define new operations. For example the operations Chancel , Password Modify and StartTLS .

Abandonment

The operation Abandon sends a request to the waiter to say to him to give up an operation by providing him its identifier. The waiter does not have obligation to honor the request. Unfortunately, the operation Abandonment as well as the effective abandonment of an operation returns an answer. This is why the wide operation Cancel was defined, not to return an answer, but all the waiters do not deal with it.

Unbind

The operation Unbind gives up any operation in progress and firm connection. There is no answer. Its name has historical reasons, it is not the contrary operation with Bind .

The customers can finish a session by closing connection, but it is more clean to use Unbind . The waiter can thus differentiate the network errors from the discourteous customers.

URI

There exists a format of URI LDAP, but all the customers do not deal with it. The waiters use it to indicate to the customers the references towards other waiters. The format is the following:

ldap: //hôte: port/DN? attributes? depth? filters? extension

with:

DNN: the DNN from which to carry out research;
attributes: list containing the attributes to be returned, separated by commas;
depth : bases (by defect), one or sub for the depth of research;
filter: the filter of research;
extension: possible extensions of the format of URL LDAP.

As in all the URI, the characters special must be escaped while following the algorithm envisaged by RFC 3986.

One can also meet URI using the diagram not standardized “ldaps”.

For example:

ldap: /ldap.example.com/cn=John%20Doe,dc=example,dc=com

turn over all the attributes of the entry “John Doe”,

ldap: ///dc=example, dc=com?? sub? (givenName=John)

seek the entry having like first name “John” in the directory starting from the root.

Diagram

The contents of the entries of a directory LDAP are governed by diagram S.

The diagrams define the types of attribute which the entries of a directory can contain. The definition of an attribute includes a syntax, the majority of the nonbinary attributes in LDAPv3 use the syntax of the character strings UTF-8. For example, the attribute email can contain " utilisateur@example.org" , the attribute jpegPhoto can contain a photograph with the binary format JPEG, the attribute member can contain the DNN of an entry of the directory.

The definition of an attribute also indicates if the attribute mono-valué or is multi-valué, according to which rules will be made research/comparisons (sensitive in the breakage or not, search of under-chain or not).

The diagrams define classes of objects. Each entry of the directory must have at least a value for the attribute objectClass , which is a class of objects defined in the diagrams. Generally, the attribute objectClass is multi-valué and contains the class signal as well as a certain number of other classes.

Just like in the directed Programming object, the classes allow to describe an object by associating attributes to him. Classes LDAP represent people, organizations,… the fact that an entry belongs to a class (thus that the attribute objectClass contains the name of the class) enables him to use the attributes of this class. Certain attributes are obligatory and the other optional ones. For example, if the entry uses the class person , it must have obligatorily a value for the attributes Sn and Cn , and can optionally have a value for the attributes userPassword and telephoneNumber . The entries having generally several classes, differentiation between obligatory and optional attributes can be rather complex.

The elements of a diagram have a name and a single identifier named Object to identify (OID, to see).

Many waiters expose the diagrams of the directory like accessible entries LDAP starting from the DNN cn=schema. It is possible for the administrators to define their own diagram in addition to the standard diagrams.

Variations from one waiter to another

A large left the possible operations is left with the appreciation of the developer or the administrator.

For example, the data storage is not specified by the protocol. The waiter can flat use files, a SGBDR, or be simply a footbridge towards another waiter. The access controls (ACL) are not standardized either, although a common use emerges.

LDAP is an extensible protocol, which causes the appearance of new operations on certain waiters and not on others. For example, sorting of the results.

Use

The principal interest of LDAP is the standardization of the authentification. It is very easy to program a module of authentification using LDAP starting from a language having a API LDAP. It is the operation Bind which makes it possible to authenticate a user. More and more of Web applications have a module of authentification dealing with LDAP.

On the recent systems GNU/Linux, one sees more and more the adoption of a database using LDAP in the place of the files flat password and shadow . The data can be reached by the modules WFP and NSS.

Waiters LDAP

Apache Directory Server
Critical Path Directory Server and Meta Directory Server
Fedora Directory Server
Red Hat Directory Server
OpenLDAP
Novell eDirectory
Sun Directory Server Enterprise Edition
IBM SecureWay Directory
IBM Tivoli Directory Server (formerly IBM Directory Server)
IBM Lotus Domino
Active Directory of Microsoft
Siemens DirX
View500
Oracle Internet Directory
tinyldap a waiter LDAP minimalist
Mandriva Directory Server offers an interface Web to manage Samba and LDAP

Customers LDAP

Jxplorer: a customer developed under Java and thus independent of the operating system.
LDAPBrowser: a customer for Windows
LDAP Admin: another excellent customer for Windows
Apache Directory Studio: a customer multi platforms, developed in java, by Apache Software Foundation

See too

Internal bonds

Directory
IETF
Request For Comments
Internet Assigned Numbers Authority
Internet
industrial Standards and standards

External bonds

Group of standardization IETF LDAP (v3) Revision (ldapbis)
Page of the Committee Network of the Universities on LDAP
LDAP Wiki

RFCs

LDAP is defined by a series of Request For Comments:

RFC 4510 - Lighweight Directory Access Protocol (LDAP) Technical Roadmap Specification (replaces the preceding version, 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 off Distinguished Names
RFC 4515 - Lightweight Directory Access Protocol (LDAP): String Representation off 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): Diagram for To use Applications

The RFC following detail the good practices to be adopted concerning LDAP:

RFC 4520 (also BCP 64) - Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) (the RFC 3383 replaces)
RFC 4521 (also BCP 118) - Considerations for Lightweight Directory Access Protocol (LDAP) Extensions

What follows is a list containing the defining RFC of the LDAPv3 extensions:

RFC 2247 - Uses off DNS domains in distinguished names
RFC 2307 - Using LDAP ace has Network Information Service
RFC 2589 - LDAPv3: Dynamic Directory Services Extensions
RFC 2649 - LDAPv3 Operational Signatures
RFC 2696 - LDAP Simple Paged Result Control
RFC 2798 - inetOrgPerson LDAP Object Class
RFC 2849 - The LDAP Dated Interchange Format (LDIF)
RFC 2891 - Server Side Sorting off Search Results
RFC 3045 - Storing Vendor Information in the LDAP root From the
RFC 3062 - LDAP Password Modify Extended Operation
RFC 3296 - Named Subordinate References in LDAP Directories
RFC 3671 - Collective Attributes in LDAP
RFC 3672 - Subentries in LDAP
RFC 3673 - LDAPv3: All Operational Attributes
RFC 3687 - LDAP Component Matching Rules
RFC 3698 - LDAP: Additional Matching Rules
RFC 3829 - LDAP Authorization Identity Controls
RFC 3866 - Language Tags and Arrange in LDAP
RFC 3909 - LDAP Cancel Operation
RFC 3928 - LDAP Client Update Protocol
RFC 4370 - LDAP Proxied Authorization Control
RFC 4373 - LBURP
RFC 4403 - LDAP Schema for UDDI
RFC 4522 - LDAP: Binary Encoding Option
RFC 4523 - LDAP: X.509 Certificate Diagram
RFC 4524 - LDAP: COSINE Diagram (the RFC 1274 replaces)
RFC 4525 - LDAP: Modify-increment Extension
RFC 4526 - LDAP: Absolute True and False Filters
RFC 4527 - LDAP: Read Entry Controls
RFC 4528 - LDAP: Assertion Control
RFC 4529 - LDAP: Requesting Attributes by Object Class
RFC 4530 - LDAP: entryUUID
RFC 4531 - LDAP Turn Operation
RFC 4532 - LDAP Who amndt I? Operation
RFC 4533 - Content LDAP Sync Operation

LDAPv2 was defined by the RFC following:

RFC 1777 - Lightweight Directory Access Protocol (the RFC 1487 replaces)
RFC 1778 - The String Representation off Standard Attribute Syntaxes (the RFC 1488 replaces)
RFC 1779 - has String Representation Distinguished Names off (the RFC 1485 replaces)

LDAPv2 was moves in " Historic Status " by the RFC following:

RFC 3494 - Lightweight Directory Access Protocol version 2 (LDAPv2) to Historic Status

Other RFC:

RFC 2254 - The String Representation off LDAP Search Filters

Random links: