Lightweight Directory Access Protocol
Lightweight Directory Access Protocol (LDAP), while not unique to Exchange 2000 Server, is still a foundational protocol without which it could not operate. LDAP has its roots in the X.500 Directory services and was first defined in RFC 1487. By now LDAP has been through three revisions, and the current standard is defined in RFC 2251.
The X.500 Directory Access Protocol (DAP) originally required an OSI stack. The current version of LDAP runs over TCP/IP and is thus more adaptable in today's market. In addition, an LDAP server can query a non-LDAP server. Earlier versions of LDAP provided for a client to send queries to a front-end processor at the server that converted the LDAP query to a DAP query and presented that to the server. Version 3 no longer requires this conversion. Moreover, earlier versions of LDAP specified the object classes and attributes as part of the protocol, making the directory static and nonextensible. With LDAP version 3, clients can query a server to discover the object classes and attributes, and the protocol no longer defines what you have come to know as the schema.
LDAP version 3 also allows for X.509 certificates as well as Connectionless LDAP (CLDAP), which is well suited for applications that need to make simple queries and get fast responses. CLDAP uses user datagram protocol (UDP) as the transport protocol at the transport layer.
In LDAP version 3, the client transmits a request to the server describing the query to be performed on the directory. The server performs the query and return the results to the client. There is no requirement in the RFC for synchronous behavior by either the server or the client, which means that multiple requests and responses may be passed between the client and server in any order, provided that the client eventually receives a response for every request.
An LDAP client assumes that there are one or more servers that jointly provide access to a Directory Information Tree (DIT). The tree is composed of entries with names, each of which must have one or more attribute values that form its Relative Distinguished Name (RDN), which must be unique among all its siblings. The concatenation of the object hierarchy names above the RDN form the entry's Distinguished Name (DN), which is, by default, unique in the tree. An example of a DN is: CN=Bill English,DC=HR, DC=Oaktree,DC=com
Each attribute is actually a set of attributes, each of which is a defined type that has one or more associated values. The attribute type is identified by a short, descriptive name and an Object Identifier (OID). The attribute type governs whether there can be more than one value entered in a given attribute field, what rules the syntax must conform to, and other functions. The schema is a collection of attribute type definitions, object class definitions, and other information.
An LDAP server must provide information about itself and other LDAP servers hosting the same directory. This information is represented as a group of attributes located in the root DSA-Specific Entry (DSE), which is named with the zero-length LDAPDN. You can retrieve these attributes by performing a base object search of the root with the filter "objectClass=*". The root DSE must not be included if the query performed is focused on a subtree as its starting point.
All message exchanges are encapsulated in a common envelope, the LDAPMessage. The only common fields in the envelope are the message ID and the controls. The following list offers the commands for LDAP version 3 that are sent inside the LDAPMessage:
If the LDAP search is operating over a connection-oriented transport such as TCP, the server will return a sequence of responses in separate LDAP messages containing zero or more SearchResultEntry responses, one for each entry found during the search. The client will know that all the results have been returned by the server when the server sends the SearchResultDone message. Each entry in a SearchResultEntry will contain all the attributes specified in the field of the search request. Return of any attribute is subject to access control and other administrative policies.
EAN: N/A
Pages: 193