30.3. Configuring SSSD to Work with System Services

SSSD worked with specialized services that run in tandem with the SSSD process itself. SSSD and its associated services are configured in the sssd.conf file. on sections. The [sssd] section also lists the services that are active and should be started when sssd starts within the services directive.
SSSD currently provides several 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.
  • monitor, a special service that monitors and starts or restarts all other SSSD services. Its options are specified in the [sssd] section of the /etc/sssd/sssd.conf configuration file.

Note

If a DNS lookup fails to return an IPv4 address for a hostname, SSSD attempts to look up an IPv6 address before returning a failure. This only ensures that the asynchronous resolver identifies the correct address.
The hostname resolution behavior is configured in the lookup family order option in the sssd.conf configuration file.

30.3.1. Configuring NSS Services

SSSD 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.

30.3.1.1. About NSS Service Maps and SSSD

The 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)

30.3.1.2. Configuring NSS Services to Use SSSD

NSS 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 sss
shadow:     files sss
group:      files sss

netgroup:   files sss

30.3.1.3. Configuring SSSD to Work with NSS

The options and configuration that SSSD uses to service NSS requests are configured in the SSSD configuration file, in the [nss] services section.
  1. Open the sssd.conf file. 
    [root@server ~]# vim /etc/sssd/sssd.conf
  2. Make sure that NSS is listed as one of the services that works with SSSD. 
    [sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
  3. In the [nss] section, change any of the NSS parameters. These are listed in Table 30.1, “SSSD [nss] Configuration Parameters”. 
    [nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75
  4. Restart SSSD. 
    [root@server ~]# service sssd restart

Table 30.1. SSSD [nss] Configuration Parameters

Parameter Value Format [root@server ~] 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.

30.3.2. Configuring the PAM Service

Warning

A 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:
  1. The Authentication Configuration tool automatically writes to the /etc/pam.d/system-auth-ac file, which is symlinked to /etc/pam.d/system-auth. Any changes made to /etc/pam.d/system-auth are overwritten the next time that authconfig is run.
    So, remove the /etc/pam.d/system-auth symlink. 
    [root@server ~]# rm /etc/pam.d/system-auth
rm: remove symbolic link `/etc/pam.d/system-auth'? y
  2. Create a new /etc/pam.d/system-auth-local file. One easy way to do this is simply to copy the /etc/pam.d/system-auth-ac file. 
    [root@server ~]# cp /etc/pam.d/system-auth-ac /etc/pam.d/system-auth-local
  3. Create a new symlink between the /etc/pam.d/system-auth-local file and /etc/pam.d/system-auth. 
    [root@server ~]# ln -s /etc/pam.d/system-auth-local /etc/pam.d/system-auth
  4. Edit the /etc/pam.d/system-auth-local file, and add all of the SSSD modules to the PAM configuration: 
    #%PAM-1.0
...
auth        sufficient    pam_sss.so use_first_pass
auth        required      pam_deny.so

...
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account     required      pam_permit.so

...
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so

...
session     sufficient    pam_sss.so
session     required      pam_unix.so
    These modules can be set to include statements, as necessary.
  5. Open the sssd.conf file. 
    # vim /etc/sssd/sssd.conf
  6. Make sure that PAM is listed as one of the services that works with SSSD. 
    [sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
  7. In the [pam] section, change any of the PAM parameters. These are listed in Table 30.2, “SSSD [pam] Configuration Parameters”. 
    [pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
  8. Restart SSSD. 
    [root@server ~]# service sssd restart

Table 30.2. 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).