Chapter 10. Configuring Authentication

Authentication is the way that a user is identified and verified to a system. The authentication process requires presenting some sort of identity and credentials, like a username and password. The credentials are then compared to information stored in some data store on the system. In Red Hat Enterprise Linux, the Authentication Configuration Tool helps configure what kind of data store to use for user credentials, such as LDAP.

For convenience and potentially part of single sign-on, Red Hat Enterprise Linux can use a central daemon to store user credentials for a number of different data stores. The System Security Services Daemon (SSSD) can interact with LDAP, Kerberos, NIS, and PAM for authentication modules and can be accessed by external applications, like Red Hat Enterprise IPA, to check for user credentials. The Authentication Configuration Tool can be configured to work with SSSD, so that authentication processing and caching can be combined.

10.1. Configuring System Authentication

When a user logs into a Red Hat Enterprise Linux system, that user presents some sort of credential to establish the user identity. The system then checks those credentials against its stored information. If the credentials match and the user account is active, then the user is authenticated and can successfully access the server.

The information to verify the user can be located on the local system or the local system can reference a user database on a remote system.

The system must have a configured list of valid account databases for it to check for user authentication. On Red Hat Enterprise Linux, the Authentication Configuration Tool has both GUI and command-line options to configure any user data stores.

A local system can use a variety of different data stores for user information, including Lightweight Directory Access Protocol (LDAP), Network Information Service (NIS), and Winbind. Additionally, both LDAP and NIS data stores can use Kerberos authentication.

Note

If a medium or high security level is set during installation or with the Security Level Configuration Tool, then the firewall prevents NIS authentication. For more information about firewalls, see the "Firewalls" section of the Security Guide.

10.1.1. Launching the Authentication Configuration Tool UI

To open the Authentication Configuration Tool:

Open the System.
Select the Administration menu.
Select the Authentication item.

Alternatively, run the system-config-authentication command.

Important

Any changes take effect immediately when the Authentication Configuration Tool UI is closed.

There are two configuration tabs in the Authentication dialog box:

Identity & Authentication, which configures the resource used as the identity store (the data repository where the user IDs and corresponding credentials are stored)
Advanced Options, which allows authentication methods other than passwords or certificates, like smart cards and fingerprint.

10.1.2. Selecting the Identity Store for Authentication

The Identity & Authentication tab sets how users should be authenticated. The default is to use local system authentication, meaning the users and their passwords are checked against local system accounts. A Red Hat Enterprise Linux machine can also use external resources which contain the users and credentials, including LDAP, NIS, and Winbind.

Figure 10.1. Local Authentication

10.1.2.1. Configuring LDAP Authentication

The openldap-clients package must be installed in order to use an LDAP server for the user database.

Open the Authentication Configuration Tool, as in Section 10.1.1, “Launching the Authentication Configuration Tool UI”.
Select LDAP in the User Account Database drop-down menu.
Set the information that is required to connect to the LDAP server.
- LDAP Search Base DN gives the root suffix or distinguished name (DN) for the user directory. All of the user entries used for identity/authentication will exist below this parent entry. For example, ou=people,dc=example,dc=com.
- LDAP Server gives the URL of the LDAP server. This usually requires both the hostname and port number of the LDAP server, such as ldap://ldap.example.com:389.
- Use TLS to encrypt connections sets whether to use Start TLS to encrypt the connections to the LDAP server. This enables a secure connection over a standard port.
  Selecting TLS enables the Download CA Certificate button, which retrieves the issuing CA certificate for the LDAP server from whatever certificate authority issued it. The CA certificate must be in the privacy enhanced mail (PEM) format.
  Important
  Do not select Use TLS to encrypt connections if the server URL uses a secure protocol (ldaps).
Select the authentication method. LDAP allows simple password authentication or Kerberos authentication.
Using Kerberos is described in Section 10.1.2.4, “Using Kerberos with LDAP or NIS Authentication”.
The LDAP password option uses PAM applications to use LDAP authentication. This option requires either a secure (ldaps://) URL or the TLS option to connect to the LDAP server.

10.1.2.2. Configuring NIS Authentication

The ypbind package must be installed in order to use NIS authentication. When it is configured, the portmap and ypbind services are started and enabled to start at boot time.

Open the Authentication Configuration Tool, as in Section 10.1.1, “Launching the Authentication Configuration Tool UI”.
Select NIS in the User Account Database drop-down menu.
Set the information to connect to the NIS server, meaning the NIS domain name and the server hostname. If the NIS server is not specified, the authconfig daemon scans for the NIS server.
Select the authentication method. NIS allows simple password authentication or Kerberos authentication.
Using Kerberos is described in Section 10.1.2.4, “Using Kerberos with LDAP or NIS Authentication”.

For more information about NIS, see the "Securing NIS" section of the Security Guide.

10.1.2.3. Configuring Winbind Authentication

Open the Authentication Configuration Tool, as in Section 10.1.1, “Launching the Authentication Configuration Tool UI”.
Select Winbind in the User Account Database drop-down menu.
Set the information that is required to connect to the Microsoft Active Directory or Windows NT domain controller.
- Winbind Domain gives the Windows domain to connect to.
- Security Model sets the security model to use for Samba clients. authconfig supports four types of security models:
  ads configures Samba to act as a domain member in an Active Directory Server (ADS) realm. To operate in this mode, the krb5-server package must be installed and Kerberos must be configured properly.
  domain has Samba validate the username/password by authenticating it through a Windows NT primary or backup domain controller, much like a Windows NT server.
  server has a local Samba server validate the username/password by authenticating it through another server, such as a Windows NT server). If the server authentication attempt fails, the system then attempts to authentication using user mode.
  user requires a client to log in with a valid username and password. This mode does support encrypted passwords.
  This is the default option.
- Winbind ADS Realm gives the Active Directory realm that the Samba server will join. This is only used with the ads security model.
- Winbind Domain Controllers gives the domain controller to use. For more information about domain controllers, please refer to Section 17.1.6.3, “Domain Controller”.
- Template Shell sets which login shell to use for Windows NT user account settings.
- Allow offline login allows authentication information to be stored in a local cache provided by SSSD. The cache is referenced when a user attempts to authenticate to system resources while the system is offline. SSSD is described in Section 10.2, “Using and Caching Credentials with SSSD”.

For more information about the winbindd service, refer to Section 17.1.2, “Samba Daemons and Related Services”.

10.1.2.4. Using Kerberos with LDAP or NIS Authentication

Both LDAP and NIS authentication stores support Kerberos authentication methods. Using Kerberos has a couple of benefits:

It uses a security layer for communication while still allowing connections over standard ports.
It automatically uses credentials caching with SSSD, which allows offline logins.

Using Kerberos authentication requires the krb5-libs and krb5-workstation packages.

The Kerberos authentication selection automatically opens the fields required to connect to the Kerberos realm.

Figure 10.2. Kerberos Fields

Realm gives the name for the realm for the Kerberos server. The realm is the network that uses Kerberos, composed of one or more KDCs and a potentially large number of clients.
KDCs gives a comma-separated list of servers that issue Kerberos tickets (key distribution center or KDC).
Admin Servers gives a list of administration servers running the kadmind process in the realm.
Optionally, use DNS to resolve server hostname and to find additional KDCs within the realm.

For more information about Kerberos, refer to section "Using Kerberos" of the Red Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards guide.

10.1.3. Configuring Alternative Authentication Features

The Authentication Configuration Tool also configures settings related to authentication behavior, apart from the identity store. This includes entirely different authentication methods (fingerprint scans and smart cards) or local authentication rules.

Figure 10.3. Advanced Options

10.1.3.1. Setting Local Authentication Parameters

There are two options in the Local Authentication Options area which define authentication behavior on the local system:

Enable local access control instructs the /etc/security/access.conf file to check for local user authorization rules.
Password Hashing Algorithm sets the hashing algorithm to use to encrypt locally-stored passwords.

10.1.3.2. Using Fingerprint Authentication

When there is appropriate hardware available, the Enable fingerprint reader support option allows fingerprint scans to be used to authenticate local users rather than other credentials.

10.1.3.3. Enabling Smart Card Authentication

When there are appropriate smart card readers available, a system can accept smart cards (or tokens) instead of other user credentials to authenticate.

Once the Enable smart card support option is selected, then the behaviors of smart card authentication can be defined:

Card Removal Action tells the system how to respond when the card is removed from the card reader during an active session. A system can either ignore the removal and allow the user to access resources as normal, or a system can immediately lock until the smart card is supplied.
Require smart card login sets whether a smart card is required for logins or simply allowed for logins. When this option is selected, all other methods of authentication are immediately blocked.
Warning
Do not select this option until you have successfully authenticated to the system using a smart card.

Using smart cards requires the pam_pkcs11 package. For more information about smart cards, see the Managing Single Sign-On and Smart Cards Guide.

10.1.3.4. Creating User Home Directories

There is an option (Create home directories on the first login) to create a home directory automatically the first time that a user logs in.

10.1.4. Configuring Authentication from the Command Line

The authconfig command-line tool updates all of the configuration files and services required for system authentication, according to the settings passed to the script. Along with allowing all of the identity and authentication configuration options that can be set through the UI, the authconfig tool can also be used to create backup and kickstart files.

For a complete list of authconfig options, check the help output and the man page.

10.1.4.1. Tips for Using authconfig

There are some things to remember when running authconfig:

With every command, use either the --update or --test option. One of those options is required for the command to run successfully. Using --update writes the configuration changes. --test prints the changes to stdout but does not apply the changes to the configuration.
Each enable option has a corresponding disable option.

10.1.4.2. Configuring LDAP User Stores

To use an LDAP identity store, use the --enableldap. To use LDAP as the authentication source, use --enableldapauth and then the requisite connection information, like the LDAP server name, base DN for the user suffix, and (optionally) whether to use TLS. The authconfig command also has options to enable or disable RFC 2307bis schema for user entries, which is not possible through the Authentication Configuration UI.

Be sure to use the full LDAP URL, including the protocol (ldap or ldaps) and the port number. Do not use a secure LDAP URL (ldaps) with the --enableldaptls option.

authconfig --enableldap --enableldapauth --ldapserver=ldap://ldap.example.com:389,ldap://ldap2.example.com:389 --ldapbasedn="ou=people,dc=example,dc=com" --enableldaptls --ldaploadcacert=https://ca.server.example.com/caCert.crt --update

Instead of using --ldapauth for LDAP password authentication, it is possible to use Kerberos with the LDAP user store. These options are described in Section 10.1.4.5, “Configuring Kerberos Authentication”.

10.1.4.3. Configuring NIS User Stores

To use a NIS identity store, use the --enablenis. This automatically uses NIS authentication, unless the Kerberos parameters are explicitly set, so it uses Kerberos authentication (Section 10.1.4.5, “Configuring Kerberos Authentication”). The only parameters are to identify the NIS server and NIS domain; if these are not used, then the authconfig service scans the network for NIS servers.

authconfig --enablenis --nisdomain EXAMPLE --nisserver nis.example.com --update

10.1.4.4. Configuring Winbind User Stores

Windows domains have several different security models, and the security model used in the domain determines the authentication configuration for the local system.

For user and server security models, the Winbind configuration requires only the domain (or workgroup) name and the domain controller hostnames.

authconfig --enablewinbind --enablewinbindauth --smbsecurity user|server  --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --update

For ads and domain security models, the Winbind configuration allows additional configuration for the template shell and realm (ads only). For example:

authconfig --enablewinbind --enablewinbindauth --smbsecurity ads  --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --smbrealm EXAMPLE.COM --winbindtemplateshell=/bin/sh --update

There are a lot of other options for configuring Windows-based authentication and the information for Windows user accounts, such as name formats, whether to require the domain name with the username, and UID ranges. These options are listed in the authconfig help.

10.1.4.5. Configuring Kerberos Authentication

Both LDAP and NIS allow Kerberos authentication to be used in place of their native authentication mechanisms. At a minimum, using Kerberos authentication requires specifying the realm, the KDC, and the administrative server. There are also options to use DNS to resolve client names and to find additional admin servers.

authconfig NIS or LDAP options --enablekrb5 --krb5realm EXAMPLE --krb5kdc kdc.example.com:88,server.example.com:88 --krb5adminserver server.example.com:749 --enablekrb5kdcdns --enablekrb5realmdns --update

10.1.4.6. Configuring Local Authentication Settings

The Authentication Configuration Tool can also control some user settings that relate to security, such as creating home directories, setting password hash algorithms, and authorization. These settings are done independently of identity/user store settings.

For example, to create user home directories:

authconfig --enablemkhomedir --update

To set or change the hash algorithm used to encrypt user passwords:

authconfig --passalgo=sha512 --update

10.1.4.7. Configuring Fingerprint Authentication

There is one option to enable support for fingerprint readers. This option can be used alone or in conjunction with other authconfig settings, like LDAP user stores.

authconfig --enablefingerprint --update

10.1.4.8. Configuring Smart Card Authentication

All that is required to use smart cards with a system is to set the --enablesmartcard option:

authconfig --enablesmartcard --update

There are other configuration options for smart cards, such as changing the default smart card module, setting the behavior of the system when the smart card is removed, and requiring smart cards for login. For example, this tells the system to lock out a user immediately if the smart card is removed (a setting of 1 ignores it if the smart card is removed):

authconfig --enablesmartcard --smartcardaction=0 --update

Warning

Do not use the --enablerequiresmartcard option until you have successfully authenticated to the system using a smart card. Otherwise, users may be unable to log into the system.

10.1.4.9. Managing Kickstart and Configuration Files

The --update option updates all of the configuration files with the configuration changes. There are a couple of alternative options with slightly different behavior:

--kickstart writes the updated configuration to a kickstart file.
--test prints the full configuration, with changes, to stdout but does not edit any configuration files.

Additionally, authconfig can be used to back up and restore previous configurations. All archives are saved to a unique subdirectory in the /var/lib/authconfig/ directory. For example, the --savebackup option gives the backup directory as 2011-07-01:

authconfig --savebackup=2011-07-01

This backs up all of the authentication configuration files beneath the /var/lib/authconfig/backup-2011-07-01 directory.

Any of the backups can be used to restore the configuration using the --restorebackup option. authconfig automatically makes a backup of the configuration before it applies any changes (with the --update option). The configuration can be restored from that automatic backup using the --restorelastbackup option.

10.1.5. Using Custom Home Directories

If LDAP users have home directories that are not in /home and the system is configured to create home directories the first time users log in, then these directories are created with the wrong permissions.

Apply the correct SELinux context and permissions from the /home directory to the home directory that is created on the local system. For example:
```
# semanage fcontext -a -e /home /home/locale
```
Install the oddjob-mkhomedir package on the system.
This package provides the pam_oddjob_mkhomedir.so library, which the Authentication Configuration Tool uses to create home directories. The pam_oddjob_mkhomedir.so library, unlike the default pam_mkhomedir.so library, can create SELinux labels.
The Authentication Configuration Tool automatically uses the pam_oddjob_mkhomedir.so library if it is available. Otherwise, it will default to using pam_mkhomedir.so.
Make sure the oddjobd service is running.
Re-run the Authentication Configuration Tool and enable home directories, as in Section 10.1.3, “Configuring Alternative Authentication Features”.

If home directories were created before the home directory configuration was changed, then correct the permissions and SELinux contexts. For example:

# semanage fcontext -a -e /home /home/locale
# restorecon -R -v /home/locale