| Deployment GuideChapter 11. Configuring AuthenticationAuthentication 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, 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. 11.1. Configuring System AuthenticationWhen 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. 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. 11.1.1. Launching the Authentication Configuration Tool UILog into the system as root. Open the . Select the menu. Select the item.
Alternatively, run the system-config-authentication command. 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.
11.1.2. Selecting the Identity Store for AuthenticationThe 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. 11.1.2.1. Configuring LDAP AuthenticationEither 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 the System Security Services Daemon (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. 11.1.2.2. Configuring NIS AuthenticationInstall 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. 11.1.2.3. Configuring Winbind AuthenticationInstall the samba-winbind package. This is required for Windows integration features in Samba services, but is not installed by default. [root@server ~]# yum install samba-winbind 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.
11.1.2.4. Using Kerberos with LDAP or NIS AuthenticationBoth 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 Red Hat Enterprise Linux 6 Managing Single Sign-On and Smart Cards guide. 11.1.3. Configuring Alternative Authentication FeaturesThe 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. 11.1.3.1. Using Fingerprint AuthenticationWhen 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. 11.1.3.2. Setting Local Authentication ParametersThere 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.
11.1.3.3. Enabling Smart Card AuthenticationWhen 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. 11.1.3.4. Creating User Home DirectoriesThere 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. 11.1.4. Configuring Authentication from the Command LineThe 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. 11.1.4.1. Tips for Using authconfigThere 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.
11.1.4.2. Configuring LDAP User StoresTo 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 11.1.4.3. Configuring NIS User StoresTo 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 11.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 11.1.4.4. Configuring Winbind User StoresWindows 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. 11.1.4.5. Configuring Kerberos AuthenticationBoth 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 11.1.4.6. Configuring Local Authentication SettingsThe 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 11.1.4.7. Configuring Fingerprint AuthenticationThere 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. [root@server ~]# authconfig --enablefingerprint --update 11.1.4.8. Configuring Smart Card AuthenticationAll that is required to use smart cards with a system is to set the --enablesmartcard option: [root@server ~]# 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): [root@server ~]# 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. [root@server ~]# 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. 11.1.4.9. Managing Kickstart and Configuration FilesThe --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: [root@server ~]# 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: [root@server ~]# 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. 11.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: [root@server ~]# 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.
If home directories were created before the home directory configuration was changed, then correct the permissions and SELinux contexts. For example: [root@server ~]# semanage fcontext -a -e /home /home/locale# restorecon -R -v /home/locale 11.2. Using and Caching Credentials with SSSDThe System Security Services Daemon (SSSD) provides access to different identity and authentication providers. Most system authentication is configured locally, which means that services must check with a local user store to determine users and credentials. What SSSD does is allow a local service to check with a local cache in SSSD, but that cache may be taken from any variety of remote identity providers - an LDAP directory, an Identity Management domain, Active Directory, possibly even a Kerberos realm. SSSD also caches those users and credentials, so if the local system or the identity provider go offline, the user credentials are still available to services to verify. SSSD is an intermediary between local clients and any configured data store. This relationship brings a number of benefits for administrators: Reducing the load on identification/authentication servers. Rather than having every client service attempt to contact the identification server directly, all of the local clients can contact SSSD which can connect to the identification server or check its cache. Permitting offline authentication. SSSD can optionally keep a cache of user identities and credentials that it retrieves from remote services. This allows users to authenticate to resources successfully, even if the remote identification server is offline or the local machine is offline. Using a single user account. Remote users frequently have two (or even more) user accounts, such as one for their local system and one for the organizational system. This is necessary to connect to a virtual private network (VPN). Because SSSD supports caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine and then SSSD maintains their network credentials.
Additional Resources While this chapter covers the basics of configuring services and domains in SSSD, this is not a comprehensive resource. Many other configuration options are available for each functional area in SSSD; check out the man page for the specific functional area to get a complete list of options. Table 11.1. A Sampling of SSSD Man Pages | Functional Area | Man Page |
|---|
| General Configuration | sssd.conf(8) | | sudo Services | sssd-sudo | | LDAP Domains | sssd-ldap | | Active Directory Domains | | | Identity Management (IdM or IPA) Domains | | | Kerberos Authentication for Domains | sssd-krb5 | | OpenSSH Keys | | sss_ssh_authorizedkeys | | sss_ssh_knownhostsproxy |
| | Cache Maintenance | | sss_cache (cleanup) | | sss_useradd, sss_usermod, sss_userdel, sss_seed (user cache entry management) |
|
11.2.2. Setting up the sssd.conf FileSSSD services and domains are configured in a .conf file. By default, this is /etc/sssd/sssd.conf - although that file must be created and configured manually, since SSSD is not configured after installation. 11.2.2.1. Creating the sssd.conf FileThere are three parts of the SSSD configuration file: [sssd], for general SSSD process and operational configuration; this basically lists the configured services, domains, and configuration parameters for each
[domain_type/DOMAIN_NAME], for configuration options for each configured identity provider While services are optional, at least one identity provider domain must be configured before the SSSD service can be started.
Example 11.1. Simple sssd.conf File [sssd]domains = LOCALservices = nssconfig_file_version = 2[nss]filter_groups = rootfilter_users = root[domain/LOCAL]id_provider = localauth_provider = localaccess_provider = permit The [sssd] section has three important parameters: domains lists all of the domains, configured in the sssd.conf, which SSSD uses as identity providers. If a domain is not listed in the domains key, it is not used by SSSD, even if it has a configuration section.
services lists all of the system services, configured in the sssd.conf, which use SSSD; when SSSD starts, the corresponding SSSD service is started for each configured system service. If a service is not listed in the services key, it is not used by SSSD, even if it has a configuration section.
config_file_version sets the version of the configuration file to set file format expectations. This is version 2, for all recent SSSD versions.
Even if a service or domain is configured in the sssd.conf file, SSSD does not interact with that service or domain unless it is listed in the services or domains parameters, respectively, in the [sssd] section. Other configuration parameters are listed in the sssd.conf man page. Each service and domain parameter is described in its respective configuration section in this chapter and in their man pages. 11.2.2.2. Using a Custom Configuration FileBy default, the sssd process assumes that the configuration file is /etc/sssd/sssd.conf. An alternative file can be passed to SSSD by using the -c option with the sssd command: [root@server ~]# sssd -c /etc/sssd/customfile.conf --daemon 11.2.3. Starting and Stopping SSSDEither the service command or the /etc/init.d/sssd script can start SSSD. For example: [root@server ~]# service sssd start By default, SSSD is not configured to start automatically. There are two ways to change this behavior: Enabling SSSD through the authconfig command: [root@server ~]# authconfig --enablesssd --enablesssdauth --update Adding the SSSD process to the start list using the chkconfig command: [root@server ~]# chkconfig sssd on
11.2.4. SSSD and System ServicesSSSD and its associated services are configured in the sssd.conf file. The [sssd] section also lists the services that are active and should be started when sssd starts within the services directive. SSSD can provide credentials caches for several system services: A Name Service Switch (NSS) provider service that answers name service requests from the sssd_nss module. This is configured in the [nss] section of the SSSD configuration. A PAM provider service that manages a PAM conversation through the sssd_pam module. This is configured in the [pam] section of the configuration. An autofs provider service that connects to an LDAP server to retrieve configured mount locations. This is configured as part of an LDAP identity provider in a [domain/NAME] section in the configuration file. A sudo provider service that connects to an LDAP server to retrieve configured sudo policies. This is configured as part of an LDAP identity provider in a [domain/NAME] section in the configuration file. A PAC responder service that defines how SSSD works with Kerberos to manage Active Directory users and groups. This is specifically part of managing Active Directory identity providers with domains, as described in Section 11.2.13, "Creating Domains: Active Directory".
11.2.5. Configuring Services: NSSSSSD provides an NSS module, sssd_nss, which instructs the system to use SSSD to retrieve user information. The NSS configuration must include a reference to the SSSD module, and then the SSSD configuration sets how SSSD interacts with NSS. 11.2.5.1. About NSS Service Maps and SSSDThe Name Service Switch (NSS) provides a central configuration for services to look up a number of configuration and name resolution services. NSS provides one method of mapping system identities and services with configuration sources. SSSD works with NSS as a provider services for several types of NSS maps: Passwords (passwd) User groups (shadow) Groups (groups) Netgroups (netgroups) Services (services)
11.2.5.2. Configuring NSS Services to Use SSSDNSS can use multiple identity and configuration providers for any and all of its service maps. The default is to use system files for services; for SSSD to be included, the nss_sss module has to be included for the desired service type. Use the Authentication Configuration tool to enable SSSD. This automatically configured the nsswitch.conf file to use SSSD as a provider. [root@server ~]# authconfig --enablesssd --update This automatically configures the password, shadow, group, and netgroups services maps to use the SSSD module: passwd: files sssshadow: files sssgroup: files sssnetgroup: files sss The services map is not enabled by default when SSSD is enabled with authconfig. To include that map, open the nsswitch.conf file and add the sss module to the services map: [root@server ~]# vim /etc/nsswitch.conf...services: file sss...
11.2.5.3. Configuring SSSD to Work with NSSThe options and configuration that SSSD uses to service NSS requests are configured in the SSSD configuration file, in the [nss] services section. Open the sssd.conf file. [root@server ~]# vim /etc/sssd/sssd.conf Make sure that NSS is listed as one of the services that works with SSSD. [sssd]config_file_version = 2reconnection_retries = 3sbus_timeout = 30services = nss, pam [nss]filter_groups = rootfilter_users = rootreconnection_retries = 3entry_cache_timeout = 300entry_cache_nowait_percentage = 75 Restart SSSD. [root@server ~]# service sssd restart
Table 11.2. SSSD [nss] Configuration Parameters | Parameter | Value Format | Description |
|---|
| enum_cache_timeout | integer | Specifies how long, in seconds, sssd_nss should cache requests for information about all users (enumerations). | | entry_cache_nowait_percentage | integer | Specifies how long sssd_nss should return cached entries before refreshing the cache. Setting this to zero (0) disables the entry cache refresh. This configures the entry cache to update entries in the background automatically if they are requested if the time before the next update is a certain percentage of the next interval. For example, if the interval is 300 seconds and the cache percentage is 75, then the entry cache will begin refreshing when a request comes in at 225 seconds - 75% of the interval. The allowed values for this option are 0 to 99, which sets the percentage based on the entry_cache_timeout value. The default value is 50%. | | entry_negative_timeout | integer | Specifies how long, in seconds, sssd_nss should cache negative cache hits. A negative cache hit is a query for an invalid database entries, including non-existent entries. | | filter_users, filter_groups | string | Tells SSSD to exclude certain users from being fetched from the NSS database. This is particularly useful for system accounts such as root. | | filter_users_in_groups | Boolean | Sets whether users listed in the filter_users list appear in group memberships when performing group lookups. If set to FALSE, group lookups return all users that are members of that group. If not specified, this value defaults to true, which filters the group member lists. | | debug_level | integer, 0 - 9 | Sets a debug logging level. |
11.2.6. Configuring Services: PAMA mistake in the PAM configuration file can lock users out of the system completely. Always back up the configuration files before performing any changes, and keep a session open so that any changes can be reverted. SSSD provides a PAM module, sssd_pam, which instructs the system to use SSSD to retrieve user information. The PAM configuration must include a reference to the SSSD module, and then the SSSD configuration sets how SSSD interacts with PAM. To configure the PAM service: Use authconfig to enable SSSD for system authentication. # authconfig --update --enablesssd --enablesssdauth This automatically updates the PAM configuration to reference all of the SSSD modules: #%PAM-1.0# This file is auto-generated.# User changes will be destroyed the next time authconfig is run.auth required pam_env.soauth sufficient pam_unix.so nullok try_first_passauth requisite pam_succeed_if.so uid >= 500 quietauth sufficient pam_sss.so use_first_passauth required pam_deny.soaccount required pam_unix.so account sufficient pam_localuser.soaccount sufficient pam_succeed_if.so uid < 500 quietaccount [default=bad success=ok user_unknown=ignore] pam_sss.soaccount required pam_permit.sopassword requisite pam_cracklib.so try_first_pass retry=3password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtokpassword sufficient pam_sss.so use_authtokpassword required pam_deny.sosession optional pam_keyinit.so revokesession required pam_limits.sosession [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uidsession sufficient pam_sss.sosession required pam_unix.so These modules can be set to include statements, as necessary. Open the sssd.conf file. # vim /etc/sssd/sssd.conf Make sure that PAM is listed as one of the services that works with SSSD. [sssd]config_file_version = 2reconnection_retries = 3sbus_timeout = 30services = nss, pam [pam]reconnection_retries = 3offline_credentials_expiration = 2offline_failed_login_attempts = 3offline_failed_login_delay = 5 Restart SSSD. [root@server ~]# service sssd restart
Table 11.3. SSSD [pam] Configuration Parameters | Parameter | Value Format | Description |
|---|
| offline_credentials_expiration | integer | Sets how long, in days, to allow cached logins if the authentication provider is offline. This value is measured from the last successful online login. If not specified, this defaults to zero (0), which is unlimited. | | offline_failed_login_attempts | integer | Sets how many failed login attempts are allowed if the authentication provider is offline. If not specified, this defaults to zero (0), which is unlimited. | | offline_failed_login_delay | integer | Sets how long to prevent login attempts if a user hits the failed login attempt limit. If set to zero (0), the user cannot authenticate while the provider is offline once he hits the failed attempt limit. Only a successful online authentication can re-enable offline authentication. If not specified, this defaults to five (5). |
11.2.7. Configuring Services: autofs11.2.7.1. About Automount, LDAP, and SSSDAutomount maps are commonly flat files, which define a relationship between a map, a mount directory, and a fileserver. (Automount is described in the Storage Administration Guide.) For example, let's say that there is a fileserver called nfs.example.com which hosts the directory pub, and automount is configured to mount directories in the /shares/ directory. So, the mount location is /shares/pub. All of the mounts are listed in the auto.master file, which identifies the different mount directories and the files which configure them. The auto.shares file then identifies each file server and mount directory which goes into the /shares/ directory. The relationships could be viewed like this: auto.master _________|__________ | | | |/shares/ auto.shares | | | nfs.example.com:pub Every mount point, then, is defined in two different files (at a minimum): the auto.master and auto.whatever file, and those files have to be available to each local automount process. One way for administrators to manage that for large environments is to store the automount configuration in a central LDAP directory, and just configure each local system to point to that LDAP directory. That means that updates only need to be made in a single location, and any new maps are automatically recognized by local systems. For automount-LDAP configuration, the automount files are stored as LDAP entries, which are then translated into the requisite automount files. Each element is then translated into an LDAP attribute. The LDAP entries look like this: # container entrydn: cn=automount,dc=example,dc=comobjectClass: nsContainerobjectClass: topcn: automount# master map entrydn: automountMapName=auto.master,cn=automount,dc=example,dc=comobjectClass: automountMapobjectClass: topautomountMapName: auto.master# shares map entrydn: automountMapName=auto.shares,cn=automount,dc=example,dc=comobjectClass: automountMapobjectClass: topautomountMapName: auto.shares# shares mount pointdn: automountKey=/shares,automountMapName=auto.master,cn=automount,dc=example,dc=comobjectClass: automountobjectClass: topautomountKey: /sharesautomountInformation: auto.shares# pub mount pointdn: automountKey=pub,automountMapName=auto.shares,cn=automount,dc=example,dc=comobjectClass: automountobjectClass: topautomountKey: pubautomountInformation: filer.example.com:/pubdescription: pub The schema elements, then, match up to the structure like this (with the RFC 2307 schema): auto.master objectclass: automountMap filename attribute: automountMapName _______________________|_________________________ | | | |/shares/ auto.sharesobjectclass: automount objectclass: automountMapmount point name attribute: automountKey filename attribute: automountMapNamemap name attribute: automountInformation | | | nfs.example.com:pub objectclass: automount mount point name attribute: automountKey fileserver attribute: automountInformation autofs uses those schema elements to derive the automount configuration. The /etc/sysconfig/autofs file identifies the LDAP server, directory location, and schema elements used for automount entities:
LDAP_URI=ldap://ldap.example.comSEARCH_BASE="cn=automount,dc=example,dc=com"MAP_OBJECT_CLASS="automountMap"ENTRY_OBJECT_CLASS="automount"MAP_ATTRIBUTE="automountMapName"ENTRY_ATTRIBUTE="automountKey"VALUE_ATTRIBUTE="automountInformation" Rather than pointing the automount configuration to the LDAP directory, it cna be configured to point to SSSD. SSSD, then, stores all of the information that automount needs, and as a user attempts to mount a directory, that information is cached into SSSD. This offers several advantages for configuration - such as failover, service discovery, and timeouts - as well as performance improvements by reducing the number of connections to the LDAP server. Most important, using SSSD allows all mount information to be cached, so that clients can still successfully mount directories even if the LDAP server goes offline. 11.2.7.2. Configuring autofs Services in SSSDMake sure that the autofs and libsss_autofs packages are installed. Open the sssd.conf file. [root@server ~]# vim /etc/sssd/sssd.conf Add the autofs service to the list of services that SSSD manages. [sssd]services = nss,pam,autofs.... Create a new [autofs] service configuration section. This section can be left blank; there is only one configurable option, for timeouts for negative cache hits. This section is required, however, for SSSD to recognize the autofs service and supply the default configuration. [autofs] The automount information is read from a configured LDAP domain in the SSSD configuration, so an LDAP domain must be available. If no additional settings are made, then the configuration defaults to the RFC 2307 schema and the LDAP search base (ldap_search_base) for the automount information. This can be customized: The directory type, autofs_provider; this defaults to the id_provider value; a value of none explicitly disables autofs for the domain. The search base, ldap_autofs_search_base. The object class to use to recognize map entries, ldap_autofs_map_object_class The attribute to use to recognize map names, ldap_autofs_map_name The object class to use to recognize mount point entries, ldap_autofs_entry_object_class The attribute to use to recognize mount point names, ldap_autofs_entry_key The attribute to use for additional configuration information for the mount point, ldap_autofs_entry_value
For example: [domain/LDAP]...autofs_provider=ldapldap_autofs_search_base="cn=automount,dc=example,dc=com"ldap_autofs_map_object_class="automountMap"ldap_autofs_entry_object_class="automount"ldap_autofs_map_name="automountMapName"ldap_autofs_entry_key="automountKey"ldap_autofs_entry_value="automountInformation" Save and close the sssd.conf file. Configure autofs to look for the automount map information in SSSD by editing the nsswitch.conf file and changing the location from ldap to sss: [root@server ~]# vim /etc/nsswitch.confautomount: files sss Restart SSSD. [root@server ~]# service sssd restart
|
| |
