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:

  1. It connects the client to a remote provider to retrieve identity and authentication information.
  2. 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

A flow chart displaying a local system (an SSSD client) with an "SSSD cache" on the left and a remote system (provider) on the right. An arrow originating from the remote system and pointing inside the SSSD cache of the local system is labeled to explain that SSSD retrieves and stores information about users from the remote system.

SSSD can also provide caches for several system services, such as Name Service Switch (NSS) or Pluggable Authentication Modules (PAM).

Note

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:

  1. The primary /etc/sssd/sssd.conf file
  2. Other *.conf files in /etc/sssd/conf.d/, in alphabetical order

If the same parameter appears in multiple configuration files, SSSD uses the last read parameter.

Note

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_provider option in the [domain/name of the domain] section of the /etc/sssd/sssd.conf file.
  • An authentication provider, which handles authentication requests.

    • Specify a domain as the authentication provider by using the auth_provider option in the [domain/name of the domain] section of /etc/sssd/sssd.conf.
  • An access control provider, which handles authorization requests.

    • Specify a domain as the access control provider using the access_provider option in the [domain/name of the domain] section of /etc/sssd/sssd.conf. By default, the option is set to permit, which always allows all access. See the sssd.conf(5) man page for details.
  • 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, and access_provider options are all listed in the same [domain/name of the domain] or [domain/default] section of /etc/sssd/sssd.conf.
Note

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/passwd file 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.

Table 3.1. Available Combinations of Identity and Authentication Providers
Identity ProviderAuthentication 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.


[1] To list and verify the status of the domains using the sssctl utility, your host should be enrolled in Identity Management (IdM) that is in a trust agreement with an Active Directory (AD) forest.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.