APP.2.3 OpenLDAP
OpenLDAP is a freely available directory service that makes information about any objects — such as accounts, IT systems, or configurations — available in a standardized and defined manner within a data network...
Description
Introduction
OpenLDAP is a freely available directory service that makes information about any objects — such as accounts, IT systems, or configurations — available in a standardized and defined manner within a data network. The information can include simple attributes such as the names or numbers of objects, or also complex formats such as photos or certificates for electronic signatures. Typical use cases include address books or account management systems, but also configurations.
OpenLDAP represents a reference implementation for a server service within the Lightweight Directory Access Protocol (LDAP). As open-source software, OpenLDAP can be installed on a wide variety of operating systems and is considered one of the most widely used directory services. A particular feature of OpenLDAP is its overlays. Overlays extend the range of functions of OpenLDAP with numerous capabilities and are also used for basic functions such as logging, replication, and maintaining integrity.
Objective
The objective of this building block is to securely operate OpenLDAP-based directory services and to protect the information processed with them appropriately.
Scope and Modeling
The building block APP.2.3 OpenLDAP is to be applied to every OpenLDAP directory.
This building block addresses the threats and requirements specific to OpenLDAP. Version 2.4 of OpenLDAP is used as a basis. General security recommendations for directory services are found in the building block APP.2.1 General Directory Service. These must be taken into account additionally. The requirements described there are specified and supplemented in this building block.
OpenLDAP should generally be taken into account in the context of the building blocks ORP.4 Identity and Authorization Management, OPS.1.1.3 Patch and Change Management, CON.3 Data Backup Concept, OPS.1.2.2 Archiving, OPS.1.1.5 Logging, and OPS.1.1.2 Proper IT Administration.
Threat Landscape
Since IT-Grundschutz building blocks cannot address individual information domains, typical scenarios are used as the basis for describing the threat landscape. The following specific threats and vulnerabilities are of particular importance for the building block APP.2.3 OpenLDAP.
Missing or Insufficient Planning of OpenLDAP
OpenLDAP can be used in conjunction with numerous other applications. These applications can access and generally also modify the information in the directory service. If the deployment of OpenLDAP is not planned or is planned insufficiently, the following problems can occur:
- If backends and their associated directives and parameters are incorrectly selected, these unintentionally affect the functions that OpenLDAP can offer. For example, if the “back-ldif” backend is used for data storage to avoid installing an additional database, only rudimentary functions of the directory service are available. A large number of users or other objects cannot then be managed appropriately.
- If the deployment of overlays is poorly planned, unnecessary operations can be executed in OpenLDAP or other functions can be impaired. For example, accesses to the directory service are not logged or are logged incorrectly if the debug function of the slapd server itself and the “auditlog” and “accesslog” overlays are insufficiently planned.
- OpenLDAP can be run in an unsuitable system environment. If a distributed file system such as Network File System (NFS) is used to store the OpenLDAP data, file functions of OpenLDAP may not be usable. An example of this is the locking function used by many databases, which allows the directory service database to be locked when multiple users want to write to the database simultaneously.
- Incompatible versions of one or more applications could access the databases used by OpenLDAP. For example, the specifications of the LDAPv3 protocol are not met by OpenLDAP without additional extensions. In addition, connection problems with applications can arise if the wrong version of one or more programs that are not compatible with OpenLDAP is used.
Insufficient Separation of Offline and Online Access to OpenLDAP
The data managed by OpenLDAP (objects in the directory service as well as configuration settings) can be accessed via various methods. Offline and online access fulfills identical or partially identical functions. In online access, data is accessed via the LDAP protocol and the slapd server. In offline access, the database files are accessed directly, or an ldif export of the directory is edited and then reloaded into the database. If these methods are mixed or if the respective mode of operation for offline or online access is misinterpreted, numerous errors can occur. As a result, the resulting database is inconsistent for OpenLDAP and can therefore no longer be used without errors.
Requirements
The following are the specific requirements of the building block APP.2.3 OpenLDAP. The Information Security Officer (ISO) is responsible for ensuring that all requirements are met and verified in accordance with the established security concept. The ISO must always be involved in strategic decisions.
Additional roles are defined in the IT-Grundschutz Compendium. These SHOULD be filled insofar as this is meaningful and appropriate.
| Responsibilities | Roles |
|---|---|
| Primarily responsible | IT Operations |
| Additional responsibilities | None |
Exactly one role SHOULD be Primarily responsible. There may also be Additional responsibilities. If one of these additional roles is primarily responsible for fulfilling a requirement, that role is listed in square brackets after the requirement heading. The use of singular or plural says nothing about how many people SHOULD fill these roles.
Basic Requirements
The following requirements MUST be fulfilled as a priority for this building block.
APP.2.3.A1 Planning and Selection of Backends and Overlays for OpenLDAP (B)
The deployment of OpenLDAP in an institution MUST be carefully planned. If OpenLDAP is to be used together with other applications, the planning, configuration, and installation of the applications with OpenLDAP MUST be coordinated with each other. For the database used for data storage, it MUST be ensured that the version used is compatible. Backends and overlays for OpenLDAP MUST be selected restrictively. For this purpose, it MUST be ensured that the OpenLDAP overlays are used in the correct order. When planning OpenLDAP, the client applications to be supported MUST be taken into account.
APP.2.3.A2 DISCONTINUED (B)
This requirement has been discontinued.
APP.2.3.A3 Secure Configuration of OpenLDAP (B)
For the secure configuration of OpenLDAP, the slapd server MUST be correctly configured. The client applications used MUST also be securely configured. When configuring OpenLDAP, care MUST be taken to ensure that the permissions in the operating system are correctly set. The default values of all relevant configuration directives of OpenLDAP MUST be checked and adjusted if necessary. The backends and overlays of OpenLDAP MUST be included in the configuration. Appropriate time and size constraints MUST be defined for searching within OpenLDAP. The configuration on the slapd server MUST be checked after each change.
APP.2.3.A4 Configuration of the Database Used by OpenLDAP (B)
The access rights for newly created database files MUST be restricted to the identity under whose context the slapd server is operated. The default settings of the database used by OpenLDAP MUST be adapted.
APP.2.3.A5 Secure Assignment of Access Rights on OpenLDAP (B)
The global and database-specific access control lists (Access Control Lists) maintained in OpenLDAP MUST be correctly taken into account when using OpenLDAP. Database directives MUST take precedence over global directives.
APP.2.3.A6 Secure Authentication Against OpenLDAP (B)
If the directory service is to distinguish between different users, they MUST authenticate themselves appropriately. The authentication between the slapd server and the communicating parties MUST be encrypted. Only the hash values of passwords SHOULD be stored on clients and servers. A suitable hashing algorithm MUST be used.
Standard Requirements
Together with the basic requirements, the following requirements correspond to the state of the art for this building block. They SHOULD generally be met.
APP.2.3.A7 DISCONTINUED (S)
This requirement has been discontinued.
APP.2.3.A8 Restriction of Attributes in OpenLDAP (S)
Using overlays, attributes in OpenLDAP SHOULD be restricted. OpenLDAP SHOULD be configured so that values in the directory service only match a specific regular expression. In addition, overlays SHOULD be used to ensure that selected values exist only once in the directory tree. Such restrictions SHOULD only be applied to user data.
APP.2.3.A9 Partitioning and Replication in OpenLDAP (S)
When partitioning or replicating OpenLDAP, the distribution SHOULD be chosen appropriately for the security objectives. Changes to the data SHOULD be exchanged between the servers via replication. A replication mode SHOULD be chosen depending on network connections and availability requirements.
APP.2.3.A10 Secure Updating of OpenLDAP (S)
During updates, attention SHOULD be paid to whether the changes affect the backends or overlays used, as well as software dependencies. When updating to new releases, it SHOULD be checked whether the overlays and backends used continue to be available in the new version. If this is not the case, suitable migration paths SHOULD be selected.
If administrators use custom scripts, these SHOULD be checked to determine whether they work without problems with the updated version of OpenLDAP. The configuration and access rights SHOULD be carefully checked after an update.
APP.2.3.A11 Restriction of the OpenLDAP Runtime Environment (S)
The runtime environment of the slapd server SHOULD, where possible using means of the operating system, be restricted to the minimum required files, directories, and functions provided by the operating system. If containerization technologies are used for this purpose, they SHOULD be used taking into account SYS.1.6 Containerization. If the slapd server is operated as an exclusive service on a dedicated server, this SHOULD be sufficiently hardened.
APP.2.3.A12 DISCONTINUED (S)
This requirement has been discontinued.
APP.2.3.A13 DISCONTINUED (S)
This requirement has been discontinued.
Requirements for High Protection Needs
No requirements for high protection needs are defined for this building block.
Additional Information
Good to Know
No further information is available for the building block APP.2.3 OpenLDAP.