S 2.485 Selection of backends for OpenLDAP

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Head of IT, Administrator

Based on the intended possible uses of the directory service, it must be defined which backends are to be provided for subsequent installation and configuration:

• If OpenLDAP manages one or several databases directly, it is necessary to select a backend suitable for corresponding data storage. Regarding the management of data, OpenLDAP is optimised to use the database management system (DBMS) BerkeleyDB. For the BerkeleyDB, two different backends are available: "back-bdb" and the refinement "back-hdb". The Backend "back-hdb" generates a higher load in the IT system and imposes higher requirements for the data storage device required for the temporary storage, but has a wider range of functions and supports the renaming of entire subtrees in the directory structure (subtree renaming). The medium-term planning of the OpenLDAP team aims at giving up "back-bdb". For new installations of OpenLDAP, it is thus recommended to use "back-hdb".
  
  Using the "back-ldif" backend, OpenLDAP can also store data in files in the LDAP Data Interchange Format (LDIF). In the LDIF format, the entire database is stored in the plain text format in text files. This type of data storage is inefficient for larger amounts of data and unsuitable for a large number of users. If the online configuration is used, "back-ldif" is still necessary, since the suffix "CN=config" is always stored in the LDIF format.
• OpenLDAP can be used completely or partially as proxy for other LDAP servers. In this case, the "back-ldap" backend or the refinement "back-meta" are required. Compared to "back-ldap", "back-meta" is able to address different servers at the same time. The backend has a wider range of functions than "back-ldap", but its configuration is also very complex. For most application scenarios, "back-ldap" is sufficient.
  
  The "back-ldap" backend is also required whenever the slapd server itself triggers ldap operations. This is, for example, the case when the slapd server resolves references autonomously or a replication is carried out in the push mode.
• Moreover, it is possible that OpenLDAP accesses data of a relational database. For this purpose, the "back-sql" backend is used. It is pointed out that a relational database is not suited to store the data of a directory service completely. It can be useful, however, to connect OpenLDAP to a relational database in order to read individual additional information from such a source of data, for example telephone numbers from a telephone list in a directory service managing all users of an organisation.
• If necessary, OpenLDAP must obtain data from proprietary development applications or is used to control these applications. If communication does not take place via the LDAP standard, one of the "back-perl", "back-shell" or "back-sock" backends is required depending on the interface created in-house.
• If it is decided that the operation of OpenLDAP is to be monitored (monitoring), the "back-monitor" backend provides the necessary functions (see S 4.407 Logging when using OpenLDAP).

Backends other than the backends mentioned in this safeguard should not be taken into account in the planning for the production environments. They are either outdated (back-ldbm, back-tcl), only intended for testing purposes (back-passwd, back-null) or still have an experimental status (back-dnssrv, back-ndb, back-relay) in OpenLDAP version 2.4.

Review questions:

• Are only the required OpenLDAP backends used in the production environment?