1. Lightweight Directory Access Protocol
Introduction
Lightweight Directory Access Protocol,LDAP is an Internet protocol that email and other
programs use to look up information from a server.In computer networking, the
Lightweight Directory Access Protocol, or LDAP, is a networking protocol for querying
and modifying directory services running over TCP/IP. An LDAP directory usually
follows the X.500 model: it is a tree of entries, each of which consists of a set of named
attributes with values. While some services use a more complicated "forest" model, the
vast majority use a simple starting point for their database organization.
Its current version is LDAPv3. LDAPv3 is specified in a series of IETF Standard Track
RFCs as detailed in RFC 4510.
LDAP also defines:
1. Permissions: Permissions set by the administrator to optionally keep certain data
private.
2. Schema: A way to describe the format and attributes of data in the server
History
LDAP was designed at the University of Michigan to adapt a complex enterprise
directory system (called X.500) to the modern Internet. X.500 is too complex to support
on desktops and over the Internet, so LDAP was created to provide this service LDAP
provides low-overhead access to the X.500 directory. LDAP includes a subset of full
X.500 functionality. It runs directly over TCP and uses a simplified data representation
for many protocol elements. These simplifications make LDAP clients smaller, faster,
and easier to implement than full X.500 clients.

2. LDAP servers exist at three levels: There are big public servers, large organizational
servers at universities and corporations, and smaller LDAP servers for workgroups.
Every email program has a personal address book, but how do you look up an address for
someone who's never sent you email? How can an organization keep one centralized up-
to-date phone book that everybody has access to?
Directory structure
The protocol accesses LDAP directories, which follow the X.500 model:
1. A directory is a tree of directory entries.
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.
2. Each entry has a unique identifier: it’s 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 a full filename and
the RDN as a relative filename in a folder.
3. 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 may be provided in the set of the entry's operational attributes.
4. LDAP rarely defines any ordering: The server may return the values in an
attribute, the attributes in an entry, and the entries found by a search operation in
any order.

3. Relationship between LDAP and X.500
Figure 2. Relationship between LDAP and X.500
The LDAP client-server model includes an LDAP server translating LDAP requests into
X.500 requests, chasing X.500 referrals, and returning results to the client.
LDAP Operations
The client gives each request a positive Message ID, and the server response
has the same Message ID. The response includes a numeric result code indicating
success, some error condition or some other special cases. Before the response, the server
may send other messages with other result data - for example each entry found by the
Search operation is returned in such a message.
Stub for discussion of referral responses to various operations, especially modify, for
example where all modifies must be directed from replicas to a master directory.
The LDAP functional model is a subset of the X.500 model. LDAP supports the
following operations:
1. search
2. add
3. delete
4. modify
5. modify RDN
6. bind
7. unbind and
8. Abandon.

4. The search operation is similar to it’s DAP counterpart. The time and size
limit service controls are included directly in the search request. (They are not included
with the other operations.) The searchAliases search control and dereferenceAliases
service controls are combined in a single derefAliases parameter in the LDAP search.
Bind (authenticate):
The Bind operation authenticates the client to the server. Simple Bind sends
the user's DN and password - in clear text, so the connection should be protected using
Transport Layer Security (TLS). The server typically checks the password against the
user Password attribute in the named entry. Anonymous Bind (with empty DN and
password) resets the connection to anonymous state. SASL (Simple Authentication and
Security Layer) Bind provides authentication services through a wide-range of
mechanisms.e.g. Kerberos or the client certificate sent with TLS.
Bind also sets the LDAP protocol version. Normally clients should use
LDAPv3, which is the default in the protocol but not always in LDAP libraries.
StartTLS:
The StartTLS operation establishes Transport Layer Security (the descendant of SSL) on
the connection. That can provide data confidentiality (cannot be read by third parties)
and/or data integrity protection (protect from tampering). During TLS negotiation the
server sends its X.509 certificate to prove its identity. The client may also send a
certificate to prove its identity. After doing so, the client may then use
SASL/EXTERNAL to have this identity used in determining the identity used in making
LDAP authorization decisions.
Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly
known as "LDAP over SSL") protocol on a separate port, by default 636. The LDAPS
differs from LDAP in two ways: 1) upon connect, the client and server establish TLS
before any LDAP messages are transferred (without a Start TLS operation) and 2) the
LDAPS connection must be closed upon TLS closure.

5. Search and Compare:
The Search operation is used to both search for and read entries. Its parameters are:
1. Base Object - the DN (Distinguished Name) of the entry at which to start the
search,
2. Scope - base Object (search just the named entry, typically used to read one
entry), single Level (entries immediately below the base DN), or wholeSubtree
(the entire sub tree starting at the base DN).
3. Filter - how to examine each entry in the scope. E.g. (& (object Class=person)(|
(given Name=John)(mail=john*))) - search for persons who either have given
name John or an e-mail address starting with john.
4. derefAliases - whether and how to follow alias entries (entries which refer to
other entries),
5. Attributes - which attributes to return in result entries?
6. SizeLimit, time Limit - max number of entries, and max search time.
7. Types Only - return attribute types only, not attribute values.
The server returns the matching entries and maybe continuation references (in
any order), followed by the final result with the result code.
The Compare operation takes a DN, an attribute name and an attribute value,
and checks if the named entry contains that attribute with that value.
Update operations:
Add, Delete, and Modify DN - all require the DN of the entry that is to be changed.
1. Modify takes a list of attributes to modify and the modifications to each: Delete
the attribute or some values, add new values, or replace the current values with
the new ones.
2. Add operations also can have additional attributes and values for those attributes.

6. 3. Modify DN (move/rename entry) takes the new RDN (Relative Distinguished
Name), optionally the new parent's DN, and a flag which says whether to delete
the value(s) in the entry which match the old RDN. The server may support
renaming of entire directory sub trees.
An update operation is atomic: Other operations will see either the new entry or
the old one. On the other hand, LDAP does not define transactions of multiple operations:
If you read an entry and then modify it, another client may have updated the entry in the
mean time. Servers may implement extensions which support this, however.
Extended operations:
The Extended Operation is a generic LDAP operation which can be used to define new
operations. Examples include the Cancel, Password Modify and Start TLS operations.
Abandon:
The Abandon operation requests that the server aborts an operation named by a message
ID. The server need not honor the request. Unfortunately, neither Abandon nor a
successfully abandoned operation sends a response. A similar Cancel extended operation
has therefore been defined which does send responses, but not all implementations
support this.
Unbind:
The Unbind operation abandons any outstanding operations and closes the connection. It
has no response. The name is of historical origin: It is not the opposite of the Bind
operation.
Clients can abort a session by simply closing the connection, but they should use Unbind.
Otherwise the server cannot tell the difference between a failed network connection (or a
truncation attack) and a discourteous client.

7. About LDAP
"LDAP-aware" client programs can ask LDAP servers to look up entries in a wide variety
of ways. LDAP servers index all the data in their entries and "filters" may be used to
select just the person or group we want, and return just the information you want.
Example: If an LDAP search translated into plain English: "Search for all people located
in Chicago whose name contains "Fred" that have an email address. Then it returns their
full name, email, title, and description."
Origin and influences
LDAP was originally intended to be a lightweight alternative protocol for accessing
X.500 directory services. X.500 directory services were traditionally accessed via the
X.500 Directory Access Protocol, or DAP, which required the cumbersome Open
Systems Interconnection (OSI) protocol stack. With LDAP, a client could access these
directory services through an LDAP-to-DAP gateway. The gateway would translate
LDAP requests to DAP requests and DAP responses to LDAP. This model of directory
access was borrowed from DIXIE and the Directory Assistance Service.
Standalone LDAP directory servers soon followed, as did directory servers supporting
both DAP and LDAP. The former has become popular in enterprises as they removed any
need to deploy an OSI network. Today, X.500 directory protocols including DAP can
also be used directly over TCP/IP.
The protocol was originally created by Tim Howes of the University of Michigan, Steve
Kille of ISODE and Wengyik Yeong of Performance Systems International, circa 1993.
Further development has been done via the Internet Engineering Task Force
(IETF).
Note that in the early engineering stages of LDAP, it was known as Lightweight
Directory Browsing Protocol or LDBP. It was renamed as the scope of the protocol was

8. expanded to not only include directory browsing functions (e.g., search) but also
directory update functions (e.g., modify).
LDAP has influenced subsequent Internet protocols, including later versions of X.500,
XML Enabled Directory (XED), Directory Services Markup Language (DSML), Service
Provisioning Markup Language (SPML), and the Service Location Protocol (SLP).
LDAP Protocol
As a protocol, LDAP does not define how programs work on either the client or server
side. It defines the "language" used for client programs to talk to servers (and servers to
servers, too). On the client side, a client may be an email program, a printer browser, or
an address book. The server may speak only LDAP, or have other methods of sending
and receiving data—LDAP may just be an add-on method. A client starts an LDAP
session by connecting to an LDAP server, by default on TCP port 389. The client then
sends operation requests to the server, and the server sends responses in return. With
some exceptions the client need not wait for a response before sending the next request,
and the server may then send the responses in any order
The basic operations are, in order:
1. Bind - authenticate, and specify LDAP protocol version,
2. Start TLS - protect the connection with Transport Layer Security (TLS), to have a
more secure connection,
3. Search - search for and/or retrieve directory entries,
4. Compare - test if a named entry contains a given attribute value,
5. Add a new entry,
6. Delete an entry,
7. Modify an entry,
8. Modify DN - move or rename an entry,
9. Abandon - abort a previous request,

9. 10. Extended Operation - generic operation used to define other operations,
11. Unbind - close the connection, not the inverse of Bind.
Advantages & Disadvantages
Advantages:
LDAP has four key advantages over DAP.
1. First, it runs directly over TCP (or other reliable transport, in theory), eliminating
much of the connection set-up and packet-handling overhead of the OSI session
and presentation layers required by DAP. In addition, the near universal
availability of TCP/IP implementations means that LDAP can run on most
systems "out of the box."
2. Second, LDAP simplifies the X.500 functional model in two ways. It leaves out
the read and list operations, emulating them via the search operation. It also
leaves out some of the more esoteric and less-often-used service controls and
security features of full X.500 (e.g., the ability to sign operations). This simplifies
LDAP implementations.
3. Third, though X.500 and LDAP both describe and encode protocol elements using
ASN.1 and BER [12], LDAP uses string encodings for distinguished names and
data elements. X.500 uses a complex and highly-structured encoding even for
simple data elements; LDAP data elements are string types. This encoding is a big
win for distinguished names, which have considerable structure leading to
encoding/decoding complexity and size. LDAP relegates the knowledge of a
value's syntax to the application program rather than lower-level protocol
routines.
4. Finally, LDAP frees clients from the burden of chasing referrals. The LDAP
server is responsible for chasing down any referrals returned by X.500, returning
either results or errors to the client. Clients assume a single connection model in
which X.500 appears as a single logical directory.

10. Disadvantages:
If you have an email program (as opposed to web-based email), it probably
supports LDAP. Most LDAP clients can only read from a server. Search abilities of
clients (as seen in email programs) vary widely. A few can write or update information,
but LDAP does not include security or encryption, so updates usually require additional
protection such as an encrypted SSL connection to the LDAP server.
Architecture Of Apache Directory Server
Here the primary vision is to build an enterprise directory server platform (and its
components) where other Internet services snap in to store their data within the directory
so they may be managed using LDAP. From the image above you'll see the architecture
is designed so services besides LDAP like DNS, DHCP, SLP and Kerberos will snap in.

11. Other services like UDDI can also be implemented and snapped in. These services will
use a common networking layer and each can be toggled on and off according to the
needs of the environment. Apseda, mina, or sedang are various frameworks used for the
common network layer. These services share the common network layer and back their
data within the Apache Directory Server's backing stores without any network latency or
going through the LDAP line protocol. NTP btw is the only exception and it's there to
remedy the need for time sync for replication and other time sensitive protocols like
Kerberos.
Security
With such a concentration of data in the directory, security becomes very
important. Anyone who could modify the data could give themselves access to vast
numbers of machines at a stroke. Some data needs to be protected from unauthorized
viewing: although all passwords are hashed, anyone who can read the hashes can mount a
dictionary attack. More subtly, anyone who can hijack a client-server connection can feed
bogus data to an individual client, or use the client's privileges to modify server data. All
these things can be protected against, and LDAP now has most of the tools needed to do
it.
Terminology
Beware: The LDAP terminology one can encounter is quite a mess. Some of this is due to
misunderstandings, other examples are due to its historical origins, others arise when
used with non-X.500 services that use different terminology.
For example, "LDAP" is sometimes used to refer to the protocol, other times to the
protocol and the data. An "LDAP directory" may be the data or also the access point. An
"attribute" may be the attribute type, or the contents of an attribute in a directory, or an
attribute description (an attribute type with options). An "anonymous" and an
"unauthenticated" Bind are different Bind methods that both produce anonymous
authentication state, so both terms are being used for both variants. The "uid" attribute
should hold user names rather than numeric user IDs.

12. Tips for LDAP Users
The ‘Comparison of the LDAP and JNDI Models’ lesson gives an overview of the
LDAP and describes the differences and similarities between the JNDI and the LDAP.
The ‘Security’ lesson shows how to use different security authentication mechanisms
and SSL (Secure Socket Layer) to access the LDAP service.
The ‘Searches’ lesson explains search filters in more detail. It also explains how the
LDAP "compare" operation relates to the JNDI search methods and how the LDAP
"search" operation is related to other JNDI methods.
The ‘Schema’ lesson describes schema information that is available from the LDAP and
how it can be accessed from the JNDI.
The ‘Controls and Extensions' lesson describes how to use LDAP controls and
extensions
Supporting vendors
LDAP has gained wide support from vendors such as:
1. Apache (through Apache Directory Server)
2. Apple (through Open Directory/Open DAP)
3. AT&T
4. Avaya (through Directory Enabled Management)
5. Banyan
6. Cisco
7. Critical Path
8. eB2Bcom (through View500)
9. Red Hat through Fedora Directory Server aka Red Hat Directory server

13. 10. Hewlett-Packard
11. Identyx
12. IBM/Lotus
13. ISODE (through M-Vault server)
14. MaXware (through MaXware Virtual Directory)
15. Microsoft (through Active Directory)
as well as in open source/free software implementations such as OpenLDAP and Fedora
Directory Server. Also the Apache HTTP Server used as a proxy (by the module
mod_proxy) supports LDAP.

14. LDAP Implementations
In setting out to implement LDAP we had three goals in mind.
1. Provide a freely available reference implementation of the protocol;
2. Enable the development of LDAP clients on a wide variety of platforms;
3. Solve the problem of providing access to our campus X.500 directory
In addition, we have found our implementation has been incorporated into a number of
vendor offerings, increasing the availability of LDAP product.
Our LDAP implementation has three main components: a server, a client library, and
various clients. Our LDAP server, ldapd, is based on the popular ISO Development
Environment (ISODE) package. We use the ISODE OSI stack implementation and DAP
client library to access X.500. The ldapd server supports connections to multiple X.500
servers, providing efficient handling of referrals.
The ldapd server can be run as a UNIX stand-alone daemon or from inetd, the UNIX
Internet protocol daemon. It accepts connections from LDAP clients, forking off a copy
of itself to handle each connection. It also supports connectionless LDAP (CLDAP) a
version of LDAP that runs over UDP or other connectionless transport. CLDAP is useful
in applications where speed is paramount, the information desired is small, and the
connection setup overhead of LDAP is too large.
Key to the success of our LDAP implementation has been libldap, the LDAP client
library. The libldap library gives programmers a simple yet powerful C Language API for
accessing the X.500 directory through LDAP. The library is self-contained, including the
necessary ASN.1/BER routines for producing and reading LDAP protocol elements. It
contains routines to begin and end sessions with the directory, perform searches and other
operations, and parse and display the results obtained from the directory. Figure is a C
code fragment showing a simple use of libldap. It illustrates the synchronous interface
provided by libldap.
Asynchronous routines are also provided
1. Apache Directory Server

15. 2. Critical Path Directory Server and Meta Directory Server
3. Fedora Directory Server
4. Red Hat Directory Server
5. OpenLDAP
6. Novell eDirectory
7. Sun Directory Server Enterprise Edition
8. IBM Secure Way Directory
Performance
The performance of LDAP is satisfactory for most applications. In this section, we
compare the performance of DAP and LDAP in four areas: response time to
queries; the size of queries; PDU encoding speed; and the size and complexity of
client-side implementations. For these comparisons, we used our LDAP
implementation and the ISODE DAP implementation. The same DSA was used
for all query measurements, providing a baseline for comparison.
Variations
A lot of the server operation is left to the implementer or administrator to decide.
Accordingly, servers may be set up to support a wide variety of scenarios.
For example, data storage in the server is not specified - the server may use flat files,
databases, or just be a gateway to some other server. Access control is not standardized,
though there has been work on it and there are commonly used models. Users' passwords
may be stored in their entries or elsewhere. The server may refuse to perform operations
when it wishes, and impose various limits.
Most parts of LDAP are extensible. Examples: One can define new operations. Controls
may modify requests and responses, e.g. to request sorted search results. New search
scopes and Bind methods can be defined. Attributes can have options that may modify
their semantics.

16. Other data model
As LDAP has gained momentum, vendors have provided it as an access protocol to other
services. The implementation then recasts the data to mimic the LDAP/X.500 model, but
how closely this model is followed varies. For example, there is software to access SQL
databases through LDAP, even though LDAP does not readily lend itself to this. X.500
servers may support LDAP as well.
Similarly, data which were previously held in other types of data stores are sometimes
moved to LDAP directories. For example, UNIX user and group information can be
stored in LDAP and accessed via PAM and NSS modules. LDAP is often used by other
services for authentication.
Conclusion
The Lightweight Directory Access Protocol provides a low-overhead method of
accessing the X.500 directory. It runs directly over TCP, and makes several
simplifications to full X.500 DAP, leaving out many of the lesser-used features. LDAP
uses primitive string encodings for most data elements, making it more efficient and
easier to implement than DAP. We have developed a freely available reference
implementation of LDAP which has been ported to several platforms, including UNIX,
VMS, PC, and Macintosh. Our intermediate-server-based implementation introduces
little delay over full DAP, produces smaller protocol exchanges, and results in smaller
and less complex clients. Our implementation is freely available.

17. BIBILIOGRAPHY
1. http://www.itu.ch/
2. http://www.wikipedia.com
3. http://www.Google.co.in
4. http://www.howstuff.com