Lightweight Directory Access Protocol (LDAP) is an application protocol for accessing and maintaining distributed directory information services overn an Internet Protocol Network. The Directory services may provide any organized set of records, often with hirearchical structure, such as corporate email directory. Similarly, a telephone directory is a list of subscribers with an address and a phone number. Another example can be found on college where each student has unique student-ID and sort of informations.
LDAP is specified in a series of Internet Engineering Task Force (IETF) Standard Track RFC, using description language ASN.1. The latest specification is version 3 and published as RFC 4511.
Origins and Early Development
Telecommunication companies’ undestanding of directory requirements was well developed after some 70 years of producing and managing telephone directories. These companies then introduced the concept of the directory services to IT-based and culminating in the comprehensive X.500 specification, a suit of protocols produced by the International Telecommunication Union (ITU) in the 1980s.
X.500 directory services were traditionally accessed via X.500 Directory Access Protocol (DAP), which required the OSI protocol stack. LDAP was originally intended to be a lightweight alternative protocol for accessing X.500 directory services through the simpler TCP/IP protocol stack. This model of directory access was borrowed from the DIXIE and Directory Assistance Service protocols.
The protocol was originally created by Tim Howes of the University of Michigan, Steve Kille of Isode Limited, Collin Robbins of Nexor, and Wengyik Yeong of Performance Systems International.
In the early times, LDAP was known as Lightweight Directory Browsing Protocol, or LDBP. It was then renamed with the expansion of the scope of the protocol beyond directory browsing and searching, to include directory update funtions. The name Lightweight was given as it was not as network intensive as its DAP predecessor and thus was more easily implemented over the internet due to its relatively modest bandwidth usage.
LDAP has influenced subsequenct Internet protocols, including later version of X.500, XML Enabled Directory (XED), Directory Service Markup Language (DSML), Service Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).
A client starts an LDAP session by connecting to an LDAP server, called a Directory System Agent (DSA), by default on TCP port 389. The client then sends an operation request to the server, and the server sends responses in return. With some exceptions, the client does not need to wait for a response before sending the next request, and the server may send the responses in any order. All information is transmitted using Basic Encoding Rules (BER).
The client may request the following operations:
- StartTLS — use the LDAPv3 Transport Layer Security (TLS) extension for a secure connection
- Bind — authenticate and specify LDAP protocol version
- Search — search for and/or retrieve directory entries
- Compare — test if a named entry contains a given attribute value
- Add a new entry
- Delete an entry
- Modify an entry
- Modify Distinguished Name (DN) — move or rename an entry
- Abandon — abort a previous request
- Extended Operation — generic operation used to define other operations
- Unbind — close the connection (not the inverse of Bind)
In addition the server may send “Unsolicited Notifications” that are not responses to any request, e.g. before the connection is timed out.
A common alternative method of securing LDAP communication is using an SSL tunnel. This is denoted in LDAP URLs by using the URL scheme “ldaps”. The default port for LDAP over SSL is 636. The use of LDAP over SSL was common in LDAP Version 2 (LDAPv2) but it was never standardized in any formal specification. This usage has been deprecated along with LDAPv2, which was officially retired in 2003
The protocol provides an interface with directories which follow the 1993 edition of the X.500 model:
- An entry consists of a set of attributes.
- An attribute has a name (an attribute type or attribute description) and one or more values. The attributes are defined in a schema (see below).
- Each entry has a unique identifier: its Distinguished Name (DN). This consists of its Relative Distinguished Name (RDN), constructed from some attribute(s) in the entry, followed by the parent entry’s DN. Think of the DN as the full file path and the RDN as its relative filename in its parent folder (e.g. if
/foo/bar/myfile.txtwere the DN, then
myfile.txtwould be the RDN).
Be aware that a DN may change over the lifetime of the entry, for instance, when entries are moved within a tree. To reliably and unambiguously identify entries, a UUID might be provided in the set of the entry’s operational attributes.
An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (while LDAP itself is a binary protocol):
dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 888 555 6789 telephoneNumber: +1 888 555 1232 mail: [email protected] manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top
dn” is the distinguished name of the entry; it is neither an attribute nor a part of the entry. “
cn=John Doe” is the entry’s RDN (Relative Distinguished Name), and “
dc=example,dc=com” is the DN of the parent entry, where “
dc” denotes ‘Domain Component’. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like “
cn” for common name, “
dc” for domain component, “
sn” for surname.
A server holds a subtree starting from a specific entry, e.g. “
dc=example,dc=com” and its children. Servers may also hold references to other servers, so an attempt to access “
ou=department,dc=example,dc=com” could return a referral or continuation reference to a server that holds that part of the directory tree. The client can then contact the other server. Some servers also support chaining, which means the server contacts the other server and returns the results to the client.
LDAP rarely defines any ordering: The server may return the values of an attribute, the attributes in an entry, and the entries found by a search operation in any order. This follows from the formal definitions – an entry is defined as a set of attributes, and an attribute is a set of values, and sets need not be ordered.
Most people said, LDAP is one of many protocol having many confusing terminologies. One should understand LDAP terminologies to operate LDAP well. The terminologies might many, but it should be obvious when we have know it.
Light Directory Access Protocol, as the name said, is consists of directories. Directories are collection of object having each attributes composed in hierarchical form. They are represented as nodes of the tree, just like directory in UNIX.
Data or informations are stored inside of hierarchical directories, forming a tree. This tree is referred as Data Information Tree (DIT). In topmost level / the root, there is an object called as suffix and others object of the tree are stored inside of suffix.
Every entry in the tree have only one parent object / entry. Every entry might not have child entry or it can also has one or more entries as children. Each entry which has the same parent is called siblings.
Every entry is an instance of one or more object class. Object class is can have one or more attributes. Attribute has name and value. The concept is similar to object in real world.ldap, server