Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.
Chapter 3. Understanding SSSD and its benefits
The System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. The following chapters outline how SSSD works, what are the benefits of using it, how the configuration files are processed, as well as what identity and authentication providers you can configure.
3.1. How SSSD works
The System Security Services Daemon (SSSD) is a system service that allows you to access remote directories and authentication mechanisms. You can connect a local system, an SSSD client, to an external back-end system, a provider.
For example:
- An LDAP directory
- An Identity Management (IdM) domain
- An Active Directory (AD) domain
- A Kerberos realm
SSSD works in two stages:
- It connects the client to a remote provider to retrieve identity and authentication information.
- It uses the obtained authentication information to create a local cache of users and credentials on the client.
Users on the local system are then able to authenticate using the user accounts stored in the remote provider.
SSSD does not create user accounts on the local system. However, SSSD can be configured to create home directories for IdM users. Once created, an IdM user home directory and its contents on the client are not deleted when the user logs out.
Figure 3.1. How SSSD works
SSSD can also provide caches for several system services, such as Name Service Switch (NSS) or Pluggable Authentication Modules (PAM).
Only use the SSSD service for caching user information. Running both Name Service Caching Daemon (NSCD) and SSSD for caching on the same system might lead to performance issues and conflicts.
3.2. Benefits of using SSSD
Using the System Security Services Daemon (SSSD) provides multiple benefits regarding user identity retrieval and user authentication.
- Offline authentication
- SSSD optionally keeps a cache of user identities and credentials retrieved from remote providers. In this setup, a user - provided they have already authenticated once against the remote provider at the start of the session - can successfully authenticate to resources even if the remote provider or the client are offline.
- A single user account: improved consistency of the authentication process
With SSSD, it is not necessary to maintain both a central account and a local user account for offline authentication. The conditions are:
- In a particular session, the user must have logged in at least once: the client must be connected to the remote provider when the user logs in for the first time.
Caching must be enabled in SSSD.
Without SSSD, remote users often have multiple user accounts. For example, to connect to a virtual private network (VPN), remote users have one account for the local system and another account for the VPN system. In this scenario, you must first authenticate on the private network to fetch the user from the remote server and cache the user credentials locally.
With SSSD, thanks to caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine. SSSD then maintains their network credentials.
- Reduced load on identity and authentication providers
- When requesting information, the clients first check the local SSSD cache. SSSD contacts the remote providers only if the information is not available in the cache.
3.3. Multiple SSSD configuration files on a per-client basis
The default configuration file for SSSD is /etc/sssd/sssd.conf. Apart from this file, SSSD can read its configuration from all *.conf files in the /etc/sssd/conf.d/ directory.
This combination allows you to use the default /etc/sssd/sssd.conf file on all clients and add additional settings in further configuration files to extend the functionality individually on a per-client basis.
How SSSD processes the configuration files
SSSD reads the configuration files in this order:
-
The primary
/etc/sssd/sssd.conffile -
Other
*.conffiles in/etc/sssd/conf.d/, in alphabetical order
If the same parameter appears in multiple configuration files, SSSD uses the last read parameter.
SSSD does not read hidden files (files starting with .) in the conf.d directory.
3.4. Identity and authentication providers for SSSD
You can connect an SSSD client to the external identity and authentication providers, for example an LDAP directory, an Identity Management (IdM), Active Directory (AD) domain, or a Kerberos realm. The SSSD client then get access to identity and authentication remote services using the SSSD provider. You can configure SSSD to use different identity and authentication providers or a combination of them.
Identity and Authentication Providers as SSSD domains
Identity and authentication providers are configured as domains in the SSSD configuration file, /etc/sssd/sssd.conf. The providers are listed in the [domain/name of the domain] or [domain/default] section of the file.
A single domain can be configured as one of the following providers:
An identity provider, which supplies user information such as UID and GID.
-
Specify a domain as the identity provider by using the
id_provideroption in the[domain/name of the domain]section of the/etc/sssd/sssd.conffile.
-
Specify a domain as the identity provider by using the
An authentication provider, which handles authentication requests.
-
Specify a domain as the authentication provider by using the
auth_provideroption in the[domain/name of the domain]section of/etc/sssd/sssd.conf.
-
Specify a domain as the authentication provider by using the
An access control provider, which handles authorization requests.
-
Specify a domain as the access control provider using the
access_provideroption in the[domain/name of the domain]section of/etc/sssd/sssd.conf. By default, the option is set topermit, which always allows all access. See the sssd.conf(5) man page for details.
-
Specify a domain as the access control provider using the
A combination of these providers, for example if all the corresponding operations are performed within a single server.
-
In this case, the
id_provider,auth_provider, andaccess_provideroptions are all listed in the same[domain/name of the domain]or[domain/default]section of/etc/sssd/sssd.conf.
-
In this case, the
You can configure multiple domains for SSSD. You must configure at least one domain, otherwise SSSD will not start.
Proxy Providers
A proxy provider works as an intermediary relay between SSSD and resources that SSSD would otherwise not be able to use. When using a proxy provider, SSSD connects to the proxy service, and the proxy loads the specified libraries.
You can configure SSSD to use a proxy provider to enable:
- Alternative authentication methods, such as a fingerprint scanner
- Legacy systems, such as NIS
-
A local system account defined in the
/etc/passwdfile as an identity provider and a remote authentication provider, for example Kerberos - Authentication of local users using smart cards
Available Combinations of Identity and Authentication Providers
You can configure SSSD to use the following combinations of identity and authentication providers.
| Identity Provider | Authentication Provider |
|---|---|
| Identity Management [a] | Identity Management |
| Active Directory | Active Directory |
| LDAP | LDAP |
| LDAP | Kerberos |
| Proxy | Proxy |
| Proxy | LDAP |
| Proxy | Kerberos |
[a]
An extension of the LDAP provider type.
| |
sssctl utility, your host should be enrolled in Identity Management (IdM) that is in a trust agreement with an Active Directory (AD) forest.
