Configuring the LDAP Clients

In the last couple of sections we have focused exclusively on the SLAPD server. Now that the server is running we need to get the client configuration so that we can make test connections to the server.

Fortunately all of the OpenLDAP client programs share one common configuration file, ldap.conf, which is located in Ubuntu at /etc/ldap/ldap.conf (if you build from source, according to Appendix A, the default location for this file is /usr/local/etc/openldap/ldap.conf).

Other programs, such as those that use the OpenLDAP client libraries (like the PHP and Python LDAP APIs, may also use the ldap.conf file as a default location to retrieve basic configuration information.

Tip

Too Many ldap.conf Files

Occasionally, some Linux distributions will create two different ldap.conf files—one for OpenLDAP, and one for the PAM or NSS LDAP tools. This can lead to confusion about which ldap.conf file is used for which process. Ubuntu, however, gives the other packages distinctly named configuration files, like /etc/pam_ldap.conf.

A Basic ldap.conf File

The purpose of the ldap.conf file is two-fold:

1. It provided a place to define certain aspects of client behavior, such as how they treat SSL/TLS certificates or whether they follow alias entries.
2. It provides the OpenLDAP clients with useful defaults. By specifying some defaults, we can reduce the number of parameters we have to pass to the OpenLDAP clients when we run them from the command line.

Note

An alias is an entry in the directory that points to some other entry. Conceptually, it is similar to a symbolic link in a UNIX/Linux file system, or to a shortcut in Microsoft Windows.

The ldap.conf file has three different kinds of directive:

• General settings, which specify things such as the default server and DN to use
• SASL-specific settings, which determine how the OpenLDAP clients will try to authenticate when using SASL (Simple Authentication and Security Layer) authentication mechanisms
• TLS-specific settings, which specify how OpenLDAP will handle connections that use SSL (Secure Sockets Layer) and TLS encryption

At this point we are only interested in the general settings. In later chapters, we will return to this file when configuring SSL/TLS and SASL.

Now, we need to look into a basic ldap.conf file. The ldap.conf file is located in the same directory as slapd.conf—/etc/ldap/ (or /usr/local/etc/openldap/ if you built from source). We will now insert the LDAP client settings into that basic ldap.conf file:

# LDAP Client Settings

URI  ldap://localhost
BASE  dc=example,dc=com
BINDDN  cn=Manager,dc=example,dc=com

SIZELIMIT  0
TIMELIMIT  0

Again, as with slapd.conf, lines that begin with a number sign (#) are treated as comments, and are ignored by the OpenLDAP client tools.

Next, we have directives:

• The URI directive indicates which server (or servers, as this directive can take multiple URIs, separated by spaces) is to be contacted if no server is explicitly specified by the client.

  Since the server is running on the same machine that we are going to be running client commands from, we should set the URI to ldap://localhost. This URI specifies that the default client connection should be made using the (unencrypted) LDAP protocol over the loopback interface (127.0.0.1 or localhost). Since no port is specified it will use the default LDAP port, which is 389.

• The second directive is BASE. This tells the client programs where to start their search in the directory. It takes a full DN as a value. In this case we set it to the base DN of the server—to the DN of the root entry in our directory tree, so that all searches will start at the root.

  You may recall that when we were working on the database configuration section of slapd.conf, we set this same base DN, dc=example,dc=com, as the suffix for the database stored there. So, what we have done here is told the client to start at the same directory tree root that the server manages. This is generally the most convenient way to configure BASE in the ldap.conf file.

• The third directive, BINDDN, specifies the default DN that will be used when connecting to the server. In this file I have set it to the manager's DN, cn=Manager,dc=example,dc=com. While this will be very helpful when it comes to the examples in the next chapter it is not, in general, a good idea, and should never be set this way in a production environment. Usually the BINDDN default value should be set to a user that has limited privileges, or it should be omitted (in which case no default DN will be used).

Size and Time Limits

The next two directives, SIZELIMIT and TIMELIMIT, indicate the upper limits on the number of records returned (SIZELIMIT) and the amount of time the client will wait for the server to respond (TIMELIMIT). Here we have set both to 0, a special value for these directives that indicates that there should be no limit.

The way that size and time limits are handled can be a little confusing. On the client side there are two ways of specifying these limits: through the ldap.conf configuration file (as we are doing here) and through command-line parameters (as we will see in the next chapter).

However, the SIZELIMIT and TIMELIMIT directives above are not exactly defaults in the usual sense of the word. They are the absolute upper limit that the client can request. With command-line arguments the client can specify lower time and size limits, and those lower numbers will be used. But if the client attempts to specify larger size or time limits, they will be ignored, and the values of SIZELIMIT and TIMELIMIT will be used instead.

But the story doesn't end here. The SLAPD server can also define size and time limits (with the limits, sizelimit and timelimit directives in slapd.conf). If a client specifies a limit higher than the server's, the server will ignore the client's limit and use its own. We will look more at setting server limits in Chapter 5.

Now we have a functioning ldap.conf file that will alleviate the need to specify these parameters on the command line.

The last thing we need to do in this chapter is to use an OpenLDAP client to test out the SLAPD server.