The book thus far has been focused on the LDAP services themselves. In this chapter we will look at integrating LDAP with other services. The focus of this chapter will be on integrating OpenLDAP and LDAP-enabled web services. The goal is not only to provide some concrete examples of certain web services, but also to give a general idea as to the common features of LDAP-enabled applications. We will make use primarily of the Apache web server, and of the phpLDAPadmin tool. In this chapter, we will cover the following topics:
We will conclude with some general guidance on integrating OpenLDAP and LDAP-aware applications.
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.
While there are many LDAP-aware applications, not all of them support the LDAP v3 protocol in spite of the fact that LDAP v3 has been around for a decade (see RFC 2251). Many LDAP-aware applications still use version 2 of the LDAP protocol, which lacks some important features, like StartTLS support and SASL binding.
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:
ldap URL (ldap://directory.example.com:389) or a host and port pair (host=directory.example.com, port=389).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.