此内容没有您所选择的语言版本。
Chapter 13. 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 user name 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, and external applications to verify user credentials. The Authentication Configuration Tool can configure SSSD along with NIS, Winbind, and LDAP, so that authentication processing and caching can be combined.
13.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 the configured authentication service. If the credentials match and the user account is active, then the user is authenticated. (Once a user is authenticated, then the information is passed to the access control service to determine what the user is permitted to do. Those are the resources the user is authorized to access.)
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, such as LDAP or Kerberos.
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 to authenticate users.
Important
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.
13.1.1. Launching the Authentication Configuration Tool UI
- Log into the system as root.
- Open the .
- Select the menu.
- Select the 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.
13.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 13.1. Local Authentication
13.1.2.1. Configuring LDAP Authentication
Either the openldap-clients package or the sssd package is used to configure an LDAP server for the user database. Both packages are installed by default.
- Open the Authentication Configuration Tool, as in Section 13.1.1, “Launching the Authentication Configuration Tool UI”.
- Select 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.This field is optional. If it is not specified, then the System Security Services Daemon (SSSD) attempts to detect the search base using the
namingContextsanddefaultNamingContextattributes in the LDAP server's configuration entry. - LDAP Server gives the URL of the LDAP server. This usually requires both the host name and port number of the LDAP server, such as ldap://ldap.example.com:389.Entering the secure protocol in the URL,
ldaps://, enables the button. - 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 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). This option uses Start TLS, which initiates a secure connection over a standard port; if a secure port is specified, then a protocol like SSL must be used instead of Start TLS.
- Select the authentication method. LDAP allows simple password authentication or Kerberos authentication.Using Kerberos is described in Section 13.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.
13.1.2.2. Configuring NIS Authentication
- Install the ypbind package. This is required for NIS services, but is not installed by default.
~]# yum install ypbind
When theypbindservice is installed, theportmapandypbindservices are started and enabled to start at boot time. - Open the Authentication Configuration Tool, as in Section 13.1.1, “Launching the Authentication Configuration Tool UI”.
- Select 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 host name. If the NIS server is not specified, the
authconfigdaemon scans for the NIS server. - Select the authentication method. NIS allows simple password authentication or Kerberos authentication.Using Kerberos is described in Section 13.1.2.4, “Using Kerberos with LDAP or NIS Authentication”.
For more information about NIS, see the "Securing NIS" section of the Security Guide.
13.1.2.3. Configuring Winbind Authentication
- Install the samba-winbind package. This is required for Windows integration features in Samba services, but is not installed by default.
~]# yum install samba-winbind
- Open the Authentication Configuration Tool, as in Section 13.1.1, “Launching the Authentication Configuration Tool UI”.
- Select in the User Account Database drop-down menu.
- Set the information that is required to connect to the Microsoft Active Directory domain controller.
- Winbind Domain gives the Windows domain to connect to.This should be in the Windows 2000 format, such as
DOMAIN. - Security Model sets the security model to use for Samba clients.
authconfigsupports four types of security models:- ads configures Samba to act as a domain member in an Active Directory Server realm. To operate in this mode, the krb5-server package must be installed and Kerberos must be configured properly. Also, when joining to the Active Directory Server using the command line, the following command must be used:
net ads join - domain has Samba validate the user name/password by authenticating it through a Windows primary or backup domain controller, much like a Windows server.
- server has a local Samba server validate the user name/password by authenticating it through another server, such as a Windows server. If the server authentication attempt fails, the system then attempts to authenticate using
usermode. - user requires a client to log in with a valid user name and password. This mode does support encrypted passwords.The user name format must be domain\user, such as
EXAMPLE\jsmith.Note
When verifying that a given user exists in the Windows domain, always use Windows 2000-style formats and escape the backslash (\) character. For example:~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
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, see Section 21.1.6.3, “Domain Controller”.
- Template Shell sets which login shell to use for Windows user account settings.
- Allow offline login allows authentication information to be stored in a local cache. The cache is referenced when a user attempts to authenticate to system resources while the system is offline.
For more information about the
Winbind service, see Section 21.1.2, “Samba Daemons and Related Services”.
For additional information about configuring
Winbind and troubleshooting tips, see the Knowledgebase on the Red Hat Customer Portal.
Also, the Red Hat Access Labs page includes the
Winbind Mapper utility that generates a part of the smb.conf file to help you connect a Red Hat Enterprise Linux to an Active Directory.
13.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 option from the Authentication Method drop-down menu automatically opens the fields required to connect to the Kerberos realm.
Figure 13.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 key distribution centers (KDC) and a potentially large number of clients.
- KDCs gives a comma-separated list of servers that issue Kerberos tickets.
- Admin Servers gives a list of administration servers running the
kadmindprocess in the realm. - Optionally, use DNS to resolve server host name and to find additional KDCs within the realm.
For more information about Kerberos, see section "Using Kerberos" of the Red Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards guide.
13.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. These alternative authentication options are configured in the Advanced Options tab.
Figure 13.3. Advanced Options
13.1.3.1. 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 in addition to other credentials.
13.1.3.2. 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.conffile to check for local user authorization rules. - Password Hashing Algorithm sets the hashing algorithm to use to encrypt locally-stored passwords.
13.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 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.
13.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.
This option is beneficial with accounts that are managed centrally, such as with LDAP. However, this option should not be selected if a system like automount is used to manage user home directories.
13.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.
13.1.4.1. Tips for Using authconfig
There are some things to remember when running
authconfig:
- With every command, use either the
--updateor--testoption. One of those options is required for the command to run successfully. Using--updatewrites the configuration changes.--testprints the changes to stdout but does not apply the changes to the configuration. - Each enable option has a corresponding disable option.
13.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 13.1.4.5, “Configuring Kerberos Authentication”.
13.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 13.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
13.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 host names.
authconfig --enablewinbind --enablewinbindauth --smbsecurity=user|server --enablewinbindoffline --smbservers=ad.example.com --smbworkgroup=EXAMPLE --update
Note
The user name format must be domain\user, such as
EXAMPLE\jsmith.
When verifying that a given user exists in the Windows domain, always use Windows 2000-style formats and escape the backslash (\) character. For example:
~]# getent passwd domain\\user DOMAIN\user:*:16777216:16777216:Name Surname:/home/DOMAIN/user:/bin/bash
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 user name, and UID ranges. These options are listed in the
authconfig help.
13.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
13.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
13.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
13.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 command instructs 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
Once smart card authentication has been successfully configured and tested, then the system can be configured to require smart card authentication for users rather than simple password-based authentication.
~]# authconfig --enablerequiresmartcard --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.
13.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:
--kickstartwrites the updated configuration to a kickstart file.--testprints 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 saved backups can be used to restore the configuration using the
--restorebackup option, giving the name of the manually-saved configuration:
~]# authconfig --restorebackup=2011-07-01
Additionally,
authconfig automatically makes a backup of the configuration before it applies any changes (with the --update option). The configuration can be restored from the most recent automatic backup, without having to specify the exact backup, using the --restorelastbackup option.
13.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
/homedirectory 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.solibrary, which the Authentication Configuration Tool uses to create home directories. Thepam_oddjob_mkhomedir.solibrary, unlike the defaultpam_mkhomedir.solibrary, can create SELinux labels.The Authentication Configuration Tool automatically uses thepam_oddjob_mkhomedir.solibrary if it is available. Otherwise, it will default to usingpam_mkhomedir.so. - Make sure the
oddjobdservice is running. - Re-run the Authentication Configuration Tool and enable home directories, as in Section 13.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
