S 5.170 Secure communication connections when using OpenLDAP

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

Communications between an slapd server and its communication partners should be encrypted in order to protect the exchanged information from being read or changed by unauthorised persons. Here the communication partners may include clients and other servers, within the framework of partitioning and replication, for example.

StartTLS und ldaps://

In order to protect OpenLDAP by means of TLS/SSL, StartTLS and ldaps:// should preferably be used (see S 5.66 use of TLS/SSL):

Although OpenLDAP supports both connection variants, the use of StartTLS is recommendable. StartTLS has the advantage of default conformity and of avoiding another open port/service at a central network components. However, it is possible that a communication partner does not support StartTLS. Furthermore, there are cases where LDAP clients exchanged confidential information, particularly regarding the authentication, using an LDAP connection before StartTLS processing was completed. Transmission was partially not secured. In these cases using ldaps:// makes sense. SSLv2 should neither be used for StartTLS nor for ldaps://.

Configuration with certificates

A server certificate is required for encrypted communication, including the completely specified computer name of the server as Distinguished Name (DN) of the certificate. If the communication is also to include the certificate-based identity determination of the user, the user also needs an X.509 certificate. If the DN entries in the certificate of a user do not match his/her entry in the directory, mapping is required.

The configuration for encrypted connections must be conducted both on the server and on the client. For the slapd server, the settings must be made in the global directives of the "slapd.conf" configuration file; for the ldap* tools of OpenLDAP, in the local ldap.conf. The ldap.conf settings can be overwritten by the user-specific .ldaprc configuration file; user certificates must be entered into this file in any case. Information on other tools and clients can be found in the respective documentation.

The following parameters, among others, must be documented:

TLSCACertificateFile (server) and/or TLS_CACERT (client or user)

The entry refers to the file containing the public key and/or the root certificate of a trustworthy certificate authority. Several files can be specified.

TLSCACertificatePath (server) and/or TLS_CACERTDIR (client or user)

Instead of the files in the above-mentioned parameter, one or several paths can be described here where the files can be found.

TLSCertificateFile (server) and/or TLS_CERT (user, not client)

The parameter refers to the file containing the proprietary certificate and/or the public key.

TLSCertificateKeyFile (server) and/or TLS_KEY (user, not client)

This parameter refers to the secret key that must be protected in any case. The access rights to the file must be configured carefully so that only the respective user (or the user with whose rights the slapd server is operated) can access the file.

TLSCipherSuite (server only)

The entry lists the admissible encryption methods in the preferred sequence and depends on the used SSL/TLS implementation. The fewer and the stronger the encryption methods specified, the better; SSLv2 should be avoided, for example. Entry "NULL" (no encryption) is prohibited at this point.

TLSRandFile (server) and/or TLS_RANDFILE (client or user)

This information refers to the source of random values. The file provides the baseline value (Seed) that can be used in connection with mathematical functions in order to generate sufficiently random numerical values as session keys. This information is not required on most of the Linux and Unix systems, because /dev/urandom is available to this end.

TLSVerifyClient (server) and/or TLS_REQCERT (client or user)

This parameter defines the extent to which certificates of the respective responder are checked. Possible values include:

Establishing a secure connection

For StartTLS, all ldap* tools of OpenLDAP support the flags "-Z" and "-ZZ". "Z" means that an encrypted connection is to be attempted and used if the attempt is successful. "ZZ", on the other hand, means that successful encryption is required before the command may be executed. For other clients contacting a slapd server, the respective documentation must be read.

ldaps:// is normally started by the corresponding target address with ldaps://... instead of ldap://...; alternatively, by a general entry in the URI directive of the client-specific "ldap.conf" configuration file.

If overlays are used, it must be taken into consideration that these partially offer proprietary subdirectives for TLS/SSL if they result in an exchange of data between servers. Amongst other things, this applies to the overlays "syncprov" and "chain"

Restriction of the network traffic

In order to additionally secure communications, OpenLDAP offers the "selective listening" feature and the integration of the TCP Wrapper system application. "Selective listening" restricts the acceptance of operations to certain sender IP addresses. TCP Wrapper provides rule-based monitoring of the TCP/IP communications. It is recommendable to relinquish "selective listening" and TCP Wrapper. It must rather be observed that the server is protected adequately at the operating system level already (see S 4.238 Use of local packet filters). Additionally monitoring the network traffic by OpenLDAP causes unnecessary administrative efforts and ultimately results in OpenLDAP assuming a function the application was not designed for.

Deviating ports

Occasionally, it is recommended to configure directory services in such a way that these use other ports than 389 and/or 636. This is intended to make attacks to weaknesses of an LDAP version that have become known more difficult. This recommendation is advised against since the comprehensive and therefore buggy administrative efforts only provide a minimum increase in security. Functional limitations may even be possible in the event of insufficiently configurable clients.

Review questions:

© Federal Office for Information Security. All rights reserved.