| Lightweight Directory Access Protocol |
Article Index for Lightweight |
Shopping Protocol |
Website Links For Lightweight |
Information AboutLightweight Directory Access Protocol |
| CATEGORIES ABOUT LIGHTWEIGHT DIRECTORY ACCESS PROTOCOL | |
| internet protocols | |
| internet standards | |
| identity management | |
| application layer protocols | |
|
An LDAP directory often reflects various political, geographic, and/or organizational boundaries, depending on the model chosen. LDAP deployments today tend to use Domain Name System (DNS) names for structuring the most simple levels of the hierarchy. Further into the directory might appear entries representing people, organizational units, printers, documents, groups of people or anything else which represents a given tree entry, or multiple entries. Its current version is LDAPv3, as defined in RFC 3377. 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 a 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 be also 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). It is noted 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 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) . PROTOCOL OVERVIEW 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:
In addition the server may send "Unsolicited Notifications" that are not responses to any request, e.g. before it times out a connection. LDAP is defined in terms of ASN.1 , and protocol messages are encoded in the binary format BER . It uses textual representations for a number of ASN.1 fields/types, however. DIRECTORY STRUCTURE The protocol accesses LDAP directories, which follow the X.500 model: 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'' (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 a full filename and the RDN as a relative filename in a folder. 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, an UUID is provided in the set of the entry's ''operational attributes''. An entry can look like this when represented in LDIF format (LDAP itself is a binary protocol): dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: +1 555 6789 telephoneNumber: +1 555 1234 mail: john@example.com manager: cn=Barbara Doe,dc=example,dc=com objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top dn is the name of the entry; it's not an attribute nor part of the entry. "cn=John Doe" is the entry's RDN, and "dc=example,dc=com" is the DN of the parent entry. The other lines show the attributes in the entry. Attribute names are typically mnemonic strings, like "cn" for common name, "dc" for domain component, and "mail" for e-mail address. 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=Some department,dc=example,dc=com" could return a ''referral'' or ''continuation reference'' to a server which 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 in an attribute, the attributes in an entry, and the entries found by a search operation in any order. 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. Bind (authenticate) The Bind operation authenticates the client to the server. Simple Bind sends the user's DN and password - in cleartext, so the connection should be protected using Transport Layer Security (TLS). The server typically checks the password against the userPassword 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. Start TLS The Start TLS operation establishes Transport Layer Security (the descendant of SSL) on the connection. That can provide data confidentiality protection (hide the data) 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. Search and Compare The Search operation is used to both search for and read entries. Its parameters are:
|
|
|