Lightweight Directory Access Protocol (LDAP) By Raghavendra Aekka Professor Dr. Ravi Mukkamala

Directory Service What is a Directory Service ? A Directory Service (DS) is a software application or a set of applications that store and organize information about a computer network's users and network resources, and that allows network administrators to manage user’s access to the resources. Sun Java System Directory Server Active Directory for Windows 2000,Server 2003 Directory Services act as an abstraction layer between users and shared resources.

Differences Differences between Directories and Databases directories are organized hierarchically directories are optimized for lookups (searching and reading information) directories have a much higher read-to-write ratio directories do not support secure transaction mechanisms directories are more easily extended support for standards is more important in directories

Lightweight Directory Access Protocol The Lightweight Directory Access Protocol, or LDAP, is an application protocol for querying and modifying directory services running over TCP/IP. A descendent of X.500 OSI Directory Access Protocol, which was deemed too complex and cumbersome to be implemented on microcomputers A data-representation model optimized for arbitrary queries Recent versions of LDAP also specify encryption methods, methods for clients to discover the structure of the system's configuration, as well interoperability with other services such as Kerberos and SASL

Directory structure 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. Each entry has a unique identifier: Distinguished Name (DN). Relative Distinguished Name (RDN) constructed from some attribute(s) in the entry, The parent entry's DN. Think of the DN as a full filename and RDN as a relative filename in a folder.

Directory structure An entry can look like this when represented in LDAP Data Interchange Format (LDIF) (LDAP itself is a binary protocol): dn: cn=John Doe,dc=example,dc=com cn: John Doe givenName: John sn: Doe telephoneNumber: telephoneNumber: mail: 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, "mail" for address and "sn" for surname.

Directory Structure

Distinguished Name (DN) In each base DN, each RDN is unique

Referral 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 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.

Reference to Other Servers

Operations The client gives each request a positive Message ID The server response has the same Message ID. The response includes a numeric result code which indicates 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.

Operations Start TLS Bind Search Compare Add a new entry Delete an entry Modify an entry Modify Distinguished Name (DN) Abandon Extended Operation Unbind

Operations – START TLS 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. 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. LDAPS was primarily used with LDAPv2, because the StartTLS operation had not yet been defined.

Operations – Bind (authenticate) The Bind operation authenticates the client to the server. Simple Bind can send the user's DN and password in plaintext, 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. Bind had to be the first operation in a session in LDAPv2, but is not required in LDAPv3 (the current LDAP version).

Operations – Search and Compare The Search operation is used to both search for and read entries. baseObject The DN (Distinguished Name) of the entry at which to start the search, scope BaseObject SingleLevel wholeSubtree filter How to examine each entry in the scope. E.g. (&(objectClass=person)(|(givenName=John)(mail=john*))) - search for persons who either have given name John or an address starting with john. derefAliases Whether and how to follow alias entries (entries which refer to other entries), attributes Which attributes to return in result entries. sizeLimit, timeLimit Max number of entries, and max search time. typesOnly 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.

Base Scope One Level Scope Subtree Scope Scope

LDAP Search Flow

Update operations Add, Delete, and Modify DN all require the DN of the entry that is to be changed. 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. Add operations also can have additional attributes & values for those attributes. 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. 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.

Operations 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 send 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.

LDAP Security Authentication Assurance that the opposite party (machine or person) really is who he/she/it claims to be. Integrity Assurance that the information that arrives is really the same as what was sent. Confidentiality Protection of information disclosure by means of data encryption to those who are not intended to receive it. Authorization Assurance that a party is really allowed to do what he/she/it is requesting to do. This is usually checked after user authentication. In LDAP Version 3, this is currently not part of the protocol specification and is therefore implementation- (or vendor-) specific.

LDAP Security Security Issues A normal LDAPv2 or LDAPv3 connection works by the client connecting directly to port 389 (by default), and then issuing various LDAP requests like search, add, etc. There is no way to guarantee that an LDAP client is connected to the right LDAP server. Hackers could have poisoned the DNS, so 'ldap.example.com' could be made to point to 'ldap.hacker.com‘ or they could have installed their own server on the correct machine. It is in the nature of the LDAP protocol that all information goes between the client and the server in 'plain text'. This is a term used by cryptographers to describe unencrypted and recoverable data, so even though LDAP can transfer binary values like JPEG photographs, audio clips and X.509 certificates, everything is still considered 'plain text'. If these vulnerabilities are an issue to, then you should consider the other possibilities described below, namely LDAPS, LDAPv3 and TLS, and SASL.

LDAP Security There are several methods that can be used for implementing the aspects of authentication, integrity and confidentiality No authentication Basic authentication Secure Lightweight Directory Access Protocol (LDAPS)

LDAP Security : No Authentication This method should only be used when data security is not an issue and when no special access control permissions are involved. For example, when your directory is an address book browsable by anybody. No authentication is assumed when you leave the password and DN field empty in the bind API call The LDAP server then automatically assumes an anonymous user session and grants access with the appropriate access controls defined for this kind of access

LDAP Security : Basic Authentication The security mechanism in LDAP is negotiated when the connection between the client and the server is established. This is the approach specified in the LDAP application program interface(API). Beside the option of using no authentication at all, the most simple security mechanism in LDAP is called basic authentication, which is also used in several other Web-related protocols, such as in HTTP. When using basic authentication with LDAP, the client identifies itself to the server by means of a DN and a password which are sent in the clear over the network (some implementation may use Base64 encoding instead). The server considers the client authenticated if the DN and password sent by the client matches the password for that DN stored in the directory.

LDAP Security : LDAPS LDAPS is an unofficial protocol. It is to LDAP what HTTPS is to HTTP, namely the exact same protocol (but in this case LDAPv2 or LDAPv3) running over a secured SSL ("Secure Socket Layer") connection to port 636 (by default). Not all servers will be configured to listen for LDAPS connections, but if they do, it will commonly be on a different port from the normal plain text LDAP port. Using LDAPS can potentially solve the vulnerabilities described above First of all, LDAPS can solve the problem of verifying that you are connected to the correct server. When the client and server connect, they perform a special SSL 'handshake', part of which involves the server and client exchanging cryptographic keys, which are described using X.509 certificates. If the client wishes to confirm that it is connected to the correct server, all it needs to do is verify the server's certificate which is sent in the handshake.

LDAP Security : LDAPS This is done in two ways: check that the certificate is signed (trusted) by someone that you trust, and that the certificate hasn't been revoked. For instance, the server's certificate may have been signed by Verisign ( and you decide that you want to trust Verisign to sign legitimate certificates. check that the least-significant cn RDN in the server's certificate's DN is the fully-qualified hostname of the hostname that you connected to when creating the LDAPS object. For example if the server is, then the RDN to check is cn=ldap.example.com.

LDAP Security : Simple Authentication and Security Layer (SASL) SASL is a framework for adding additional authentication mechanisms to connection-oriented protocols. It has been added to LDAP Version 3 to overcome the authentication shortcomings of Version 2. In SASL, connection protocols, like LDAP, IMAP, and so on, are represented by profiles; each profile is considered a protocol extension that allows the protocol and SASL to work together. A complete list of SASL profiles can be obtained from the Information Sciences Institute (ISI). Each protocol that intends to use SASL needs to be extended with a command to identify an authentication mechanism and to carry out an authentication exchange. Optionally, a security layer can be negotiated to encrypt the data after authentication and so ensure confidentiality.

LDAP Security : Simple Authentication and Security Layer (SASL) Through the SASL bind API function call, LDAP client applications call the SASL protocol driver on the server, which in turn connects the authentication system named in the SASL mechanism to retrieve the required authentication information for the user. SASL can be seen as intermediator between the authentication system and a protocol like LDAP. Of course, the server must support this SASL mechanism as well, otherwise the authentication process will not be able to succeed. The basic idea behind SASL is that it provides a high level framework that lets the involved parties decide on the particular security mechanism to use. The SASL security mechanism negotiation between client and server is done in the clear.

LDAP Security : Simple Authentication and Security Layer (SASL) Once the client and the server have agreed on a common mechanism, the connection is secure against modifying the authentication identities. An attacker could now try to eavesdrop the mechanism negotiation and cause a party to use the least secure mechanism. In order to prevent this from happening, clients and servers should be configured to use a minimum security mechanism, provided they support such a configuration option. SSL / TLS, Kerberos are the mechanisms commonly used in SASL for LDAP

LDAP Security : Simple Authentication and Security Layer (SASL)

References Wikepedia Understanding LDAP Heinz Johner, Larry Brown, Franz-Stefan Hinner, Wolfgang Reis, Johan Westman An Introduction To LDAP LDAPV3