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 Fedora, 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.
7.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 Fedora machine can also use external resources which contain the users and credentials, including LDAP, NIS, and Winbind.
7.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.
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 SSSD attempts to detect the search base using the namingContexts
and defaultNamingContext
attributes in the LDAP server's configuration entry.
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.
Entering the secure protocol in the URL, ldaps://
, enables the Download CA Certificate 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 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.
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.
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.
7.1.2.2. Configuring NIS Authentication
Install the ypbind
package. This is required for NIS services, but is not installed by default.
[root@server ~]# yum install ypbind
When the ypbind
service is installed, the portmap
and ypbind
services are started and enabled to start at boot time.
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 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.
For more information about NIS, see the "Securing NIS" section of the Security Guide.
7.1.2.3. Configuring Winbind Authentication
Using Winbind as an authentication provider requires the samba-winbind
package, which is installed by default.
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.
authconfig
supports 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.
domain has Samba validate the username/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 username/password by authenticating it through another server, such as a Windows 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.
The username 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:
[root@server ~]# 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.
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.
7.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.
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 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 Fedora 20 Managing Single Sign-On and Smart Cards guide.
7.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.
7.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.
7.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.conf
file to check for local user authorization rules.
Password Hashing Algorithm sets the hashing algorithm to use to encrypt locally-stored passwords.
7.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.
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.
7.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.
7.1.4. Setting Password Options
Through the Authentication Configuration Tool, it is possible to set requirements of passwords and the classes of characters it will contain. Also, it can determine how consecutive characteres will be repeated within a password. This options are configured in the Password Options tab.
The Lenght option allows a maximun of 30 characters and the Character Classes option allows to choose from one to four according the classes: Lowercase, Uppercase, Digits and Other characters which are going to be required to create a password if they are enabled.
An adecuated election to the lenght of password must be done correspondinly to the classes chossen. For example, the password FeDOrAwOrld which has two character classes contains eleven characters and The password FeD2rA1 contains seven characteres but has three character classes.
The maximun amount of consecutive character repetition is set to characters and classes. Both, the Same Character option and the Same Class option have the lenght of 30 as character repetition allowed.
7.1.5. 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.
7.1.5.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.
7.1.5.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
7.1.5.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 7.1.5.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
7.1.5.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
The username 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:
[root@server ~]# 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 username, and UID ranges. These options are listed in the authconfig
help.
7.1.5.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
7.1.5.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
7.1.5.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
7.1.5.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
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.
7.1.5.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 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.