Summary

This module was created to improve the performance of
websites relying on backend connections to LDAP servers. In
addition to the functions provided by the standard LDAP
libraries, this module adds an LDAP connection pool and an LDAP
shared memory cache.

To enable this module, LDAP support must be compiled into
apr-util. This is achieved by adding the --with-ldap
flag to the configure script when building
Apache.

LDAP connections are pooled from request to request. This
allows the LDAP server to remain connected and bound ready for
the next request, without the need to unbind/connect/rebind.
The performance advantages are similar to the effect of HTTP
keepalives.

On a busy server it is possible that many requests will try
and access the same LDAP server connection simultaneously.
Where an LDAP connection is in use, Apache will create a new
connection alongside the original one. This ensures that the
connection pool does not become a bottleneck.

There is no need to manually enable connection pooling in
the Apache configuration. Any module using this module for
access to LDAP services will share the connection pool.

For improved performance, mod_ldap uses an aggressive
caching strategy to minimize the number of times that the LDAP
server must be contacted. Caching can easily double or triple
the throughput of Apache when it is serving pages protected
with mod_authnz_ldap. In addition, the load on the LDAP server
will be significantly decreased.

mod_ldap supports two types of LDAP caching during
the search/bind phase with a search/bind cache and
during the compare phase with two operation
caches. Each LDAP URL that is used by the server has
its own set of these three caches.

The process of doing a search and then a bind is the
most time-consuming aspect of LDAP operation, especially if
the directory is large. The search/bind cache is used to
cache all searches that resulted in successful binds.
Negative results (i.e., unsuccessful searches, or searches
that did not result in a successful bind) are not cached.
The rationale behind this decision is that connections with
invalid credentials are only a tiny percentage of the total
number of connections, so by not caching invalid
credentials, the size of the cache is reduced.

mod_ldap stores the username, the DN
retrieved, the password used to bind, and the time of the bind
in the cache. Whenever a new connection is initiated with the
same username, mod_ldap compares the password
of the new connection with the password in the cache. If the
passwords match, and if the cached entry is not too old,
mod_ldap bypasses the search/bind phase.

During attribute and distinguished name comparison
functions, mod_ldap uses two operation caches
to cache the compare operations. The first compare cache is
used to cache the results of compares done to test for LDAP
group membership. The second compare cache is used to cache
the results of comparisons done between distinguished
names.

mod_ldap has a content handler that allows
administrators to monitor the cache performance. The name of
the content handler is ldap-status, so the
following directives could be used to access the
mod_ldap cache information:

<Location /server/cache-info>
SetHandler ldap-status
</Location>

By fetching the URL http://servername/cache-info,
the administrator can get a status report of every cache that is used
by mod_ldap cache. Note that if Apache does not
support shared memory, then each httpd instance has its
own cache, so reloading the URL will result in different
information each time, depending on which httpd
instance processes the request.

The ability to create an SSL and TLS connections to an LDAP server
is defined by the directives
LDAPTrustedGlobalCert,
LDAPTrustedClientCert and
LDAPTrustedMode.
These directives specify the CA and
optional client certificates to be used, as well as the type of
encryption to be used on the connection (none, SSL or TLS/STARTTLS).

CA certificates are specified within a file called cert7.db.
The SDK will not talk to any LDAP server whose certificate was
not signed by a CA specified in this file. If
client certificates are required, an optional key3.db file may
be specified with an optional password. The secmod file can be
specified if required. These files are in the same format as
used by the Netscape Communicator or Mozilla web browsers. The easiest
way to obtain these files is to grab them from your browser
installation.

Client certificates are specified per connection using the
LDAPTrustedClientCert directive by referring
to the certificate "nickname". An optional password may be
specified to unlock the certificate's private key.

The SDK supports SSL only. An attempt to use STARTTLS will cause
an error when an attempt is made to contact the LDAP server at
runtime.

One or more CA certificates must be specified for the Novell
SDK to work correctly. These certificates can be specified as
binary DER or Base64 (PEM) encoded files.

Note: Client certificates are specified globally rather than per
connection, and so must be specified with the LDAPTrustedGlobalCert
directive as below. Trying to set client certificates via the
LDAPTrustedClientCert directive will cause an error to be logged
when an attempt is made to connect to the LDAP server..

The SDK supports both SSL and STARTTLS, set using the
LDAPTrustedMode parameter. If an ldaps:// URL is specified,
SSL mode is forced, override this directive.

One or more CA certificates must be specified for the OpenLDAP
SDK to work correctly. These certificates can be specified as
binary DER or Base64 (PEM) encoded files.

Client certificates are specified per connection using the
LDAPTrustedClientCert directive.

The documentation for the SDK claims to support both SSL and
STARTTLS, however STARTTLS does not seem to work on all versions
of the SDK. The SSL/TLS mode can be set using the
LDAPTrustedMode parameter. If an ldaps:// URL is specified,
SSL mode is forced. The OpenLDAP documentation notes that SSL
(ldaps://) support has been deprecated to be replaced with TLS,
although the SSL functionality still works.

This directive configures the LDAP_OPT_NETWORK_TIMEOUT option in the
underlying LDAP client library, when available. This value typically
controls how long the LDAP client library will wait for the TCP connection
to the LDAP server to complete.

If a connection is not successful with the timeout period, either an error will be
returned or the LDAP client library will attempt to connect to a secondary LDAP
server if one is specified (via a space-separated list of hostnames in the
AuthLDAPURL).

The default is 10 seconds, if the LDAP client library linked with the
server supports the LDAP_OPT_NETWORK_TIMEOUT option.

LDAPConnectionTimeout is only available when the LDAP client library linked
with the server supports the LDAP_OPT_NETWORK_TIMEOUT option, and the
ultimate behavior is dictated entirely by the LDAP client library.

It specifies the directory path, file name or nickname of a
per connection client certificate used when establishing an SSL
or TLS connection to an LDAP server. Different locations or
directories may have their own independent client certificate
settings. Some LDAP toolkits (notably Novell)
do not support per connection client certificates, and will throw an
error on LDAP server connection if you try to use this directive
(Use the LDAPTrustedGlobalCert directive instead for Novell client
certificates - See the SSL/TLS certificate guide above for details).
The type specifies the kind of certificate parameter being
set, depending on the LDAP toolkit being used. Supported types are:

It specifies the directory path and file name of the trusted CA
certificates and/or system wide client certificates mod_ldap
should use when establishing an SSL or TLS connection to an LDAP
server. Note that all certificate information specified using this directive
is applied globally to the entire server installation. Some LDAP toolkits
(notably Novell) require all client certificates to be set globally using
this directive. Most other toolkits require clients certificates to be set
per Directory or per Location using LDAPTrustedClientCert. If you get this
wrong, an error may be logged when an attempt is made to contact the LDAP
server, or the connection may silently fail (See the SSL/TLS certificate
guide above for details).
The type specifies the kind of certificate parameter being
set, depending on the LDAP toolkit being used. Supported types are:

Notice:This is not a Q&A section. Comments placed here should be pointed towards suggestions on improving the documentation or server, and may be removed again by our moderators if they are either implemented or considered invalid/off-topic. Questions on how to manage the Apache HTTP Server should be directed at either our IRC channel, #httpd, on Freenode, or sent to our mailing lists.