Symas OpenLDAP Knowledge Base

Overview of TLS and LDAPS

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.

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)

Applies: Global

OVERVIEW

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/

(tick) (tick) (error) ldaps://:636/ (error) (tick) (tick)

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.

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:

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