S 4.384 Secure configuration of OpenLDAP

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator

This safeguard describes how the slapd server is configured properly so that it fulfils the tasks assigned to it securely. To ensure the security of the directory service data, the client applications used must be configured securely. This can, but do not have to be the ldap* tools of OpenLDAP. It is not possible to address all available tools in the IT-Grundschutz catalogues. Thus, it is even more important that the slapd server is configured securely so that you do not have to rely on the security settings of the clients used.

Different configuration methods

In OpenLDAP version 2.3 and higher, there are two different methods to configure the slapd server. The classic method is to enter all settings in the "slapd.conf" file. The file is stored by OpenLDAP on Unix and Linux systems under usr/local/etc/openldap/slapd.conf, but can also be stored at other locations, for example, when distribution-specific installation packages are used. In OpenLDAP 2.3, the "slapd-config" format has also been introduced. This is a hierarchical database which is stored in the form of LDIF files below /usr/local/etc/openldap/slapd.d or at a distribution-specific location.

The main advantage of "slapd-config" over "slapd.conf" is the possibility of modifying the runtime configuration, whereas the slapd server must be restarted for each change to the "slapd.conf". In connection with the "slapd-config" database, this is also referred to as online configuration or, more rarely, the RunTimeConfiguration (RTC). With the permanently set suffix "CN=config", the online configuration is part of the directory tree in the slapd server. During the planning phase, the configuration method must be chosen and then applied and maintained permanently. In addition, it must be considered that the settings visible in the "slapd.conf" file are not valid when the "slapd-config" database is used.

User rights at operating system level

Whilst changes to the "slapd.conf" are implemented by editing the file, changes to the online configuration must be initiated using change commands within the framework of the LDAP log. Consequently, an administrator must have access to the file system of the IT system on which the slapd server is run for the configuration via "slapd.conf". However, the system user, in whose context the slapd server runs, should only be granted read privileges to the file. For the configuration using the "slapd-config" database, a user account in the directory service is sufficient, but the system user, in whose context the slapd server is run, must be equipped with write authorisations for the database directory. If OpenLDAP was installed and set up with root authorisations, then the authorisations to the directory are often set incorrectly. This might result in the incorrect assessment that the operation of the slapd server would require root authorisations.

Structure of the configuration

In OpenLDAP, the configuration settings are referred to as directives. There are global directives, backend directives and database directives. In some cases, the global directives are also referred to as frontend directives in order to distinguish them from the backends and databases. The directives have a hierarchical structure: Global or frontend directives can be superseded by backend directives and these, in turn, by database directives. Some of the directives have subdirectives in which other settings are made to the respective directive. This applies especially to backends and overlays which are called up using a directive and configured using subdirectives.

Conversion from slapd.conf into slapd-config

There is a clear relationship between the directives of the two configuration methods with the letters "olc" (for online configuration) being generally prefixed to the respective attribute in the "slapd-config" database. Thus, "backend" in the "slapd.conf" corresponds to the term "olcBackend" in the "slapd-config" database. Each slap* tool of OpenLDAP is able to convert a classic configuration to an online configuration by indicating the position of "slapd.conf" using the parameter "-f" and the target directory of the "slapd-config" database using the parameter "-F" . An example is: slaptest -f /usr/local/etc/openldap/slapd.conf -F /usr/local/etc/openldap/slapd.d.

Independent from the selected configuration method, each new or modified configuration must be checked using the "slaptest" tool if it is syntactically correct. This has to be done before the slapd server with the new configuration is started. When changes are made to the running system as part of the online configuration, the slapd server rejects inadmissible configuration changes. It is important that all configuration settings are documented so that they can be reproduced quickly in emergencies.

slapd.conf

In its syntax, the "slapd.conf" file corresponds to the LDAP Data Interchange Format (LDIF) defined in RFC 2849, which administrators should be familiar with. The "slapd.conf" configuration file starts with global directives. The global directives contain schema specifications. Since the integration of schemas into the slapd.conf can become very complex, it is recommended to create a separate local file for a schema and to call them up using "include" in the "slapd.conf" configuration file. The global directives are followed by backend directives, if any, provided they are used. They are introduced using the "backend <type>" directive with <type> indicating the backend, i.e. its type designation without the suffix "back-". An example is "backend hdb". The following directives no longer apply globally, but only for all databases of this type. Database directives are introduced using the "database <type>" directive with <type> defining the database type similarly to the backends. The following directives then only apply to this database. It must be noted that the type of an existing database may not be changed by simply adapting the database call. This does not have an impact on the existing data structures which might differ for different database types.

slapd-config

In the configuration subtree of the "slapd-config" database, global directives are entered as values in the "CN=config" area or in the special dummy database "olcDatabase=frontend, CN=config". Schemas are subelements of the "CN=schema, CN=config" subtree. Backends and databases, in turn, are subelements of "CN=config". The initial configuration can be created converting an existing "slapd.conf" configuration file or creating the suffix "CN=config" with its elements in the LDIF format and importing it in the directory service using "slapadd". It must be noted that the "slap-config" configuration may not changed by adapting the LDIF files in the "slapd.d" database directory. In this case, the time stamps managed as operational attributes are not updated. Therefore, the slapd server does not notice these changes and does not implement them.

Overlays

In the "slapd.conf" configuration file, overlays are called up either in global directives or in a database section. Overlays should only be called up after all other database-specific directives to avoid incorrect configurations in which database directives are interpreted as subdirectives of the overlay. In the "slapd-config" database, overlays are subelements of "CN=config" (for global overlays) or of the database element (for database-specific overlays). Since the exact impact of overlays can depend on the order of their call, overlays must be integrated into the configuration with due care. In the "slapd.conf" configuration file, the overlays are called up in the reverse order according to which they are listed within the file

In the following, several basic and security-specific directives are listed, whose default values should be checked during the configuration and adapted if necessary. Further directives can be found in the OpenLDAP Administrator's Guide as well as on the man pages.

This is the most important subdirective of a database call. Using this subdirective, it is defined which part of the directory is to be stored in the respective database, for example "DC=bsi, DC=federal, DC=de". If a database has to include a lower-level subtree, this database must be called prior to the superior database. For example, "DC=grundschutz, DC=bsi, DC=federal, DC=de" must be defined prior to "DC=bsi, DC=federal, DC=de", as otherwise the superior database is always selected.

In this directive, files outside the "slapd.conf" configuration file can be referred to, whose contents then take the place of the directive when evaluating the "slapd.conf". The directive is recommended, for example, to separately manage schema definitions and access control lists. The directive can also be used in these external files. However, the slapd server does not notice any ring references, which might result in reading a seemingly indefinite configuration ("slapd.conf" contains "include ACL1.conf", "ACL1.conf" contains "include ACL2.conf", "ACL2.conf" contains "include ACL1.conf"). In such a case, the slapd server becomes unusable; under certain circumstances, the operation of the entire IT system might be impaired by the resource requirements of the slapd server. It must also be ensured that the user ID used for the operation of the slapd server is granted a reading right to the external files. When a "slapd.conf" configuration is converted into a "slapd-config" configuration, the files integrated using "include" are included.

Using this directive, a value in seconds is defined, after which an "unbind" is forced for an unused connection to a client. In the default setting, this directive is assigned 0 and thus deactivated. In this case, it is recommended to set a value greater than zero to ensure that unused connections to clients which were not shut down properly or to left workstations cannot be used for attacks. The value should be defined with due care and should not impair the usual usage within the organisation. For example, a value less than 900 is useful to ensure that unused connections are separated after 15 minutes of inactivity at the latest.

This directive assigns a LDAP server which reports back the slapd server to a requesting client when the slapd server cannot perform the operation requested by the client itself. The directive should be assigned using a superior LDAP server, if one is available, to improve the availability. It must be ensured that no ring references are installed between servers with equal rights, as this will not be noticed by several client applications.

Using this directive, a database is set into a read-only-state.

Using these two directives, an administrative user ID for the respective database and the associated password are defined. Limits or access restrictions (see S 4.387 Secure assignment of access rights to OpenLDAP) do not have any impact on this user ID. Storing the passwords securely, as described in safeguard S 4.388 Secure authentication to OpenLDAP, must also be carried out for the password of the "rootDN".

The directive limits the number of results displayed for search operations. The default value for the directive is 500. The value must be checked and adapted, if necessary, but it should not be set to "unlimited" to make denial-of-service attacks to the directory service more difficult and prevent the database from being copied completely by unauthorised users.

This directive defines the time in seconds before a search is terminated. The default value for the directive is 3600. The value must be checked and adapted, if necessary, but it should not be set to "unlimited", because it makes denial-of-service attacks to the directory service much easier.

This directive allows restrictions similarly to sizeLimit and timeLimit at the database level. In this case, global limits are not complied with. For this directive, limits for each user are possible. The user information is thus similar to the user information within the framework of access control lists (see S 4.387 Secure assignment of access rights to OpenLDAP). It is recommended to set user-specific limits, for example, to prevent unauthenticated users from exploring the directory structure or to ease restrictions when they impair replication.

Additional directives are addressed in other safeguards regarding OpenLDAP, especially in safeguard S 4.385 Configuration of the database used by OpenLDAP.

Review questions:

© Federal Office for Information Security. All rights reserved.