Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 3. Understanding SSSD and its benefits

The System Security Services Daemon (SSSD) connects local systems to remote identity providers, including LDAP and Active Directory. It retrieves and caches credentials to enable offline authentication, reduce network traffic, and streamline access control for system services.

3.1. How SSSD works
Copy link

SSSD functions by linking a local client to an external backend provider. The service operates in two stages: connecting to the remote source to retrieve identity data, then creating a local cache to verify credentials without creating permanent local accounts.

SSSD supports multiple identity and authentication providers, such as:

  • LDAP directories
  • Identity Management (IdM) domains
  • Active Directory (AD) domains
  • Kerberos realms

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 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
Copy link

The System Security Services Daemon (SSSD) enhances system efficiency by caching credentials locally. This capability enables offline authentication, minimizes traffic to remote providers, and consolidates network access into a single user account.

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.

The System Security Services Daemon (SSSD) builds its configuration by combining the primary file with modular files in the conf.d directory. This structure helps you to maintain global defaults while applying specific overrides or extensions for individual clients.

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.

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/, processed 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.

SSSD links local clients to external backends like LDAP, Identity Management (IdM), Active Directory (AD), and Kerberos. Configure these connections as domains, assigning specific providers to handle identity, authentication, or access control tasks.

Define SSSD domains in /etc/sssd/sssd.conf to map backends to specific functions. You can configure a single domain to handle identity lookups, authentication requests, and access control either separately or together.

The providers are listed in the [domain/<domain_name>] or [domain/default] section of the file.

You can configure a single domain 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/<domain_name>] 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/<domain_name>] 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/<domain_name>] 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/<domain_name>] 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.

3.4.2. Proxy providers
Copy link

Proxy providers serve as intermediaries for resources SSSD cannot directly access. SSSD connects to the proxy service to load external libraries, enabling integration with legacy systems like NIS and alternative authentication hardware.

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

With SSSD, you can mix specific providers for identity and authentication tasks. You can configure unified backends like Active Directory or hybrid setups, such as combining LDAP directories with Kerberos realms.

Expand
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.
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. Explore our recent updates.

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.

Theme

© 2026 Red HatBack to top