SupportConsoleDevelopersStart a trialContact

9.2. OpenLDAP

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

Note

Starting with Red Hat Enterprise Linux 7.4, the openldap-server package has been deprecated and will not be included in a future major release of Red Hat Enterprise Linux. For this reason, migrate to Identity Management included in Red Hat Enterprise Linux or to Red Hat Directory Server. For further details about Identity Management, see Linux Domain Identity, Authentication, and Policy Guide. For further details about Directory Server, see Section 9.1, “Red Hat Directory Server”.

9.2.1. 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.

Important

The OpenLDAP suite in Red Hat Enterprise Linux 7.5 and later no longer uses Mozilla implementation of Network Security Services (NSS). Instead, it uses the OpenSSL. OpenLDAP continues to work with existing NSS database configuration.

Important

Due to the vulnerability described in Resolution for POODLE SSLv3.0 vulnerability (CVE-2014-3566) for components that do not allow SSLv3 to be disabled via configuration settings, Red Hat recommends that you do not rely on the SSLv3 protocol for security. OpenLDAP is one of the system components that do not provide configuration parameters that allow SSLv3 to be effectively disabled. To mitigate the risk, it is recommended that you use the stunnel command to provide a secure tunnel, and disable stunnel from using SSLv3. For more information on using stunnel, see the Red Hat Enterprise Linux 7 Security Guide.
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.

9.2.1.1. 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, and so on. 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.

9.2.1.2. 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.

9.2.1.3. OpenLDAP Server Setup

The typical steps to set up an LDAP server on Red Hat Enterprise Linux are as follows:
  1. Install the OpenLDAP suite. See Section 9.2.2, “Installing the OpenLDAP Suite” for more information on required packages.
  2. Customize the configuration as described in Section 9.2.3, “Configuring an OpenLDAP Server”.
  3. Start the slapd service as described in Section 9.2.5, “Running an OpenLDAP Server”.
  4. Use the ldapadd utility to add entries to the LDAP directory.
  5. Use the ldapsearch utility to verify that the slapd service is accessing the information correctly.

9.2.2. Installing the OpenLDAP Suite

The suite of OpenLDAP libraries and tools is provided by the following packages:
Table 9.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.
compat-openldap A package containing the OpenLDAP compatibility libraries.
Additionally, the following packages are commonly used along with the LDAP server:
Table 9.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. Note that this package is provided by the Optional channel. See Adding the Optional and Supplementary Repositories in the System Administrator's Guide for more information on Red Hat additional channels.
To install these packages, use the yum command in the following form: 
yum install package…
For example, to perform the basic LDAP server installation, type the following at a shell prompt: 
~]# yum 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 Red Hat Enterprise Linux, see Installing Packages in the System Administrator's Guide.

9.2.2.1. Overview of OpenLDAP Server Utilities

To perform administrative tasks, the openldap-servers package installs the following utilities along with the slapd service:
Table 9.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 the section called “Installed Documentation”.

Important

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 slapdadd utility, type the following at a shell prompt: 
~]# chown -R ldap:ldap /var/lib/ldap

Warning

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: 
~]# systemctl stop slapd.service
For more information on how to start, stop, restart, and check the current status of the slapd service, see Section 9.2.5, “Running an OpenLDAP Server”.

9.2.2.2. 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 9.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.

9.2.2.3. 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 Red Hat Enterprise Linux. Popular applications that can access directories in a read-only mode include Mozilla Thunderbird, Evolution, or Ekiga.

9.2.3. 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 9.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, and so on.
/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: 
~]# 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 Section 9.2.2.1, “Overview of OpenLDAP Server Utilities”.

Important

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.

9.2.3.1. 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 Table 9.6, “Available olcAllows options”. The default option is bind_v2.
Table 9.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 9.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 9.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 9.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 Table 9.7, “Available olcDisallows options”. No features are disabled by default.
Table 9.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 9.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 9.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 9.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 9.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 9.8. Using the olcWriteTimeout directive

olcWriteTimeout: 180

9.2.3.2. The Front End Configuration

The OpenLDAP front end configuration is stored in the etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif file and defines global database options, such as access control lists (ACL). For details, see the Global Database Options section in the slapd-config(5) man page.

9.2.3.3. The Monitor Back End

The /etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif file controls the OpenLDAP monitor back end. If enabled, it is automatically generated and dynamically updated by OpenLDAP with information about the running status of the daemon. The suffix is cn=Monitor and cannot be changed. For further details, see the slapd-monitor(5) man page.

9.2.3.4. Database-Specific Configuration

By default, the OpenLDAP server uses the hdb database back end. Besides that it uses a hierarchical database layout which supports subtree renames, it is identical to the bdb back end and uses the same configuration options. The configuration for this database back end is stored in the /etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif file.
For a list of other back end databases, see the slapd.backends(5) man page. Database-specific settings you find in the man page for the individual back ends. For example: 
# man slapd-hdb

Note

The bdb and hdb back ends are deprecated. Consider using the mdb back end for new installations instead.
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.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 9.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 9.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 9.12. Using the olcSuffix directive

olcSuffix: dc=example,dc=com

9.2.3.5. 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://openldap.org/doc/admin24/schema.html.

9.2.3.6. Establishing a Secure Connection

The OpenLDAP suite 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. OpenLDAP suite in Red Hat Enterprise Linux 7 uses OpenSSL as the TLS implementation.
To establish a secure connection using TLS, obtain the required certificates. Then, a number of options must be configured on both the client and the server. At 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 back end 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 with the path to the CA certificate file.
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.
The directive takes the following form: 
olcTLSCACertificatePath: path
Replace path with a path to the directory containing the CA certificate files. The specified directory must be managed with the OpenSSL c_rehash utility.
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 server certificate file of the slapd service.
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.
Client Configuration
Specify the following directives in the /etc/openldap/ldap.conf configuration file on the client system. Most of these directives are parallel to the server configuration options. Directives in/etc/openldap/ldap.conf are configured on a system-wide basis, however, individual users may override them in their ~/.ldaprc files.
The same directives can be used to establish an SSL connection. The ldaps:// string must be used instead of ldap:// in OpenLDAP commands such as ldapsearch. This forces commands to use the default port for SSL, port 636, configured on the server.
TLS_CACERT
The TLS_CACERT directive specifies a file containing certificates for all of the Certificate Authorities the client will recognize. This is equivalent to the olcTLSCACertificateFile directive on a server. TLS_CACERT should always be specified before TLS_CACERTDIR in /etc/openldap/ldap.conf. The directive takes the following form: 
TLS_CACERT path
Replace path with a path to the CA certificate file.
TLS_CACERTDIR
The TLS_CACERTDIR directive specifies the path to a directory that contains Certificate Authority certificates in separate files. As with olcTLSCACertificatePath on a server, the specified directory must be managed with the OpenSSL c_rehash utility. 
TLS_CACERTDIR directory
Replace directory with a path to the directory containing CA certificate files.
TLS_CERT
The TLS_CERT specifies the file that contains a client certificate. This directive can only be specified in a user's ~/.ldaprc file. The directive takes the following form: 
TLS_CERT path
Replace path with a path to the client certificate file.
TLS_KEY
The TLS_KEY specifies the file that contains the private key that matches the certificate stored in the file specified with the TLS_CERT directive. As with olcTLSCertificateFile on a server, encrypted key files are not supported, so the file itself must be carefully protected. This option is only configurable in a user's ~/.ldaprc file.
The TLS_KEY directive takes the following form: 
TLS_KEY path
Replace path with a path to the client certificate file.

9.2.3.7. Setting Up Replication

Replication is the process of copying updates from one LDAP server (provider) to one or more other servers or clients (consumers). A provider replicates directory updates to consumers, the received updates can be further propagated by the consumer to other servers, so a consumer can also act simultaneously as a provider. Also, a consumer does not have to be an LDAP server, it may be just an LDAP client. In OpenLDAP, you can use several replication modes, most notable are mirror and sync. For more information on OpenLDAP replication modes, see the OpenLDAP Software Administrator's Guide installed with openldap-servers package (see the section called “Installed Documentation”).
To enable a chosen replication mode, use one of the following directives in /etc/openldap/slapd.d/ on both provider and consumers.
olcMirrorMode
The olcMirrorMode directive enables the mirror replication mode. It takes the following form: 
olcMirrorMode on
This option needs to be specified both on provider and consumers. Also a serverID must be specified along with syncrepl options. Find a detailed example in the 18.3.4. MirrorMode section of the OpenLDAP Software Administrator's Guide (see the section called “Installed Documentation”).
olcSyncrepl
The olcSyncrepl directive enables the sync replication mode. It takes the following form: 
olcSyncrepl on
The sync replication mode requires a specific configuration on both the provider and the consumers. This configuration is thoroughly described in the 18.3.1. Syncrepl section of the OpenLDAP Software Administrator's Guide (see the section called “Installed Documentation”).

9.2.3.8. Loading Modules and Back ends

You can enhance the slapd service with dynamically loaded modules. Support for these modules must be enabled with the --enable-modules option when configuring slapd. Modules are stored in files with the .la extension: 
module_name.la
Back ends store or retrieve data in response to LDAP requests. Back ends may be compiled statically into slapd, or when module support is enabled, they may be dynamically loaded. In the latter case, the following naming convention is applied: 
back_backend_name.la
To load a module or a back end, use the following directive in /etc/openldap/slapd.d/:
olcModuleLoad
The olcModuleLoad directive specifies a dynamically loadable module to load. It takes the following form: 
olcModuleLoad: module
Here, module stands either for a file containing the module, or a back end, that will be loaded.

9.2.4. SELinux Policy for Applications Using LDAP

SELinux is an implementation of a mandatory access control mechanism in the Linux kernel. By default, SELinux prevents applications from accessing an OpenLDAP server. To enable authentication through LDAP, which is required by several applications, the allow_ypbind SELinux Boolean needs to be enabled. Certain applications also demand an enabled authlogin_nsswitch_use_ldap Boolean in this scenario. Execute the following commands to enable the aforementioned Booleans: 
~]# setsebool -P allow_ypbind=1
~]# setsebool -P authlogin_nsswitch_use_ldap=1
The -P option makes this setting persistent across system reboots. See the Red Hat Enterprise Linux 7 SELinux User's and Administrator's Guide for more detailed information about SELinux.

9.2.5. Running an OpenLDAP Server

This section describes how to start, stop, restart, and check the current status of the Standalone LDAP Daemon. For more information on how to manage system services in general, see Managing Services with systemd in the System Administrator's Guide.

9.2.5.1. Starting the Service

To start the slapd service in the current session, type the following at a shell prompt as root: 
~]# systemctl start slapd.service
To configure the service to start automatically at the boot time, use the following command as root: 
~]# systemctl enable slapd.service
ln -s '/usr/lib/systemd/system/slapd.service' '/etc/systemd/system/multi-user.target.wants/slapd.service'

9.2.5.2. Stopping the Service

To stop the running slapd service in the current session, type the following at a shell prompt as root: 
~]# systemctl stop slapd.service
To prevent the service from starting automatically at the boot time, type as root: 
~]# systemctl disable slapd.service
rm '/etc/systemd/system/multi-user.target.wants/slapd.service'

9.2.5.3. Restarting the Service

To restart the running slapd service, type the following at a shell prompt: 
~]# systemctl restart slapd.service
This stops the service and immediately starts it again. Use this command to reload the configuration.

9.2.5.4. Verifying the Service Status

To verify that the slapd service is running, type the following at a shell prompt: 
~]$ systemctl is-active slapd.service
active

9.2.6. Configuring a System to Authenticate Using OpenLDAP

In order to configure a system to authenticate using OpenLDAP, make sure that the appropriate packages are installed on both LDAP server and client machines. For information on how to set up the server, follow the instructions in Section 9.2.2, “Installing the OpenLDAP Suite” and Section 9.2.3, “Configuring an OpenLDAP Server”. On a client, type the following at a shell prompt: 
~]# yum install openldap openldap-clients nss-pam-ldapd

9.2.6.1. Migrating Old Authentication Information to LDAP Format

The migrationtools package provides a set of shell and Perl scripts to help you migrate authentication information into an LDAP format. To install this package, type the following at a shell prompt: 
~]# yum install migrationtools
This will install the scripts to the /usr/share/migrationtools/ directory. Once installed, edit the /usr/share/migrationtools/migrate_common.ph file and change the following lines to reflect the correct domain, for example: 
# Default DNS domain
$DEFAULT_MAIL_DOMAIN = "example.com";

# Default base
$DEFAULT_BASE = "dc=example,dc=com";
Alternatively, you can specify the environment variables directly on the command line. For example, to run the migrate_all_online.sh script with the default base set to dc=example,dc=com, type: 
~]# export DEFAULT_BASE="dc=example,dc=com" \
/usr/share/migrationtools/migrate_all_online.sh
To decide which script to run in order to migrate the user database, see Table 9.8, “Commonly used LDAP migration scripts”.
Table 9.8. Commonly used LDAP migration scripts
Existing Name Service Is LDAP Running? Script to Use
/etc flat files yes migrate_all_online.sh
/etc flat files no migrate_all_offline.sh
NetInfo yes migrate_all_netinfo_online.sh
NetInfo no migrate_all_netinfo_offline.sh
NIS (YP) yes migrate_all_nis_online.sh
NIS (YP) no migrate_all_nis_offline.sh
For more information on how to use these scripts, see the README and the migration-tools.txt files in the /usr/share/doc/migrationtools-version/ directory.

9.2.7. Additional Resources

The following resources offer additional information on the Lightweight Directory Access Protocol. Before configuring LDAP on your system, it is highly recommended that you review these resources, especially the OpenLDAP Software Administrator's Guide.

Installed Documentation

The following documentation is installed with the openldap-servers package:
  • /usr/share/doc/openldap-servers-version/guide.html — A copy of the OpenLDAP Software Administrator's Guide.
  • /usr/share/doc/openldap-servers-version/README.schema — A README file containing the description of installed schema files.
Additionally, there is also a number of manual pages that are installed with the openldap, openldap-servers, and openldap-clients packages:
Client Applications
  • ldapadd(1) — The manual page for the ldapadd command describes how to add entries to an LDAP directory.
  • ldapdelete(1) — The manual page for the ldapdelete command describes how to delete entries within an LDAP directory.
  • ldapmodify(1) — The manual page for the ldapmodify command describes how to modify entries within an LDAP directory.
  • ldapsearch(1) — The manual page for the ldapsearch command describes how to search for entries within an LDAP directory.
  • ldappasswd(1) — The manual page for the ldappasswd command describes how to set or change the password of an LDAP user.
  • ldapcompare(1) — Describes how to use the ldapcompare tool.
  • ldapwhoami(1) — Describes how to use the ldapwhoami tool.
  • ldapmodrdn(1) — Describes how to modify the RDNs of entries.
Server Applications
  • slapd(8C) — Describes command line options for the LDAP server.
Administrative Applications
  • slapadd(8C) — Describes command line options used to add entries to a slapd database.
  • slapcat(8C) — Describes command line options used to generate an LDIF file from a slapd database.
  • slapindex(8C) — Describes command line options used to regenerate an index based upon the contents of a slapd database.
  • slappasswd(8C) — Describes command line options used to generate user passwords for LDAP directories.
Configuration Files
  • ldap.conf(5) — The manual page for the ldap.conf file describes the format and options available within the configuration file for LDAP clients.
  • slapd-config(5) — Describes the format and options available within the /etc/openldap/slapd.d configuration directory.

Other Resources

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.