What does it mean to say of an application that it is LDAP-aware? An LDAP-aware application is an application that can make use of directory information by contacting a directory server over the LDAP protocol and performing LDAP operations.
While the most common use of directory services is authentication, it is certainly not the only thing LDAP can be used for. Some DNS servers use a directory server to store zone information. Sendmail and Postfix can use LDAP to store information on mail routing. Mozilla Thunderbird, Microsoft Outlook, and many other mail clients treat LDAP servers as address books. All of these applications are rightly considered LDAP-enabled applications.
The common feature of an LDAP-enabled application is the ability to connect to and bind to a directory server. And this is the feature that most often requires configuration. For that reason, most LDAP-enabled applications will need at minimum the following pieces of information:
A DN that will be used to bind to the directory.
A password to use when binding.
Information about the location of the LDAP server. This may be in the form of an
ldap://directory.example.com:389) or a host and port pair (
Some applications may need additional info, such as a search filter or a list of attributes to request.
Of course, asking users to remember a full DN when they are normally accustomed to remembering only a login ID might not be a successful strategy. For this reason, many LDAP-enabled applications will use the traditional two-stage authentication, consisting of performing two simple binds.
Such an application will prompt a user for a login ID (usually mapped to the
uid attribute in OpenLDAP) and a password. Then, the application will bind as an initial DN (often this DN will be anonymous), and then perform a search for the specified login attribute, in order to get the full DN. Then, the application will rebind with the newly-located DN and the user’s supplied password.
In this case, the application itself is not doing the password verification. It sends the password to the directory server, and the directory server does the appropriate authentication.
In rarer cases, applications may attempt a SASL bind instead of a simple bind. Then the application will not need the full DN. Instead, it will just need the SASL-specific information for the user (such as login ID and password for DIGEST-MD5, or an X.509 certificate for the SASL EXTERNAL mechanism).
Applications that just use LDAP for authentication usually only need to perform the bind operation (or operations). Once the application knows that the user can successfully bind, the application has found out all it needs to know from the LDAP server.
Other applications (such as an address book or a DNS server) may continue to interact with the LDAP server to perform searches, or even to change the directory information tree.
In this chapter we will first look at the Apache web server’s ability to use OpenLDAP as an authentication source. Then we will move on to services that perform more substantial interactions with the directory server.