Documentation for a newer release is available. View Latest

Directory Servers

OpenLDAP

LDAP (Lightweight Directory Access Protocol) is a set of open protocols used to access centrally stored information over a network. It is based on the X.500 standard for directory sharing, but is less complex and resource-intensive. For this reason, LDAP is sometimes referred to as “X.500 Lite”.

Like X.500, LDAP organizes information in a hierarchical manner using directories. These directories can store a variety of information such as names, addresses, or phone numbers, and can even be used in a manner similar to the Network Information Service (NIS), enabling anyone to access their account from any machine on the LDAP enabled network.

LDAP is commonly used for centrally managed users and groups, user authentication, or system configuration. It can also serve as a virtual phone directory, allowing users to easily access contact information for other users. Additionally, it can refer a user to other LDAP servers throughout the world, and thus provide an ad-hoc global repository of information. However, it is most frequently used within individual organizations such as universities, government departments, and private companies.

This section covers the installation and configuration of OpenLDAP 2.4, an open source implementation of the LDAPv2 and LDAPv3 protocols.

Introduction to LDAP

Using a client-server architecture, LDAP provides a reliable means to create a central information directory accessible from the network. When a client attempts to modify information within this directory, the server verifies the user has permission to make the change, and then adds or updates the entry as requested. To ensure the communication is secure, the Transport Layer Security (TLS) cryptographic protocol can be used to prevent an attacker from intercepting the transmission.

Using Mozilla NSS

The OpenLDAP suite in Fedora 39 no longer uses OpenSSL. Instead, it uses the Mozilla implementation of Network Security Services (NSS). OpenLDAP continues to work with existing certificates, keys, and other TLS configuration. For more information on how to configure it to use Mozilla certificate and key database, see How do I use TLS/SSL with Mozilla NSS.

The LDAP server supports several database systems, which gives administrators the flexibility to choose the best suited solution for the type of information they are planning to serve. Because of a well-defined client Application Programming Interface (API), the number of applications able to communicate with an LDAP server is numerous, and increasing in both quantity and quality.

LDAP Terminology

The following is a list of LDAP-specific terms that are used within this chapter:

entry: A single unit within an LDAP directory. Each entry is identified by its unique Distinguished Name (DN).
attribute: Information directly associated with an entry. For example, if an organization is represented as an LDAP entry, attributes associated with this organization might include an address, a fax number, etc. Similarly, people can be represented as entries with common attributes such as personal telephone number or email address.
An attribute can either have a single value, or an unordered space-separated list of values. While certain attributes are optional, others are required. Required attributes are specified using the objectClass definition, and can be found in schema files located in the /etc/openldap/slapd.d/cn=config/cn=schema/ directory.
The assertion of an attribute and its corresponding value is also referred to as a Relative Distinguished Name (RDN). Unlike distinguished names that are unique globally, a relative distinguished name is only unique per entry.
LDIF: The LDAP Data Interchange Format (LDIF) is a plain text representation of an LDAP entry. It takes the following form: +

id dn: distinguished_name
attribute_type: attribute_value…
attribute_type: attribute_value…
…

 +
The optional _id_ is a number determined by the application that is used to edit the entry. Each entry can contain as many _attribute_type_ and _attribute_value_ pairs as needed, as long as they are all defined in a corresponding schema file. A blank line indicates the end of an entry.

OpenLDAP Features

OpenLDAP suite provides a number of important features:

LDAPv3 Support — Many of the changes in the protocol since LDAP version 2 are designed to make LDAP more secure. Among other improvements, this includes the support for Simple Authentication and Security Layer (SASL), Transport Layer Security (TLS), and Secure Sockets Layer (SSL) protocols.
LDAP Over IPC — The use of inter-process communication (IPC) enhances security by eliminating the need to communicate over a network.
IPv6 Support — OpenLDAP is compliant with Internet Protocol version 6 (IPv6), the next generation of the Internet Protocol.
LDIFv1 Support — OpenLDAP is fully compliant with LDIF version 1.
Updated C API — The current C API improves the way programmers can connect to and use LDAP directory servers.
Enhanced Standalone LDAP Server — This includes an updated access control system, thread pooling, better tools, and much more.

OpenLDAP Server Setup

The typical steps to set up an LDAP server on Fedora are as follows:

Install the OpenLDAP suite. See Installing the OpenLDAP Suite for more information on required packages.
Customize the configuration as described in Configuring an OpenLDAP Server.
Start the slapd service as described in Running an OpenLDAP Server.
Use the ldapadd utility to add entries to the LDAP directory.
Use the ldapsearch utility to verify that the slapd service is accessing the information correctly.

Installing the OpenLDAP Suite

The suite of OpenLDAP libraries and tools is provided by the following packages:

Table 1. List of OpenLDAP packages
Package	Description
openldap	A package containing the libraries necessary to run the OpenLDAP server and client applications.
openldap-clients	A package containing the command line utilities for viewing and modifying directories on an LDAP server.
openldap-servers	A package containing both the services and utilities to configure and run an LDAP server. This includes the Standalone LDAP Daemon, `slapd`.
openldap-servers-sql	A package containing the SQL support module.

Additionally, the following packages are commonly used along with the LDAP server:

Table 2. List of commonly installed additional LDAP packages
Package	Description
nss-pam-ldapd	A package containing `nslcd`, a local LDAP name service that allows a user to perform local LDAP queries.
mod_ldap	A package containing the `mod_authnz_ldap` and `mod_ldap` modules. The `mod_authnz_ldap` module is the LDAP authorization module for the Apache HTTP Server. This module can authenticate users' credentials against an LDAP directory, and can enforce access control based on the user name, full DN, group membership, an arbitrary attribute, or a complete filter string. The `mod_ldap` module contained in the same package provides a configurable shared memory cache, to avoid repeated directory access across many HTTP requests, and also support for SSL/TLS.

To install these packages, use the dnf command in the following form:

dnf install package…

For example, to perform the basic LDAP server installation, type the following at a shell prompt as root:

~]# dnf install openldap openldap-clients openldap-servers

Note that you must have superuser privileges (that is, you must be logged in as root) to run this command. For more information on how to install new packages in Fedora, see Installing Packages.

Overview of OpenLDAP Server Utilities

To perform administrative tasks, the openldap-servers package installs the following utilities along with the slapd service:

Table 3. List of OpenLDAP server utilities
Command	Description
slapacl	Allows you to check the access to a list of attributes.
slapadd	Allows you to add entries from an LDIF file to an LDAP directory.
slapauth	Allows you to check a list of IDs for authentication and authorization permissions.
slapcat	Allows you to pull entries from an LDAP directory in the default format and save them in an LDIF file.
slapdn	Allows you to check a list of Distinguished Names (DNs) based on available schema syntax.
slapindex	Allows you to re-index the `slapd` directory based on the current content. Run this utility whenever you change indexing options in the configuration file.
slappasswd	Allows you to create an encrypted user password to be used with the ldapmodify utility, or in the `slapd` configuration file.
slapschema	Allows you to check the compliance of a database with the corresponding schema.
slaptest	Allows you to check the LDAP server configuration.

For a detailed description of these utilities and their usage, see the corresponding manual pages as referred to in Installed Documentation.

Make sure the files have correct owner

Although only root can run slapadd, the slapd service runs as the ldap user. Because of this, the directory server is unable to modify any files created by slapadd. To correct this issue, after running the slapadd utility, type the following at a shell prompt:

chown -R ldap:ldap /var/lib/ldap

Stop slapd before using these utilities

To preserve the data integrity, stop the slapd service before using slapadd, slapcat, or slapindex. You can do so by typing the following at a shell prompt as root:

~]# systemctl stop slapd.service

For more information on how to start, stop, restart, and check the current status of the slapd service, see Running an OpenLDAP Server.

Overview of OpenLDAP Client Utilities

The openldap-clients package installs the following utilities which can be used to add, modify, and delete entries in an LDAP directory:

Table 4. List of OpenLDAP client utilities
Command	Description
ldapadd	Allows you to add entries to an LDAP directory, either from a file, or from standard input. It is a symbolic link to ldapmodify -a.
ldapcompare	Allows you to compare given attribute with an LDAP directory entry.
ldapdelete	Allows you to delete entries from an LDAP directory.
ldapexop	Allows you to perform extended LDAP operations.
ldapmodify	Allows you to modify entries in an LDAP directory, either from a file, or from standard input.
ldapmodrdn	Allows you to modify the RDN value of an LDAP directory entry.
ldappasswd	Allows you to set or change the password for an LDAP user.
ldapsearch	Allows you to search LDAP directory entries.
ldapurl	Allows you to compose or decompose LDAP URLs.
ldapwhoami	Allows you to perform a `whoami` operation on an LDAP server.

With the exception of ldapsearch, each of these utilities is more easily used by referencing a file containing the changes to be made rather than typing a command for each entry to be changed within an LDAP directory. The format of such a file is outlined in the man page for each utility.

Overview of Common LDAP Client Applications

Although there are various graphical LDAP clients capable of creating and modifying directories on the server, none of them is included in Fedora. Popular applications that can access directories in a read-only mode include Mozilla Thunderbird, Evolution, or Ekiga.

Configuring an OpenLDAP Server

By default, the OpenLDAP configuration is stored in the /etc/openldap/ directory. The following table highlights the most important directories and files within this directory:

Table 5. List of OpenLDAP configuration files and directories
Path	Description
`/etc/openldap/ldap.conf`	The configuration file for client applications that use the OpenLDAP libraries. This includes ldapadd, ldapsearch, Evolution, etc.
`/etc/openldap/slapd.d/`	The directory containing the `slapd` configuration.

Note that OpenLDAP no longer reads its configuration from the /etc/openldap/slapd.conf file. Instead, it uses a configuration database located in the /etc/openldap/slapd.d/ directory. If you have an existing slapd.conf file from a previous installation, you can convert it to the new format by running the following command as root:

~]# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/

The slapd configuration consists of LDIF entries organized in a hierarchical directory structure, and the recommended way to edit these entries is to use the server utilities described in Overview of OpenLDAP Server Utilities.

Do not edit LDIF files directly

An error in an LDIF file can render the slapd service unable to start. Because of this, it is strongly advised that you avoid editing the LDIF files within the /etc/openldap/slapd.d/ directly.

Changing the Global Configuration

Global configuration options for the LDAP server are stored in the /etc/openldap/slapd.d/cn=config.ldif file. The following directives are commonly used:

olcAllows: The olcAllows directive allows you to specify which features to enable. It takes the following form:

olcAllows: feature…

It accepts a space-separated list of features as described in Available olcAllows options. The default option is bind_v2.

Table 6. Available olcAllows options
Option	Description
`bind_v2`	Enables the acceptance of LDAP version 2 bind requests.
`bind_anon_cred`	Enables an anonymous bind when the Distinguished Name (DN) is empty.
`bind_anon_dn`	Enables an anonymous bind when the Distinguished Name (DN) is not empty.
`update_anon`	Enables processing of anonymous update operations.
`proxy_authz_anon`	Enables processing of anonymous proxy authorization control.

Example 1. Using the olcAllows directive

olcAllows: bind_v2 update_anon

olcConnMaxPending: The olcConnMaxPending directive allows you to specify the maximum number of pending requests for an anonymous session. It takes the following form:

olcConnMaxPending: number

The default option is 100.

Example 2. Using the olcConnMaxPending directive

olcConnMaxPending: 100

olcConnMaxPendingAuth: The olcConnMaxPendingAuth directive allows you to specify the maximum number of pending requests for an authenticated session. It takes the following form: +

olcConnMaxPendingAuth: number

The default option is 1000.

Example 3. Using the olcConnMaxPendingAuth directive

olcConnMaxPendingAuth: 1000

olcDisallows: The olcDisallows directive allows you to specify which features to disable. It takes the following form: +

olcDisallows: feature…

It accepts a space-separated list of features as described in Available olcDisallows options. No features are disabled by default.

Table 7. Available olcDisallows options
Option	Description
`bind_anon`	Disables the acceptance of anonymous bind requests.
`bind_simple`	Disables the simple bind authentication mechanism.
`tls_2_anon`	Disables the enforcing of an anonymous session when the STARTTLS command is received.
`tls_authc`	Disallows the STARTTLS command when authenticated.

Example 4. Using the olcDisallows directive

olcDisallows: bind_anon

olcIdleTimeout: The olcIdleTimeout directive allows you to specify how many seconds to wait before closing an idle connection. It takes the following form: +

olcIdleTimeout: number

This option is disabled by default (that is, set to 0).

Example 5. Using the olcIdleTimeout directive

olcIdleTimeout: 180

olcLogFile: The olcLogFile directive allows you to specify a file in which to write log messages. It takes the following form: +

olcLogFile: file_name

The log messages are written to standard error by default.

Example 6. Using the olcLogFile directive

olcLogFile: /var/log/slapd.log

olcReferral: The olcReferral option allows you to specify a URL of a server to process the request in case the server is not able to handle it. It takes the following form: +

olcReferral: URL

This option is disabled by default.

Example 7. Using the olcReferral directive

olcReferral: ldap://root.openldap.org

olcWriteTimeout: The olcWriteTimeout option allows you to specify how many seconds to wait before closing a connection with an outstanding write request. It takes the following form: +

olcWriteTimeout

This option is disabled by default (that is, set to 0).

Example 8. Using the olcWriteTimeout directive

olcWriteTimeout: 180

Changing the Database-Specific Configuration

By default, the OpenLDAP server uses Berkeley DB (BDB) as a database back end. The configuration for this database is stored in the /etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif file. The following directives are commonly used in a database-specific configuration:

olcReadOnly: The olcReadOnly directive allows you to use the database in a read-only mode. It takes the following form: +

olcReadOnly: boolean

It accepts either TRUE (enable the read-only mode), or FALSE (enable modifications of the database). The default option is FALSE.

Example 9. Using the olcReadOnly directive

olcReadOnly: TRUE

olcRootDN: The olcRootDN directive allows you to specify the user that is unrestricted by access controls or administrative limit parameters set for operations on the LDAP directory. It takes the following form: +

olcRootDN: distinguished_name

It accepts a Distinguished Name (DN). The default option is cn=Manager,dn=my-domain,dc=com.

Example 10. Using the olcRootDN directive

olcRootDN: cn=root,dn=example,dn=com

olcRootPW: The olcRootPW directive allows you to set a password for the user that is specified using the olcRootDN directive. It takes the following form: +

olcRootPW: password

It accepts either a plain text string, or a hash. To generate a hash, type the following at a shell prompt:

~]$ slappaswd
New password:
Re-enter new password:
{SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD

Example 11. Using the olcRootPW directive

olcRootPW: {SSHA}WczWsyPEnMchFf1GRTweq2q7XJcvmSxD

olcSuffix: The olcSuffix directive allows you to specify the domain for which to provide information. It takes the following form: +

olcSuffix: domain_name

It accepts a fully qualified domain name (FQDN). The default option is dc=my-domain,dc=com.

Example 12. Using the olcSuffix directive

olcSuffix: dc=example,dc=com

Extending Schema

Since OpenLDAP 2.3, the /etc/openldap/slapd.d/ directory also contains LDAP definitions that were previously located in /etc/openldap/schema/. It is possible to extend the schema used by OpenLDAP to support additional attribute types and object classes using the default schema files as a guide. However, this task is beyond the scope of this chapter. For more information on this topic, see https://www.openldap.org/doc/admin/schema.html.

Establishing a Secure Connection

OpenLDAP clients and servers can be secured using the Transport Layer Security (TLS) framework. TLS is a cryptographic protocol designed to provide communication security over the network. As noted above, OpenLDAP suite in Fedora uses Mozilla NSS as the TLS implementation.

To establish a secure connection using TLS, obtain the required certificates as described in How do I use TLS/SSL with Mozilla NSS. Then, a number of options must be configured on both the client and the server. At a minimum, a server must be configured with the Certificate Authority (CA) certificates and also its own server certificate and private key. The clients must be configured with the name of the file containing all the trusted CA certificates.

Typically, a server only needs to sign a single CA certificate. A client may want to connect to a variety of secure servers, therefore it is common to specify a list of several trusted CAs in its configuration.

Server Configuration

This section lists global configuration directives for slapd that need to be specified in the /etc/openldap/slapd.d/cn=config.ldif file on an OpenLDAP server in order to establish TLS.

While the old style configuration uses a single file, normally installed as /usr/local/etc/openldap/slapd.conf, the new style uses a slapd backend database to store the configuration. The configuration database normally resides in the /usr/local/etc/openldap/slapd.d/ directory.

The following directives are also valid for establishing SSL. In addition to TLS directives, you need to enable a port dedicated to SSL on the server side – typically it is port 636. To do so, edit the /etc/sysconfig/slapd file and append the ldaps:/// string to the list of URLs specified with the SLAPD_URLS directive.

olcTLSCACertificateFile: The olcTLSCACertificateFile directive specifies the file encoded with Privacy-Enhanced Mail (PEM) schema that contains trusted CA certificates. The directive takes the following form: +

olcTLSCACertificateFile: path

Replace path either with a path to the CA certificate file, or, if you use Mozilla NSS, with a certificate name.

olcTLSCACertificatePath: The olcTLSCACertificatePath directive specifies the path to a directory containing individual CA certificates in separate files. This directory must be specially managed with the OpenSSL c_rehash utility that generates symbolic links with the hashed names that point to the actual certificate files. In general, it is simpler to use the olcTLSCACertificateFile directive instead.
If Mozilla NSS is used, olcTLSCACertificatePath accepts a path to the Mozilla NSS database (as shown in Using olcTLSCACertificatePath with Mozilla NSS). In such a case, c_rehash is not needed.
The directive takes the following form:

olcTLSCACertificatePath: path

Replace path with a path to the directory containing the CA certificate files, or with a path to a Mozilla NSS database file.

Example 13. Using olcTLSCACertificatePath with Mozilla NSS

With Mozilla NSS, the olcTLSCACertificatePath directive specifies the path of the directory containing the NSS certificate and key database files. For example:

olcTLSCACertificatePath: sql:/home/nssdb/sharednssdb

The certutil command is used to add a CA certificate to these NSS database files:

certutil -d sql:/home/nssdb/sharednssdb -A -n "CA_certificate" -t CT,, -a -i certificate.pem

The above command adds a CA certificate stored in a PEM-formatted file named certificate.pem. The -d option specifies the database directory containing the certificate and key database files, the -n option sets a name for the certificate, -t CT,, means that the certificate is trusted to be used in TLS clients and servers. The -A option adds an existing certificate to a certificate database, the -a option allows the use of ASCII format for input or output, and the -i option passes the certificate.pem input file to the command.

olcTLSCertificateFile: The olcTLSCertificateFile directive specifies the file that contains the slapd server certificate. The directive takes the following form: +

olcTLSCertificateFile: path

Replace path with a path to the slapd server certificate file, or, if you use Mozilla NSS, with a certificate name.

Example 14. Using olcTLSCertificateFile with Mozilla NSS

When using Mozilla NSS with certificate and key database files specified with the olcTLSCACertificatePath directive, olcTLSCertificateFile is used to specify the name of the certificate to use. First, execute the following command to view a list of certificates available in your NSS database file:

certutil -d sql:/home/nssdb/sharednssdb -L

Select a certificate from the list and pass its name to olcTLSCertificateFile. For example:

olcTLSCertificateFile slapd_cert

olcTLSCertificateKeyFile: The olcTLSCertificateKeyFile directive specifies the file that contains the private key that matches the certificate stored in the file specified with olcTLSCertificateFile. Note that the current implementation does not support encrypted private keys, and therefore the containing file must be sufficiently protected. The directive takes the following form:

olcTLSCertificateKeyFile: path

Replace path with a path to the private key file if you use PEM certificates. When using Mozilla NSS, path stands for the name of a file that contains the password for the key for the certificate specified with the olcTLSCertificateFile directive (see Using olcTLSCertificateKeyFile with Mozilla NSS).

Example 15. Using olcTLSCertificateKeyFile with Mozilla NSS

When using Mozilla NSS,