The System Security Services Daemon (SSSD) provides access to remote identity and authentication providers. Providers are configured as back ends with SSSD acting as an intermediary between local clients and any configured back-end provider. The local clients connect to SSSD and then SSSD contacts the providers. Benefits of SSSD include:
- Reduced load: Clients do not have to contact the identification/authentication servers directly; they need to contact only SSSD.
- Offline authentication: SSSD can, optionally, keep a cache of user identities and credentials, allowing users to authenticate offline.
- Single-user accounts: SSSD maintains network credentials, allowing users to connect to network resources by authenticating with their local username on their local machine.
Install the following SSSD packages:
# yum install sssd sssd-client
To cause SSSD to start when the system boots, enter either of the following:
# systemctl enable sssd # authconfig --enablesssd --update
Configuring SSSD Services
The main configuration file for SSSD is /etc/sssd/sssd.conf. SSSD services and domains are configured in separate sections of this file, each beginning with a name of the section in square brackets. The following are examples:
[sssd] [nss] [pam]
SSSD functionality is provided by specialized services that run together with SSSD. These specialized services are started and restarted by a special service called “monitor.” Monitor options and identity domains are configured in the [sssd] section of /etc/sssd/sssd.conf. The following is an example:
[sssd] domains = LDAP services = nss, pam
The domains directive can define multiple domains. Enter them in the order in which you want them to be queried. The services directive lists the services that are started when sssd itself starts.
Each of the specialized services that run together with SSSD is configured in separate sections in /etc/sssd/sssd.conf. For example, the [nss] section is used to configure the Name Service Switch (NSS) service. The [pam] section is used to configure the PAM service.
1. Configuring the NSS Service
Included in the sssd package is an NSS module, sssd_nss, which instructs the system to use SSSD to retrieve user information. This is configured in the [nss] section of /etc/sssd/sssd.conf. The following is an example that includes only a partial list of configurable directives:
[nss] filter_groups = root filter_users = root reconnection_retries = 3 entry_cache_timeout = 300
The filter_users and filter_groups directives tell SSSD to exclude certain users and groups from being fetched from the NSS database. The reconnection_retries directive specifies the number of times to attempt to reconnect in the event of a data provider crash. The enum_cache_timeout directive specifies, in seconds, how long sssd_nss caches requests information about all users.
2. Configuring the PAM Service
The sssd package also provides a PAM module, sssd_pam, which is configured in the [pam] section of /etc/sssd/sssd.conf. The following is an example that includes only a partial list of configurable directives:
[pam] reconnection_retries = 3 offline_credentials_expiration = 2 offline_failed_login_attempts = 3 offline_failed_login_delay = 5
– The offline_credentials_expiration directive specifies, in days, how long to allow cached logins if the authentication provider is offline.
– The offline_failed_login_attempts directive specifies how many failed login attempts are allowed if the authentication provider is offline.
To update the PAM configuration to reference all of the SSSD modules, use the authconfig command as follows to enable SSSD for system authentication:
# authconfig --update --enablesssd --enablesssdauth
This command auto-generates the PAM configuration file to include the necessary pam_sss.so entries.
Configuring SSSD Domains
SSSD domains are a combination of an identity provider and an authentication method. SSSD works with LDAP identity providers (including OpenLDAP, Red Hat Directory Server, and Microsoft Active Directory) and can use native LDAP authentication or Kerberos authentication. When configuring a domain, you define both where the user information is stored and how those users are allowed to authenticate to the system.
Similar to SSSD services, SSSD domains are also configured in separate sections of the /etc/sssd/sssd.conf file. The services and the domains are identified in the [sssd] section. Example:
[sssd] domains = LDAP services = nss, pam
This example specifies an LDAP domain. The domain section of the configuration would begin with the following header:
The domain configuration section would then specify the identity provider, the authentication provider, and any specific configuration to access the information in those providers.
The following is an example of a domain section:
[domain/LDAP] id_provider = ldap ldap_uri = ldap://ldap.example.com ldap_search_base = dc=example,dc=com auth_provider = krb5 krb5_server = kerberos.example.com krb5_realm = EXAMPLE.COM min_id = 10000 max_id = 20000
The id_provider specifies the data provider identity back end to use for this domain. Supported back ends are:
- proxy: Supports a legacy NSS provider
- local: SSSD internal local provider
- ldap: LDAP provider
– The ldap_uri directive gives a comma-separated list of the URIs (Universal Resource Identifiers) of the LDAP servers, in order of preference, to which SSSD connects.
– The ldap_search_base directive gives the base DN to use for performing LDAP user operations.
The auth_provider directive specifies the authentication provider used for the domain. If un- specified, the id_provider is used. Supported authentication providers are:
- ldap: Native LDAP authentication
- krb5: Kerberos authentication
- proxy: Relays authentication to some other PAM target
- none: Disables authentication explicitly
– The krb5_server directive gives a comma-separated list of Kerberos servers, in order of preference, to which SSSD connects.
– The krb5_realm directive gives the Kerberos realm to use for Simple Authentication and Security Layer (SASL)/Generic Security Services API (GSS-API) authentication. The configuration of SASL connections by using GSS-API is required before SSSD can use Kerberos to connect to the LDAP server.
– The last two directives, min_id and max_id, are examples of global attributes that are available to any type of domain. Other attributes include cache and timeout settings. These two directives specify UID and GID limits for the domain. If a domain contains an entry that is outside these limits, it is ignored.
Start or restart the sssd service after making any configuration changes to domains or services:
# systemctl start sssd