LDAP Authentication

Logging In Through an External Authentication Service

When a user enters his login name and password, these are normally checked on the local server. If in your environment many servers are used, this approach is not the most convenient, and you might benefit from a centralized service that helps you managing users and groups. To provide such centralized authentication services, LDAP is a common solution.

Understanding LDAP

The Lightweight Directory Access Protocol (LDAP) was developed as a protocol to get information from an X.500 directory service. This service was originally developed as an address book. Currently, LDAP has developed further into a service that can be used as a centralized authentication service.

In Figure 6.1, you can see a schematic overview of an LDAP directory. This is the imaginary LDAP environment that matches the DNS domain rhatcert.com. This LDAP environment spreads two geographic regions: SFO and AMS. Because it will not happen often that users in SFO are logging in or accessing resources in AMS, the directory tree is split in two parts, one for the SFO geographic and one for the AMS geographic. Every server in each geographic will know how to access information in the other partition; it will just be a bit slower because a remote server needs to be accessed.

To increase the accessibility, as well as fault tolerance, each geographic has two different servers. On each server, a replica of the partition is stored. This allows the workload to be load balanced across the servers, and it also allows for fault tolerance. When users are connecting to LDAP, they need to specify which specific server to access.

Figure 6.1 also shows that the users are in two specific containers in LDAP. When enabling LDAP access, users need to specify which container they are using as their base environment. This is referred to as the base context. The name of the base context is always written out as a name that includes the complete path (a fully distinguished name). This name includes type indicators and commas to separate the different parts. The two containers that contain users are therefore dc=sfo,dc=rhatcert,dc=com and dc=ams,dc=rhatcert,dc=com.

To access an LDAP server, security is important. To ensure a base level of security, Transport Layer Security (TLS) certificates are used. These certificates ensure that the server that LDAP users are authenticating against is verified, and that user credentials are secured while transported over the network.

To authenticate on an LDAP server, there are two options:

To pass the RHCSA exam, you need to be able to set up password-based LDAP authentication. Kerberos authentication is in the RHCE requirement.

Making the Authentication Platform Available

You do not have to know how to set up an LDAP server for the RHCSA test. You only need to know how to configure your server to authenticate on an already existing external LDAP server. If you want to test whether you can successfully authenticate on an external server, you need an LDAP server.

The easiest way to configure an LDAP authentication platform is by installing a Red Hat Identity Management server. In Appendix D, “Setting Up Identity Management,” you can read how to do that.

Also, a preconfigured server is available for download at http://rhatcert.com or this book’s website at http://pearsonitcertifiation.com.

Make sure to register. After registering, you have access to a completely configured environment that includes a FreeIPA server.

Make sure you read the information that is provided with the README.txt file that comes with the download or through the book’s webpage at pearsonitcertification.com.

Configuring RHEL 7 for LDAP Authentication

To set up RHEL7 for LDAP authentication, you need to create a configuration file that explains which LDAP server to use, which TLS certificate to use, and which container in LDAP should be used as the base LDAP URL. To specify all this, three different tools can be used:

 authconfig: A command-line utility in which you have to specify all you want to do by using command-line options

 authconfig-tui: A menu-driven text user interface that allows you to select options to be used from a list. Use of this utility is recommended

 authconfig-gtk: A utility with a GUI, which for that reason can be used from a GUI environment only

Depending on which tool you use, a different authentication backend is configured. The nslcd service is configured and started when using autconfig-tui. When authconfig-gtk is used, the sssd service is used as the backend.

Understanding sssd

After configuring authentication settings with authconfig-tui, the sssd service is used to establish contact with the LDAP server. This service uses the configuration file /etc/sssd/sssd.conf

Note that in some cases, the nslcd service is used behind the authentication process. However if you’re using the procedure that is described on Exercise 6.4, you’ll be dealing with sssd only and don’t have to worry about any other backend service.

[root@server1 sssd]# cat sssd.conf

autofs_provider = ldap
cache_credentials = True
krb5_realm = #
ldap_search_base = dc=example,dc=com
id_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://labipa.example.com/
ldap_id_use_start_tls = True
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_tls_reqcert = never
services = nss, pam, autofs
config_file_version = 2

domains = default
homedir_substring = /home







You can see the following relevant parameters:

When sssd is used, you should check whether the service is running by using systemctl status sssd. If it is, you can check the configuration in /etc/sss/sssd.conf. Normally, there should not be a need to modify the configuration in /etc/sssd/sssd conf directly, because it is written by authconfig-gtk—but for verification purposes you might want to take a look anyway. You find all LDAP-related configuration lines in this file.

Exercise: Connecting to an External LDAP Server

This exercise assumes that you have installed an LDAP server as offered by FreeIPA. Setup of this server is described in Appendix D. Alternatively, a complete lab environment is available for download at http://rhatcert.com or through this book’s website at http://pearsonitcertification.com. Make sure to register. The lab environment is available as a free download for registered users only. All tasks described here are performed on your test server:

To guarantee the success of this exercise, make sure to perform the steps that are described on a server that has been installed with the “Server with GUI” installation pattern. Your server1 should match this pattern.

  1. On server1, set up hostname resolution so that the LDAP server labipa.example.com can be reached by its name. In this exercise, the IP address is used for the LDAP server. Change this according to the setup you are using and enter the following line in the /etc/hosts file:
  2. Type yum groupinstall -y "Directory Client".
  3. As root, type authconfig-tui. In the text user interface that opens now, under User Information select Use LDAP, and under Authentication, select Use LDAP Authentication. Do not unselect any option that is selected by default.
  4. In the next screen, you are prompted as to whether TLS should be used;  Select Use TLS, and then enter the server URL ldap://labipa.example.com. Make sure the base DN is set to dc=example,dc=com. Then click OK to continue.
  5. You now see a message indicating that you need to copy the certificate of the CA that has signed the public key certificate of the LDAP server to /etc/openldap/cacerts. Open a root shell in a new terminal window and from this terminal, type scp labipa.example.com:/etc/ipa/ca.crt /etc/openldap/cacerts.
  6. Open the configuration file /etc/sssd/sssd.conf with an editor, and in the [domain/default] section, add the line ldap_tls_reqcert = never. Next, use systemctl restart sssd to restart the sssd service.
  7. Use su - ldapuser1 to verify that you now have access to users on the IPA server. On the IPA server, a user with the name lara has been created. You notice that you are logged in as this user, but you also get a warning that the home directory could not be set. For the moment, you can ignore that warning.


To find out which settings currently are used by the authentication process, use the authconfig --test command.