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.
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.
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.
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.
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 [domain/default] 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 [sssd] services = nss, pam, autofs config_file_version = 2 domains = default [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp]
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.
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.
Tip
To find out which settings currently are used by the authentication process, use the authconfig --test command.