Automating User Authentication with Authconfig

Modern computer infrastructure tends to consist of many machines, with multiple services running on them. Keeping local user accounts in sync on all these machines and their services is a daunting task, even more so since passwords need to remain synced.

A solution to syncing multiple user accounts and passwords on a network of machines is not to store account information on local systems, but instead retrieve this information from a centralised store. Having user information and the associated authentication information centralised also allows for something called single sign on (SSO). With SSO, a user authenticates once using a password and then obtains a form of a ticket or cookie that can be used to automatically authenticate to other services.

User information and authentication

A centralised identity management system will need to provide at least two services.

Account information: This includes information such as user name, home directory location UID and GID, group memberships, etc. Popular solutions include LDAP (Lightweight Directory Access Protocol), which is used in multiple products such as Active Directory, IPA server and Network Information Services (NIS).

Authentication information: This is a way for a system to validate that users are who they claim to be. This can be done by providing a cryptographic password hash to the client system, or by sending the (encrypted) password to the server and receiving a response. An LDAP server can provide authentication information in addition to account information. Kerberos provides only SSO authentication services and is typically used alongside LDAP user information. Kerberos is used in both IPA server and Active Directory.

On a RHEL 7 system, local user information is provided by /etc/passwd while authentication information (in the form of a hashed password) is provided by /etc/shadow.

Attaching a system to centralised LDAP and Kerberos servers

Configuring a Red Hat Enterprise Linux 7 system to use centralised identity management services requires the editing of various files and the configuration of some daemons. For attaching to central LDAP and Kerberos server, the following files at least would need to be updated.

• /etc/ldap.conf: For information about the central LDAP server and its settings
• /etc/krb5.conf: For information about the central Kerberos infrastructure
• /etc/sssd/sssd.conf: To configure the system security services daemon (sssd), which is the daemon responsible for retrieving and caching user information and authentication information
• /etc/nsswitch.conf: To indicate to the system which user information and authentication services should be used
• /etc/pam.d/*: To configure how authentication should be handled for various services
• /etc/openldap/cacerts: To store the root certificate authorities (CA) that can validate the SSL certificates used to identify LDAP servers

The sssd daemon will need to be enabled and started before the system can use it. With so many files and services to configure, a mistake can easily be made. Red Hat Enterprise Linux 7 (RHEL 7) ships with a suite of tools to automate these configurations, called Authconfig, which consists of three related tools that can all perform the same actions.

• Authconfig: This is a command line tool that can be used to automate configurations across a number of systems. The commands used with Authconfig tend to be very long, with multiple options being passed in. This tool can be installed using the Authconfig package.
• Authconfig-tui: The interactive version of Authconfig uses a menu-driven text interface which can be used over SSH. This tool can be installed using the Authconfig package.
• Authconfig-gtk: This version launches a graphical interface. It can be launched as system-config-authentication. This tool is installed using the Authconfig-gtk package.

The necessary LDAP parameters

To connect to a central LDAP server for user information, Authconfig needs a number of settings:

• The host name of the LDAP server.
• The base DN (Distinguished Name) of the part of the LDAP tree where the system should look for users. This typically looks something like dc=example, dc=com. This information is known to LDAP server administrators.
• If SSL/TLS is used to encrypt communications with the LDAP server, a root CA certificate that can validate the certificate is offered by the LDAP server.

Note: A system will also need some extra packages installed to provide LDAP client functionality. Installing sssd will provide all the necessary dependencies.

The required Kerberos parameters

To configure a system to use a centralised Kerberos system for user authentication, Authconfig will need the following settings:

• The name of the Kerberos realm to use. A Kerberos realm is a domain of machines, all of which use a common set of Kerberos servers and users for authentication.
• One or more key distribution centres (KDC). This is the host name of your Kerberos server.
• The host name of one or more admin servers. This is the machine that clients will talk to when they want to change their password, or perform other user modifications. This is typically the same as the primary KDC, but it can be a different machine.

In addition, a systems administrator can specify if the DNS should be used to look up the realm to use for a specific host name and to automatically find the KDCs and admin servers. An extra package can be installed to help debug Kerberos issues and to work with Kerberos tickets from the command line:

krb5-workstation

Using Authconfig-gtk

To use Authconfig-gtk to configure a system for LDAP + Kerberos, follow the steps given below.

Install all the necessary packages as shown below:

# yum –y install authconfig-gtk sssd krb5-workstation

• Launch authconfig-gtk, either from the command line or from Applications > sundry > Authentication. Enter the root password when prompted.
• On the identity and authentication tab, select LDAP from the user account database drop-down menu. Fill in the LDAP search base DN and LDAP server fields.
• If the LDAP server supports TLS, check the ‘Use TLS to encrypt connections’ box and use the ‘Download CA Certificate’ button to download the CA certificate.
• From the ‘Authentication Method’ drop down menu, select the Kerberos password and fill out the realm, KDCs and admin server fields. The last two fields are not available if the ‘Use DNS to locate KDCs for Realms’ option is checked.
• If central home directories are not available, users can create directories on first logging in by checking the ‘Create home directories’ on the first login box on the ‘Advanced Options’ tab.
• Click the ‘Apply’ button to save and activate the changes. This will write all relevant configuration files and restart the sssd service.

Testing a configuration

To test the LDAP + Kerberos configuration, an administrator can attempt to log into the system (over SSH) using the credentials of one of the network users. In addition, the getent command:

getent password <USERNAME>

…can be used to retrieve information about a network user.

Important: In the default configuration, sssd will not enumerate the network users when no user name is specified to the getent command. This is done to keep the graphical login screen uncluttered to save valuable network resources and time.

Attaching a system to an IPA server

Red Hat provides an integrated solution for configuring LDAP and Kerberos – the IPA (identity, policy and auditing) Server. This provides LDAP and Kerberos, combined, with a suite of both command line and Web based administration tools. Apart from user and authentication information, IPA Server can centralise sudo rules, SSH public keys, SSH host keys, TLS certificates, automounter maps, and much more.

Using ipa-client

A RHEL 7 system can be configured to use IPA Server with the Authconfig suite of tools, but a specialised tool also exists: ipa-client-install. This command can be installed from the ipa-client package, which pulls in all dependencies (such as sssd).

One of the benefits of using ipa-client-install is that it can retrieve almost all necessary information from DNS (when configured either by IPA Server or manually by an administrator), as well as create host entries and more on the IPA Server. This allows an IPA Server administrator to set access policies for that host, create service principles (e.g., for NFSv4 exports), and more.

When ipa-client-install is run without any arguments, it will first attempt to retrieve information about the IPA Server configured for its DNS domains from the DNS. If that fails, it will prompt the administrator for necessary information, such as the domain name of IPA Server. Unless another account has been created for this, the default IPA Server administrator account (admin) can be used. Figure 3 gives an example of a driven configuration.

It is possible to specify all the required information as command line arguments, allowing for unattended setups as part of an initial system configuration, for example, from Kickstart.

Joining a system to Active Directory

RHEL 7 has many ways of joining a system to Active Directory. Administrators can choose to install the Samba-Winbind package and configure Winbind through the Authconfig family of tools, or the administrator can install both sssd and realmd packages and use sssd and realm commands.

Note 1: The realm command can also be used to join Kerberos realms or IPA Server domains, but the final configuration will be slightly different; for example, users will have @domain appended to their user names. Ipa-client-install is the preferred method to join IPA domains.

Note 2: Since there is no Active Directory server running in the classroom, there is no current possibility to practice these steps.

The following is an example of using realmd to join an Active Directory domain, and allow Active Directory users to log into the local system. This example assumes that the Active Directory domain is called domain.example.com.

• Install realmd as follows:

# yum –y install realmd

• Discover the settings for the domain.example.com domain by using the following command:

# sudo realm discover domain.example.com

• Join the Active Directory domain — this will install all necessary packages, and configure sssd, pam, /etc/nsswitch.conf, etc.

# sudo realm join domain.example.com

The above command will attempt to join the local system to Active Directory using the administrator account. So enter the password for this account when prompted. To use a different account, use the –user argument.

• The Active Directory account is now usable on the local system, but logins using Active Directory are still disabled. To enable logins, use the following command:

# sudo realm permit --realm domain.example.com –all

To only allow certain users to log in, replace –all with a list of those users. For example:

# sudo realm permit –realm domain.example.com DOMAIN\NAME1 DOMAIN\NAME2.

Note: By default, domain users must use their fully qualified names to log in — e.g., user@ipa.example.com for IPA users, or DOMAIN\Picard for Active Directory. To disable this, change the use_fully_qualified_names settings in the correct domain block in /etc/sssd/sssd.conf to False, or remove these entirely and then restart the sssd service.