Apache HTTP Server Version 2.2
Description: | LDAP connection pooling and result caching services for use by other LDAP modules |
---|---|
Status: | Extension |
Module Identifier: | ldap_module |
Source File: | util_ldap.c |
Compatibility: | Available in version 2.0.41 and later |
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.
The following is an example configuration that uses
mod_ldap
to increase the performance of HTTP Basic
authentication provided by mod_authnz_ldap
.
# Enable the LDAP connection pool and shared
# memory cache. Enable the LDAP cache status
# handler. Requires that mod_ldap and mod_authnz_ldap
# be loaded. Change the "yourdomain.example.com" to
# match your domain.
LDAPSharedCacheSize 200000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600
<Location /ldap-status>
SetHandler ldap-status
Order deny,allow
Deny from all
Allow from yourdomain.example.com
AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one
Require valid-user
</Location>
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.
LDAP connections can keep track of the ldap client
credentials used when binding to an LDAP server. These
credentials can be provided to LDAP servers that do not
allow anonymous binds during referral chasing. To control
this feature, see the
LDAPReferrals
and
LDAPReferralHopLimit
directives. By default,
this feature is enabled.
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.
The search and bind cache is controlled with the LDAPCacheEntries
and LDAPCacheTTL
directives.
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.
Note that, when group membership is being checked, any sub-group comparison results are cached to speed future sub-group comparisons.
The behavior of both of these caches is controlled with
the LDAPOpCacheEntries
and LDAPOpCacheTTL
directives.
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 key database and
optionally specify the client certificate(s) to be used, as well as the type of
encryption to be used on the connection (none, or SSL).
Note that LDAPTrustedMode
will
default to SSL if AuthLDAPURL
is set to use ldaps:// in the URL.
# Establish an SSL LDAP connection on port 636. Requires that
# mod_ldap and mod_authnz_ldap be loaded. Change the
# "yourdomain.example.com" to match your domain.
LDAPTrustedGlobalCert CMS_KEYFILE /certs/certfile.kdb
<Location /ldap-status>
SetHandler ldap-status
Order deny,allow
Deny from all
Allow from yourdomain.example.com
AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one
Require valid-user
</Location>
Different LDAP SDKs provide support for certificates in different ways. This has required that the LDAP configuration directives be flexible, and potentially confusing, since they must offer more options than any single SDK can use.
The IBM HTTP Server uses an LDAP SDK that provides certificate support via CMS based key database files and SAF keyrings (on z/OS) that can contain multiple client and CA signer certificates. This key storage will be referred to as key databases throughout the remainder of this documentation.
The LDAPTrustedGlobalCert
directive specifies the key database to be used globally across all LDAP
controlled resources. This key database contains certificates for trusted
issuers and zero or more personal certificates (also called private keys
or client certificates).
The LDAPTrustedClientCert
directive is used to specify the label of the client certificate that
IBM HTTP Server will provide to the LDAP server, if the LDAP sever requests
a certificate. Each protected resource can specify its own
LDAPTrustedClientCert
label value.
If the key database designates a default certificate which you wish to
use, or your LDAP server does not request a client certificate, you don't need
to specify LDAPTrustedClientCert
.
# Establish an SSL LDAP connection on port 636 using a specific
# certificate and requiring a specific group memership to protect
# a directory. Requires that mod_ldap and mod_authnz_ldap be
# loaded. Change the "yourdomain.example.com", certfile info,
# Directory information, and LDAPURL to match your information.
LDAPTrustedGlobalCert CMS_KEYFILE /certs/certfile.kdb
LDAPTrustedMode SSL
<Directory "/special/protected/info">
AuthLDAPURL ldaps://127.0.0.1:636/dc=example,dc=com?uid?one
# The following is only required if you want to use a non-default cert label.
LDAPTrustedClientCert CMS_LABEL alternate_cert
AuthBasicProvider ldap
AuthLDAPBindDN "cn=ldaptestadm,ou=test group,o=myorg,c=US"
AuthLDAPBindPassword test
AuthName "Protected info"
AuthType Basic
require ldap-group cn=Just_testers_group,o=Humans,c=us
Satisfy Any
Order deny,allow
Deny from all
Allow from yourdomain.example.com
</Directory>
Description: | Specifies the maximum amount of time for a LDAP bind operation to complete |
---|---|
Syntax: | LDAPBindTimeoutseconds |
Default: | LDAPBindTimeout 0 |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Compatibility: | IBM HTTP Server 7.0.0.21, 8.0.0.2, and later |
This directive limits the amount of time the LDAP client library will wait
for the ldap_simple_bind
to complete. Default is 0,
which is unlimited.
Future relases of IBM HTTP Server will use the same default as Apache HTTP Server, which is 60 seconds.
Under different conditions, LDAP connections will be retried and this directive configures the timeout for each attempt, not an end-to-end timeout
Description: | Maximum number of entries in the primary LDAP cache |
---|---|
Syntax: | LDAPCacheEntries number |
Default: | LDAPCacheEntries 1024 |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Specifies the maximum size of the primary LDAP cache. This cache contains successful search/binds. Set it to 0 to turn off search/bind caching. The default size is 1024 cached searches.
Description: | Time that cached items remain valid |
---|---|
Syntax: | LDAPCacheTTL seconds |
Default: | LDAPCacheTTL 600 |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Specifies the time (in seconds) that an item in the search/bind cache remains valid. The default is 600 seconds (10 minutes).
Description: | Specifies the socket connection timeout in seconds |
---|---|
Syntax: | LDAPConnectionTimeout seconds |
Default: | LDAPConnectionTimeout 0 |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Compatibility: | Distributed platforms only: IBM HTTP Server 7.0.0.21, 8.0.0.2, and later |
This directive limits the amount of time the LDAP client library will wait for new TCP connections to the LDAP server to be established. Default is 0, which is unlimited (blocking connect).
Under different conditions, LDAP connections will be retried and this directive configures the timeout for each attempt, not an end-to-end timeout
Description: | Number of entries used to cache LDAP compare operations |
---|---|
Syntax: | LDAPOpCacheEntries number |
Default: | LDAPOpCacheEntries 1024 |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
This specifies the number of entries mod_ldap
will use to cache LDAP compare operations. The default is 1024
entries. Setting it to 0 disables operation caching.
Description: | Time that entries in the operation cache remain valid |
---|---|
Syntax: | LDAPOpCacheTTL seconds |
Default: | LDAPOpCacheTTL 600 |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Specifies the time (in seconds) that entries in the operation cache remain valid. The default is 600 seconds.
Description: | The maximum number of referral hops to chase before terminating an LDAP query. |
---|---|
Syntax: | LDAPReferralHopLimit number |
Default: | LDAPReferralHopLimit 5 |
Context: | directory, .htaccess |
Override: | AuthConfig |
Status: | Extension |
Module: | mod_ldap |
This directive, if enabled by the LDAPReferrals
directive,
limits the number of referral hops that are followed before terminating an
LDAP query.
Description: | Enable referral chasing during queries to the LDAP server. |
---|---|
Syntax: | LDAPReferrals On|Off |
Default: | LDAPReferrals On |
Context: | directory, .htaccess |
Override: | AuthConfig |
Status: | Extension |
Module: | mod_ldap |
Some LDAP servers divide their directory among multiple domains and use referrals
to direct a client when a domain boundary is crossed. By setting LDAPReferrals On
referrals will be chased (setting it to off causes referrals to be ignored). The directive
LDAPReferralHopLimit
works in conjunction with this directive to limit the
number of referral hops to follow before terminating the LDAP query. When referral processing
is enabled client credentials will be provided, via a rebind callback, for any LDAP server
requiring them.
Description: | Configures the number of LDAP server retries. |
---|---|
Syntax: | LDAPRetries number-of-retries |
Default: | LDAPRetries 4 (3 on Windows) |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Compatibility: | Requires PM94008. Prior to PM94008, hard-coded |
The server will retry failed LDAP requests up to
LDAPRetries
times. Setting this
directive to 0 disables retries.
LDAP errors such as timeouts and refused connections are retryable.
Description: | Specifies the number of seconds that an LDAP search request should wait for a response from the LDAP server before timing out. |
---|---|
Syntax: | LDAPSearchTimeout seconds |
Default: | LDAPSearchTimeout 10 |
Context: | server config, virtual host |
Status: | Extension |
Module: | mod_ldap |
Specifying 0 seconds indicates that LDAP searches, requested by mod_ldap, will not time out. Specifying any other number of seconds, greater than 0, results in LDAP searches timing out if the LDAP server takes longer than that number of seconds to respond to the request.
Note that the LDAP server may have a shorter default timeout set which will take precedent over a longer client timeout value.
Description: | Sets the shared memory cache file |
---|---|
Syntax: | LDAPSharedCacheFile directory-path/filename |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Specifies the directory path and file name of the shared memory cache file. If not set, anonymous shared memory will be used if the platform supports it.
Description: | Size in bytes of the shared-memory cache |
---|---|
Syntax: | LDAPSharedCacheSize bytes |
Default: | 4MB after PI93624 |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Specifies the number of bytes to allocate for the shared memory cache. The default was 100kb prior to PI93624, and 4MB after.. If set to 0, shared memory caching will not be used.
Description: | Sets the label referring to a per connection client certificate. |
---|---|
Syntax: | LDAPTrustedClientCert type label |
Context: | server config, virtual host, directory, .htaccess |
Status: | Extension |
Module: | mod_ldap |
Specifies the label 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.
For the first argument, certificate type, the only value supported by the IBM HTTP Server is CMS_LABEL. CMS_LABEL can be used with both the CMS_KEYFILE or SAF key database types.
The second argument identifies the label associated with the personal (client)
certificate you wish to use from the key database specified in the
LDAPTrustedGlobalCert
directive.
This directive is not required if the LDAP server does not request a client certificate, or if you wish to use the client certificate designated as the default in the key database.
Description: | Sets the file or database containing global trusted Certificate Authority and/or global client certificates |
---|---|
Syntax: | LDAPTrustedGlobalCert type key_database_name [password] |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Specifies the directory path and file name or keyring 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 and only one key database
can be specified per configuration file.
The type indicates the kind of certificate storage being specified. The only supported types for the IBM HTTP Server are the CMS_KEYFILE type (all platforms) and the SAF type (z/OS only).
The key_database_name specifies the path and filename of a CMS key database or specifies the SAF keyring name. A CMS key database file or a SAF keyring contain a collection of CA signer certificates and zero or more client certificates.
For the SAF type, a password should not be provided, as SAF keyrings do not use a password. Providing a password with the SAF type will result in an initialization failure.
For the CMS_KEYFILE type, you can omit the password and mod_ldap
will
try to use a stashed password as generated by ikeyman. The file with the stashed password
must have the same path and basename as the CMS_KEYFILE, but have an extension of ".sth".
Use of the stash file instead of the password is recommended.
If you provide the password in httpd.conf, take extra care to restrict access to the configuration file to protect the password.
See the LDAPTrustedClientCert
directive for information about how to specify the use of a particular
client certificate within a protected resource such as a Directory or
Location container.
Description: | Specifies the SSL mode to be used when connecting to an LDAP server. |
---|---|
Syntax: | LDAPTrustedMode type |
Context: | server config, virtual host |
Status: | Extension |
Module: | mod_ldap |
The following modes are supported:
Not all LDAP toolkits support all the above modes. An error message will be logged at runtime if a mode is not supported, and the connection to the LDAP server will fail.
If an ldaps:// URL is specified, the mode becomes SSL and the setting of LDAPTrustedMode is ignored.
Description: | Force server certificate verification |
---|---|
Syntax: | LDAPVerifyServerCert On|Off |
Default: | LDAPVerifyServerCert On |
Context: | server config |
Status: | Extension |
Module: | mod_ldap |
Specifies whether to force the verification of a server certificate when establishing an SSL connection to the LDAP server.