Overview of TLS and LDAPS
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.
THE LDAPS PROTOCOL
The use of the LDAPS protocol is strongly discouraged and may be removed from future versions of OpenLDAP.
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.
RESTRICTING CONNECTIONS BY ENCRYPTION TYPE
OpenLDAP has multiple options to restrict client communication by encryption type.
SLAPD PARAM: -h (URLlist)
The slapd -h parameter operates at the network level by defining which URLs the daemon will listen on.
Each URL contains three elements: scheme, interface and port. When restricting access by protocol, the scheme element is what defines the protocol to be allowed.
The following table shows which protocols are allowed to pass by URL scheme:
Client Request Protocol URL Scheme LDAP TLS LDAPS ldap://:389/
Note the TLS protocol is allowed by both schemes. The ldaps scheme recognizes the StartTLS operation and will process the request as TLS and not SSL.
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:
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.
- 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.
SLAPD CONFIG: security (olcSecurity)
Applies: Global, Per-Database, ACL
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 “
"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 Main|http://www.openldap.org/doc/admin24/access-control]]
- Access Control Examples (slapd.conf)
- Access Control Examples (cn=config)
- Granting and Denying Access Via SSF
ACL-based SSF restrictions may be used at both the global and database level.
SLAPD CONFIG: TLSProtocolMin (olcTLSProtocolMin)
Applies: Global, Per-Database
Note: TLSProtocolMin does not enforce cipher suites, only the minimum version of TLS to accept.