SSSD - System Security Services Daemon

SSSD (System Security Services Daemon) is a system service to access remote directories and authentication mechanisms.

SSSD is a system service that allows you to access remote directories and authentication mechanisms. You can connect a local (system SSSD client) to an external back-end system (provider like LDAP, AD, Kerberos, Identity Management (IdM) ).

Excerpt from the manual :
SSSD provides a set of daemons to manage access to remote directories and authentication mechanisms. It provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources as well as D-Bus interface. It is also the basis to provide client auditing and policy services for projects like FreeIPA. It provides a more robust database to store local users as well as extended user data.

How SSSD works

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.

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

Benefits of using SSSD

Offline authentication

SSSD optionally keeps a cache of user identities and credentials retrieved from remote providers.

So a user (if he was already authenticated once on the remote provider) can successfully authenticate to resources even if the remote provider or the client are offline.

Single user account

A single user account improves the 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.

SSSD VS Common auth

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

With caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine.

SSSD then maintains their network credentials.

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. So that reduced load on identity and authentication providers

Configuration files

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.

SSSD reads the configuration files in this order:

• The primary /etc/sssd/sssd.conf file
• 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.

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.conf file explained

Launch configuration file

Simply reload the SSSD daemon:

# service sssd reload
# systemctl reload sssd.service

With a custom file:

# sssd -c /etc/sssd/customfile.conf --daemon

Launch configuration file

There are three sections in the SSSD configuration file:

[sssd]: general SSSD process and operational configuration (basically lists the configured services, domains, and configuration parameters for each)

• domains:
  • lists all domains configured in sssd.conf used by SSD as identity providers.
  • If a domain is not listed in the domains key, it is not used by SSSD, even if it has a configuration section.
• services:
  • lists all of the system services configured in the sssd.conf, when SSSD starts, the corresponding SSSD service is started for each configured system service.
  • a service not listed in the services key is not used by SSSD even if it has a configuration section.
• config_file_version:
  • sets the version of the configuration file to set file format expectations.
  • in version 2 for all recent SSSD versions.

[service_name]: configuration options for each supported system service (see below SSSD and System Services)

• SSSD can provide credentials caches for several system services:
  • NSS:
    • [nss]
    • Name Service Switch provider service that answers name service requests from the sssd_nss module
  • PAM:
    • [pam]
    • provider service that manages a PAM conversation through the sssd_pam module.
  • SSH:
    • provider service that defines how SSSD manages the known_hosts file and other key-related configuration
  • autofs:
    • [domain/NAME] section
    • provider service that connects to an LDAP server
  • sudo:
    • [domain/NAME] section
    • provider service that connects to an LDAP server to retrieve configured sudo policies
  • PAC:
    • responder service that defines how SSSD works with Kerberos to manage Active Directory users and groups

[domain_type/DOMAIN_NAME]: configuration options for each configured identity provider

Example of a sssd.conf file:

Example:

[sssd]
domains = LOCAL
services = nss
config_file_version = 2

[nss]
filter_groups = root
filter_users = root

[domain/LOCAL]
id_provider = local
auth_provider = local
access_provider = permit	

Example with some configured services:

[sssd]
domains = LOCAL
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, autofs

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75

[pam]
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5

[domain/LDAP]
...
autofs_provider=ldap
ldap_autofs_search_base=cn=automount,dc=example,dc=com
ldap_autofs_map_object_class=automountMap
ldap_autofs_entry_object_class=automount
ldap_autofs_map_name=automountMapName
ldap_autofs_entry_key=automountKey
ldap_autofs_entry_value=automountInformation

[domain/LDAP]
id_provider = ldap

sudo_provider = ldap
ldap_uri = ldap://example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com

[domain/IDM]
id_provider = ipa
ipa_domain = example.com
ipa_server = ipa.example.com
ldap_tls_cacert = /etc/ipa/ca.crt
sudo_provider = ldap
ldap_uri = ldap://ipa.example.com
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/hostname.example.com
ldap_sasl_realm = EXAMPLE.COM
krb5_server = ipa.example.com

Documentation

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_authentication_and_authorization_in_rhel/understanding-sssd-and-its-benefits_configuring-authentication-and-authorization-in-rhel
https://jhrozek.fedorapeople.org/sssd/2.0.0/man/sssd.8.html
https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/6/html/deployment_guide/about-sssd-conf
https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/6/html/deployment_guide/configuring_services
https://access.redhat.com/documentation/fr-fr/red_hat_enterprise_linux/6/html/deployment_guide/configuration_options-nss_configuration_options