Date: 08-15-2024

Overview

Since LDAP databases can store just about any type of sensitive information (birthdates, Social Security numbers, etc.) it is critical to protect the data from interception when it is being transmitted across a network between server and client. With OpenLDAP, this protection is achieved through encryption using Transport Layer Security (TLS) or the LDAPS (LDAP over Secure Sockets Layer (SSL)) protocol.

The TLS Protocol

TLS is now the standard network security protocol.

See TLS Expanded for additional information on TLS setup for OpenLDAP 2.5.

The LDAPS Protocol

The non-standardized LDAPS, SSLv2, and SSLv3 protocols are DEPRECATED. The LDAPv2 protocols is OBSOLETE and UNSUPPORTED. LDAP over TLS is now the preferred method of securing connections. LDAPS should only be used in rare cases where legacy clients are unable to communicate via TLS.

Note: The use of the LDAPS protocol is strongly discouraged and may be removed from future versions of OpenLDAP.

Restricting Connections by Encryption Type

OpenLDAP has multiple options to restrict client communication by encryption type.

slapd Param: -h (URLlist)

Applies: Global

Overview:

The slapd -h parameter operates at the network level by defining which URLs the daemon will listen on.

This option specifies alternative listener configurations. The default is ldap:/// which implies LDAP over TCP on all interfaces on the default LDAP port 389. You can specify specific host-port pairs or other protocol schemes (such as ldaps:// or ldapi://). 

slapd supports the HAProxy proxy protocol version 2, which allows a load balancer or proxy server to provide the remote client IP address to slapd to be used for access control or logging. Listeners configured using either pldap:/// or pldaps:/// URLS will only accept connections that include the necessary proxy protocol header. Connections to the ports used by these listeners should be restricted at the network level to only trusted load balancers or proxies to avoid spoofing of client IP addresses by third parties.

For example: 

-h "ldaps:// ldap://127.0.0.1:666" 

This example will create two listeners: one for the (non-standard) ldaps:// scheme on all interfaces on the default ldaps:// port 636, and one for the standard ldap:// scheme on the localhost (loopback) interface on port 666. Hosts may be specified using using hostnames or IPv4 or IPv6 addresses. Port values must be numeric.

For LDAP over IPC, the pathname of the Unix-domain socket can be encoded in the URL. Note that directory separators must be URL-encoded, like any other characters that are special to URLs. Thus the socket /usr/local/var/ldapi must be encoded as ldapi://usr/local/var/ldapi.

ldapi: is described in detail in Using LDAP Over IPC Mechanisms [Chu-LDAPI].

Note: The ldapi:/// transport is not widely implemented: non-OpenLDAP clients may not be able to use it.

Best Practices

The use of the LDAPS scheme is strongly discouraged because of the lack of standardization of the LDAPS protocol, deprecation of SSL (versions <= 3.0) and potential security vulnerabilities of SSL. It should only be used when LDAP clients are unable to connect to your server with TLS. If you find that none of your clients depend on SSL, it is best to remove all URLs that use the LDAPS scheme from the slapd -h parameter. If you are still dependent on legacy SSL connections via LDAPS and you want to restrict all connections to LDAPS, use the following value for -h:

ldaps://<interface>:636/

This will restrict all connection to LDAPS on the given interface on port 636. It will handle both legacy SSL and TLS encryption methods.

If you are not dependent on legacy SSL/LDAPS, completely disabling the LDAPS scheme creates a new problem. Both plain and TLS enabled connections use the LDAP scheme and the slapd -h parameter cannot make this distinction. Therefore, the security (olcSecurity) setting must be used to require the use of TLS, which is addressed in the next section.

Notes

• Changes to this parameter require a restart of slapd for the changes to take effect.
• While the LDAPS scheme acts as a gatekeeper to enforce use of SSL or TLS, it does not check which SSL or TLS protocol version, strength, etc. that must be used. This must be done a a higher configuration level.
• If the -h parameter is not defined, by default URL is ldap://:389/ (non-encrypted LDAP on all network interfaces on port 389) .
• Symas OpenLDAP users: Unix/Linux servers configure the slapd -h parameter using the HOST_LIST variable in /opt/symas/etc/openldap/symas-openldap.conf.
• Windows OpenLDAP users: The slapd -h parameter is configured with the Windows registry value HKLM\SOFTWARE\Wow6432Node\OpenLDAP\Parameters\Urls.

Reference: OpenLDAP Admin Guide - Selective Listening | slapd(8c) man page**

SLAPD Config: Security (olcSecurity)

Applies: Global, Per-Database, ACL

Overview

The security (olcSecurity) setting will set the minimum allowed security strength factor (SSF) for access to a resource. Each factor type uses the same scheme:

• 0 = None required
• 1 = Integrity protection only
• 56 = DES or other weak ciphers
• 112 = Triple DES and other strong ciphers
• 128 = RC4, Blowfish and other modern strong ciphers
• 256 = <Which?> (Recommended)

The most important factor type for requiring secure connections is the "tls" type. Setting security tls=1 or olcSecurity: tls=1 will require the use of TLS for access to the resource and accept the use of any ciphers. Factor 256 is the recommended value whenever possible.

Global and Per-Database Restriction

To use SSF restrictions on a global level, place the security tls=<n> setting before any database declarations in the slapd.conf file or olcSecurity: tls=<n> in the cn=config root if using dynamic configuration (cn=config).

To use SSF restrictions on a specific database, place the security tls=<n> setting within the declaration of the target database in slapd.conf, or olcSecurity: tls=<n> under the dn of the target database if using dynamic configuration (cn=config).

Restriction via ACL

Defining SSF restriction via ACLs offers the finest level of control. An SSF level can be added to any by clause. The following links to the OpenLDAP Admin Guide provide details and examples of SSF in ACLs:

• Access Control Examples (slapd.conf)
• Access Control Examples (cn=config)

ACL-based SSF restrictions may be used at both the global and database level.

Reference: OpenLDAP Admin Guide - Security Strength Factors | slapd.conf(5) man page | slapd-config(5)(cn=config) man page

SLAPD Config: TLSProtocolMin (olcTLSProtocolMin)

Applies: Global, Per-Database

Note: TLSProtocolMin does not enforce cipher suites, only the minimum version of TLS to accept.

Reference: | slapd.conf(5) man page | slapd-config(5)(cn=config) man page