<-
Apache > HTTP Server > Documentation > Version 2.4 > Modules

Apache Module mod_ldap

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

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.

SSL/TLS support is dependent on which LDAP toolkit has been linked to APR. As of this writing, APR-util supports: OpenLDAP SDK (2.x or later), Novell LDAP SDK, Mozilla LDAP SDK, native Solaris LDAP SDK (Mozilla based) or the native Microsoft LDAP SDK. See the APR website for details.

Directives

Topics

top

Example Configuration

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 500000
LDAPCacheEntries 1024
LDAPCacheTTL 600
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600

<Location "/ldap-status">
    SetHandler ldap-status

    Require host yourdomain.example.com

    Satisfy any
    AuthType Basic
    AuthName "LDAP Protected"
    AuthBasicProvider ldap
    AuthLDAPURL "ldap://127.0.0.1/dc=example,dc=com?uid?one"
    Require valid-user
</Location>
top

LDAP Connection Pool

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.

top

LDAP Cache

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 Search/Bind Cache

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.

Operation Caches

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.

Monitoring the Cache

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.

top

Using SSL/TLS

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).

# 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

    Require host yourdomain.example.com

    Satisfy any
    AuthType Basic
    AuthName "LDAP Protected"
    AuthBasicProvider ldap
    AuthLDAPURL "ldaps://127.0.0.1/dc=example,dc=com?uid?one"
    Require valid-user
</Location>
top

SSL/TLS Certificates

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
    # LDAPTrustedClientCert 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
    Require host yourdomain.example.com
</Directory>
top

LDAPCacheEntries Directive

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.

top

LDAPCacheTTL Directive

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).

top

LDAPConnectionPoolTTL Directive

Description:Discard backend connections that have been sitting in the connection pool too long
Syntax:LDAPConnectionPoolTTL n
Default:LDAPConnectionPoolTTL -1
Context:server config, virtual host
Status:Extension
Module:mod_ldap
Compatibility:Apache HTTP Server 2.3.12 and later

Specifies the maximum age, in seconds, that a pooled LDAP connection can remain idle and still be available for use. Connections are cleaned up when they are next needed, not asynchronously.

A setting of 0 causes connections to never be saved in the backend connection pool. The default value of -1, and any other negative value, allows connections of any age to be reused.

For performance reasons, the reference time used by this directive is based on when the LDAP connection is returned to the pool, not the time of the last successful I/O with the LDAP server.

Since 2.4.10, new measures are in place to avoid the reference time from being inflated by cache hits or slow requests. First, the reference time is not updated if no backend LDAP conncetions were needed. Second, the reference time uses the time the HTTP request was received instead of the time the request is completed.

This timeout defaults to units of seconds, but accepts suffixes for milliseconds (ms), minutes (min), and hours (h).

top

LDAPConnectionTimeout Directive

Description:Specifies the socket connection timeout in seconds
Syntax:LDAPConnectionTimeout seconds
Context:server config
Status:Extension
Module:mod_ldap

This directive configures the LDAP_OPT_NETWORK_TIMEOUT (or LDAP_OPT_CONNECT_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 5 seconds in IBM HTTP Server

top

LDAPLibraryDebug Directive

Description:Enable debugging in the LDAP SDK
Syntax:LDAPLibraryDebug 7
Default:disabled
Context:server config
Status:Extension
Module:mod_ldap

Turns on SDK-specific LDAP debug options that generally cause the LDAP SDK to log verbose trace information to the main Apache error log. The trace messages from the LDAP SDK provide gory details that can be useful during debugging of connectivity problems with backend LDAP servers

This option is only configurable when Apache HTTP Server is linked with an LDAP SDK that implements LDAP_OPT_DEBUG or LDAP_OPT_DEBUG_LEVEL, such as OpenLDAP (a value of 7 is verbose) or Tivoli Directory Server (a value of 65535 is verbose, on z/OS use 2147483647).

The logged information will likely contain plaintext credentials being used or validated by LDAP authentication, so care should be taken in protecting and purging the error log when this directive is used.

z/OS

On z/OS, LDAP_OPT_DEBUG messages are written to stdout which will be lost. To save these messages, set native environment variable LDAP_DEBUG_FILENAME. Be sure to include a '%' in the filename to create unique output per process.

top

LDAPOpCacheEntries Directive

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.

top

LDAPOpCacheTTL Directive

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.

top

LDAPReferralHopLimit Directive

Description:The maximum number of referral hops to chase before terminating an LDAP query.
Syntax:LDAPReferralHopLimit number
Default:SDK dependent, typically between 5 and 10
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.

Support for this tunable is uncommon in LDAP SDKs.

top

LDAPReferrals Directive

Description:Enable referral chasing during queries to the LDAP server.
Syntax:LDAPReferrals On|Off|default
Default:LDAPReferrals On
Context:directory, .htaccess
Override:AuthConfig
Status:Extension
Module:mod_ldap
Compatibility:The default parameter is available in Apache 2.4.7 and later

Some LDAP servers divide their directory among multiple domains and use referrals to direct a client when a domain boundary is crossed. This is similar to a HTTP redirect. LDAP client libraries may or may not chase referrals by default. This directive explicitly configures the referral chasing in the underlying SDK.

LDAPReferrals takes the following values:

"on"

When set to "on", the underlying SDK's referral chasing state is enabled, LDAPReferralHopLimit is used to override the SDK's hop limit, and an LDAP rebind callback is registered.

"off"

When set to "off", the underlying SDK's referral chasing state is disabled completely.

"default"

When set to "default", the underlying SDK's referral chasing state is not changed, LDAPReferralHopLimit is not used to overide the SDK's hop limit, and no LDAP rebind callback is registered.

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 by a value of "On", client credentials will be provided, via a rebind callback, for any LDAP server requiring them.

top

LDAPRetries Directive

Description:Configures the number of LDAP server retries.
Syntax:LDAPRetries number-of-retries
Default:LDAPRetries 3
Context:server config
Status:Extension
Module:mod_ldap

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.

top

LDAPRetryDelay Directive

Description:Configures the delay between LDAP server retries.
Syntax:LDAPRetryDelay seconds
Default:LDAPRetryDelay 0
Context:server config
Status:Extension
Module:mod_ldap

If LDAPRetryDelay is set to a non-zero value, the server will delay retrying an LDAP request for the specified amount of time. Setting this directive to 0 will result in any retry to occur without delay.

LDAP errors such as timeouts and refused connections are retryable.

top

LDAPSharedCacheFile Directive

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.

top

LDAPSharedCacheSize Directive

Description:Size in bytes of the shared-memory cache
Syntax:LDAPSharedCacheSize bytes
Default:4MB
Context:server config
Status:Extension
Module:mod_ldap

Specifies the number of bytes to allocate for the shared memory cache. The default is 4MB. If set to 0, shared memory caching will not be used and every HTTPD process will create its own cache.

top

LDAPSSLProtocol Directive

Description:Set SSL protocosl for LDAP connection
Syntax:LDAPSSLProtocol SSLV3,TLS10,TLS11,TLS12,TLS13
Default:see usage
Context:server config
Status:Extension
Module:mod_ldap
Compatibility:not supported on zOS. Requires PH55900

This directive overrides the LDAP SDKs default LDAP SSL protocols. The value is a comma separated list of protocols.

z/OS

On z/OS, LDAP SSL protocols can only be controlled by the underling System SSL environment variables. The environment variables used to enable or disable SSL protocols will be ignored in the SSL environment used by the rest of the server. See https://www.ibm.com/docs/en/zos/2.5.0?topic=routines-ldap-ssl-client-init for your release for more details.

top

LDAPTimeout Directive

Description:Specifies the timeout for LDAP search and bind operations, in seconds
Syntax:LDAPTimeout seconds
Default:LDAPTimeout 60
Context:server config
Status:Extension
Module:mod_ldap
Compatibility:Apache HTTP Server 2.3.5 and later

This directive configures the timeout for bind and search operations, as well as the LDAP_OPT_TIMEOUT option in the underlying LDAP client library, when available.

If the timeout expires, httpd will retry in case an existing connection has been silently dropped by a firewall. However, performance will be much better if the firewall is configured to send TCP RST packets instead of silently dropping packets.

Timeouts for ldap compare operations requires an SDK with LDAP_OPT_TIMEOUT, such as OpenLDAP >= 2.4.4.

top

LDAPTrustedClientCert Directive

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.

top

LDAPTrustedGlobalCert Directive

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.

top

LDAPTrustedMode Directive

Description:Specifies the SSL/TLS 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.

top

LDAPVerifyServerCert Directive

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.