S 2.484 Planning OpenLDAP

Initiation responsibility: IT Security Officer, Head of IT

Implementation responsibility: Administrator, Head of IT

The use of OpenLDAP in an organisation requires careful planning. The planning of specific use of OpenLDAP is always preceded by the safeguard S 2.403 Planning the use of directory services. From the decisions taken in the framework of this safeguard, especially on how OpenLDAP is to be used, requirements for OpenLDAP arise. The specific planning also depends on the infrastructure used. If OpenLDAP is planned, at least the following aspects must be taken into consideration:

• Integration into other applications
  
  OpenLDAP provides a number of options of being integrated as support in operating systems and other applications, for example:
  • for user administration in Unix and Linux systems using the Pluggable Authentication Module (PAM) and the Name Service Switch (NSS),
  • as central directory service in heterogeneous networks or together with Active Directory using Samba (see S 5.17 Samba) or
  • as address book and certificate directory for e-mail programs such as Microsoft Outlook or Mozilla Thunderbird (see S 5.3 Groupware).
  
  
  If OpenLDAP is to be used together with other applications, it is absolutely necessary to harmonise the planning, configuration and installation of applications and OpenLDAP. Within the framework of the IT-Grundschutz system, corresponding safeguards must be implemented in parallel. "OpenLDAP Frequently Asked Questions" (http://www.openldap.org/faq) provide information on the connection to other applications in a separate section under Faq-O-Matic | OpenLDAP Software FAQ | Integration.
• Dissolution of dependencies
  
  To fulfil all functions of a directory service according to the LDAPv3 standard, OpenLDAP needs to use functions of other applications. This applies in particular to the BerkeleyDB used for data storage, which was optimised for OpenLDAP. Only with this hierarchical database, OpenLDAP provides its full range of functions. It must be taken into account in this case that BerkeleyDB and OpenLDAP are two software applications developed independently from each other. OpenLDAP requires a supported version of the BerkeleyDB.
  
  The appendix "Recommended Versions" of the OpenLDAP Administrator's Guide (http://www.openldap.org/doc) provides an overview of the supported or required versions of the BerkeleyDB. The appendix also contains information on other software packages on which the function of OpenLDAP depends. Their requirements must be taken into consideration, the installation of a Transport Layer Security version such as "OpenSSL" or "GnuTLS" and the installation of the Simple Authentication and Security Layers "Cyrus-SASL" in particular. The possible alternative "GnuSASL" is not yet supported by Open LDAP in version 2.4. Without these two supporting applications, OpenLDAP cannot implement the LDAPv3 standard completely. If the authentication is to be secured using Kerberos, the "Heimdal Kerberos" or "MIT Kerberos" services must be installed. Instead of the "TCP Wrappers" software to protect the communications with the directory service referred to in the appendix of the Administrators Guide, another IP filter mechanism should be used (see S 4.238 Use of local packet filters).
• Configuration method selection
  
  In version 2.3 and higher, OpenLDAP supports two different configuration methods. The classic configuration is carried out statically in a configuration file (slapd.conf) reading the server process "slapd" when starting the system. The more recent configuration is also referred to as online configuration and stores the configuration settings in a special area of the directory tree ("slapd-config"). The online configuration offers several advantages.
  • Changes to the online configuration are done by means of LDAP operations and are possible using a network connection without accessing the file system of the IT system on which OpenLDAP is operated.
  • Administration is possible using graphic LDAP clients which are easy to operate.
  • Settings in the online configuration can be changed while the server is running and immediately become effective without requiring a restart of the "slapd" server process.
  • The configuration can be replicated to other servers as part of the directory, making administration of distributed directory services easier. For example, changes to access rights become effective more quickly on all servers involved.
  On the other hand, not all backends and overlays support the online configuration. In addition, the static configuration protects against hasty changes to the configuration and limits the impacts of security incidents.
  
  When planning OpenLDAP, one configuration method should be used and then applied and maintained permanently. The online configuration makes all the more sense,
  • the more complex the directory sevice is,
  • the higher the availability requirements are, and
  • the more servers are involved in a distributed structure.
  
  
• Selection of the backends to be used
  
  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. Details on the selection of backends can be found in safeguard S 2.485 Selection of backends for OpenLDAP.
• Selection of the overlays to be used
  
  Just as for backends, a list of the overlays to be used must also be prepared. In order to decide on the use of overlays, the corresponding chapter of the OpenLDAP Administrator's Guide should be worked through. For each overlay, it must be checked if it has an experimental status or is no longer maintained. In both cases, the use in a production environment should be avoided. In addition, it must be checked for each overlay using the associated documentation such as the man page whether the online configuration option is supported. When selecting overlays, it must be considered that the order of their calls ("batching") can have an impact on their operability. This is for example the case when an overlay converts data that is expected by another overlay in the original form.
• Implementation of the defined tree structure
  
  When planning the directory service, its structure was defined, which must be now taken as basis for the planning of OpenLDAP:
  
  • A suitable name model must be selected if this has not already been done in the general planning phase. The classic name mode of the X.500 standard is based on mapping the organisation structures and knows identifiers such as "OrganizationalUnit" (OU), "Organization" (O), and "Country" (C) (e.g. OU=bsi, O=bund, C=de). In contrast, the Internet style name model is being used more and more often. On the higher levels of the tree structure, this name model only uses "DomainComponents" (DC) without giving different names to the individual components(e.g. DC=bsi, DC=bund, DC=de).
  • Suitable schemas which match the name model and the requested structure must be selected. Schemas define which data can be stored in the database and in which form and which relationships exist between the data. OpenLDAP already includes all schemas specified in RFCs with additional schemas being available on the Internet. The existing schemas are generally sufficient for normal applications. If, however, organisation-specific scheme extensions are necessary, then these must be implemented with extreme care as the operability of the directory service depends on them.
  • By means of overlays, OpenLDAP offers the additional option to restrict attributes of objects during operation. A correspondingly configured slapd server will then not perform assignments of objects admissible according to the schemas. For detailed information see safeguard S 4.386 Restriction in attributes in OpenLDAP.
  • Schemas may also be required independently of the defined tree structure in order to ensure error-free function of backends and overlays which store their data via LDAP or in the LDIF format. The "backmonitor" backend, for example, requires the "core.schema" schema. Such dependencies must be checked in the documentation of the components and taken into account.
  • In order to define the tree structure in OpenLDAP, it must also be decided whether dynamic objects are admitted by the "dds" (dynamic directory services) overlay. Such objects are automatically removed from the directory service after a defined period of time or in the absence of certain events. The "dynlist" (dynamic lists) overlay can be used to form dynamic groups. Instead of being populated manually, dynamic groups automatically contain all objects corresponding to a defined search criterion. This makes it possible, for example, to create groups or lists which contain all employees on one floor without any further maintenance effort. Dynamic lists can also be used for access control (see S 4.387 Secure assignment of access rights to OpenLDAP). However, care must be taken in this case, as the reduced administration effort may result in complex access authorisations.
  
  
  
• Planning user access
  
  The access by anonymous users should be avoided. If, however, anonymous access is still necessary, the directory service should only contain data with low protection requirements. If a partial area with low protection requirements is to be accessed and the directory service also contains data with higher protection requirements at the same time, it is recommended to install two different slapd server services, one of which allows anonymous access and only contains the data with low protection requirements. For example, this problem can be solved by replication (see S 4.389 Partitioning and replication in OpenLDAP). For this purpose, only the name and the extension number are, for instance, replicated from a directory service with data of employees for a public phone directory.
  
  Planning user access also includes defining the responsibilities of administrators. In this case, it is possible that different administrators can be responsible for different databases in the directory service (see also S 2.407 Planning the administration of directory services).
• Planning the use of clients
  
  The planning of OpenLDAP may not remain restricted to the slapd server, the selection and support of the clients must also be taken into consideration. OpenLDAP provides suitable applications in the form of the ldap* tools. These tools, however, are controlled completely via the command line. They require a high amount of training and are accepted by the users only to a very limited extent. In practice, graphic tools are used in most cases or the client is part of an application. If the user has already controlled directory services via LDAP, it might be possible that client applications whose capabilities are to be taken into account when planning OpenLDAP have already been used. It can also be useful to have functions which are not planned according to the LDAP specification taken over by the slapd server if the clients do not have corresponding functions. Overlays for OpenLDAP provide these functions:
  
  • The "chain" (chaining) overlay enables a server to follow referrals (these are references to higher-level servers, replicas, etc.) itself instead of communicating the address to the client under which the server could search itself.
  • If the "valsort" (value sorting) overlay is used, the server transmits search results to a client in sorted order.
  
  
  
• Performance tuning
  
  Finally, the required performance which might have a substantial effect on the availability must also be taken into account when planning OpenLDAP. Attributes frequently searched for must be indexed in particular.

Review questions:

• Is the version of the BerkeleyDB used supported by OpenLDAP?
• Are the dependencies between OpenLDAP and other applications checked and fulfilled?
• Are backends and overlays meeting the requirements selected for OpenLDAP?
• Are the OpenLDAP overlays used in the correct order?
• Is the selection and support of client applications for OpenLDAP taken into consideration when planning OpenLDAP?