The LDAP-Aware Application

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 URL (ldap:// or a host and port pair (, port=389).

Some applications may need additional info, such as a search filter or a list of attributes to request.


If the DN is for the Anonymous user (which is an empty string), then password must not be set.

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 Chapter 5, we covered the different methods of binding to OpenLDAP.

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.

Related Articles

How to add swap space on Ubuntu 21.04 Operating System

How to add swap space on Ubuntu 21.04 Operating System

The swap space is a unique space on the disk that is used by the system when Physical RAM is full. When a Linux machine runout the RAM it use swap space to move inactive pages from RAM. Swap space can be created into Linux system in two ways, one we can create a...

read more

Lorem ipsum dolor sit amet consectetur


Submit a Comment

Your email address will not be published. Required fields are marked *

thirteen − two =