LDAP ( Lightweight Directory Access Protocol )

• All protocol elements of LDAPv2 are supported.



• The protocol is carried directly over TCP or other transport, bypassing much of the session/presentation overhead of X.500 DAP.



• Most protocol data elements can be encoded as ordinary strings.



• Referrals to other servers may be returned.



• SASL mechanisms may be used with LDAP to provide association security services.



• Attribute values and Distinguished Names have been internationalized through the use of the ISO 10646 character set.



• The protocol can be extended to support new operations, and controls may be used to extend existing operations.



• Schema is published in the directory for use by clients.

• Protocol Model
  The general model adopted by this protocol is one of clients performing protocol operations against servers. In this model, a client transmits a protocol request describing the operation to be performed to a server. The server is then responsible for performing the necessary operation(s) in the directory. Upon completion of the operation(s), the server returns a response containing any results or errors to the requesting client.
  
  In LDAP versions 1 and 2, no provision was made for protocol servers returning referrals to clients. However, for improved performance and distribution this version of the protocol permits servers to return to clients referrals to other servers. This allows servers to offload the work of contacting other servers to progress operations.
  
  Note that the core protocol operations defined in this document can be mapped to a strict subset of the X.500(1997) directory abstract service, so it can be cleanly provided by the DAP. However there is not a one-to-one mapping between LDAP protocol operations and DAP operations: server implementations acting as a gateway to X.500 directories may need to make multiple DAP requests.



• Data Model
  The LDAP protocol assumes there are one or more servers which jointly provide access to a Directory Information Tree (DIT). The tree is made up of entries. Entries have names: one or more attribute values from the entry form its relative distinguished name (RDN), which MUST be unique among all its siblings. The concatenation of the relative distinguished names of the sequence of entries from a particular entry to an immediate subordinate of the root of the tree forms that entry's Distinguished Name (DN), which is unique in the tree.
  
  An example of a Distinguished Name is CN=Steve Kille, O=Isode Limited, C=GB



• Relationship to X.500
  This document defines LDAP in terms of X.500 as an X.500 access mechanism. An LDAP server MUST act in accordance with the X.500(1993) series of ITU recommendations when providing the service. However, it is not required that an LDAP server make use of any X.500 protocols in providing this service, e.g. LDAP can be mapped onto any other directory system so long as the X.500 data and service model as used in LDAP is not violated in the LDAP interface.



• Server-specific Data Requirements
  An LDAP server MUST provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE (DSA-Specific Entry), which is named with the zero-length LDAPDN. These attributes are retrievable if a client performs a base object search of the root with filter "(objectClass=*)", however they are subject to access control restrictions. The root DSE MUST NOT be included if the client performs a subtree search starting from the root.

• Common Elements
  LDAPMessage envelope PDU (Protocol Data Unit) format, as well as data type definitions which are used in the protocol operations.



• Bind Operation
  The function of the Bind Operation is to allow authentication information to be exchanged between the client and server.
  The Bind Request is defined as follows:
  
  

            BindRequest ::= [APPLICATION 0] SEQUENCE {
  
              version       INTEGER (1 .. 127),
  
              name        LDAPDN,
  
              authentication    AuthenticationChoice }
  
  
  
           AuthenticationChoice ::= CHOICE {
  
              simple      [0] OCTET STRING,
  
                       -- 1 and 2 reserved
  
              sasl        [3] SaslCredentials }
  
  
  
            SaslCredentials ::= SEQUENCE {
  
              mechanism     LDAPString,
  
              credentials     OCTET STRING OPTIONAL }




• Unbind Operation
  The function of the Unbind Operation is to terminate a protocol session. The Unbind Operation is defined as follows:
  UnbindRequest ::= [APPLICATION 2] NULL
  
  The Unbind Operation has no response defined. Upon transmission of an UnbindRequest, a protocol client may assume that the protocol session is terminated. Upon receipt of an UnbindRequest, a protocol server may assume that the requesting client has terminated the session and that all outstanding requests may be discarded, and may close theconnection.



• Unsolicited Notification
  An unsolicited notification is an LDAPMessage sent from the server to the client which is not in response to any LDAPMessage received by the server. It is used to signal an extraordinary condition in the server or in the connection between the client and the server. The notification is of an advisory nature, and the server will not expect any response to be returned from the client.
  
  The unsolicited notification is structured as an LDAPMessage in which the messageID is 0 and protocolOp is of the extendedResp form. The responseName field of the ExtendedResponse is present. The LDAPOID value MUST be unique for this notification, and not be used in any other situation.



• Search Operation
  The Search Operation allows a client to request that a search be performed on its behalf by a server. This can be used to read attributes from a single entry, from entries immediately below a particular entry, or a whole subtree of entries.

Suppose the contacted server (hosta) holds the entry "O=MNN,C=WW" and the entry 

"CN=Manager, O=MNN,C=WW". It knows that either LDAP-capable servers (hostb) or 

(hostc) hold "OU=People, O=MNN, C=WW" (one is the master and the other server a 

shadow), and that LDAP-capable server (hostd) holds the subtree "OU=Roles, O=MNN,

C=WW". If a subtree search of "O=MNN,C=WW" is requested to the contacted server, it 

may return the following:



          SearchResultEntry for O=MNN,C=WW

          SearchResultEntry for CN=Manager,O=MNN,C=WW

          SearchResultReference {

            ldap://hostb/OU=People,O=MNN,C=WW

            ldap://hostc/OU=People,O=MNN,C=WW

          }

        SearchResultReference {

            ldap://hostd/OU=Roles,O=MNN,C=WW

          }

          SearchResultDone (success)



Client implementors should note that when following a SearchResultReference, additional 

SearchResultReference may be generated. Continuing the example, if the client contacted 

the server(hostb) and issued the search for the subtree "OU=People, O=MNN,C=WW", 

the server might respond as follows:



          SearchResultEntry for OU=People,O=MNN,C=WW

          SearchResultReference {

           ldap://hoste/OU=Managers,OU=People,O=MNN,C=WW

          }

          SearchResultReference {

           ldap://hostf/OU=Consultants,OU=People,O=MNN,C=WW

          }

          SearchResultDone (success)



If the contacted server does not hold the base object for the search, then it will 

return a referral to the client.  For example, if the client requests a subtree 

search of "O=XYZ, C=US" to hosta, the server may return only a SearchResultDone 

containing a referral.



          SearchResultDone (referral) {

            ldap://hostg/

          }

■ Parent layer
■ Child layer

TCP/UDP

LDAP