Authentication with SSSD

Linux

Security

Published

May 19, 2018

Modified

October 20, 2023

SSSD (System Security Services Daemon):

Manages communication with identity and authentication providers
Local clients connect to SSSD which connects to external information providers
Requires transport layer encryption against LDAP: LDAPS, TLS, or GSSAPI
Enforces one-to-one relationships between identities and authentication service
Support automount, sudo, and ssh (including host-keys)

Credential caching, offline authentication:

Cache user, group, etc. information, and authentication credentials
Reduces load on the authentication/identification servers
Caching increases resilience against outages of LDAP, Kerberos servers

References…

SSSD Project
- …source code, GitHub
- …trouble shooting
SSSD Mailing List

Packages…

…Fedora rpms/sssd
…Rocky Linux staging/rpms/sssd upstream src-rhel/rpms/sssd

`sssd` Client

sssd serves and caches the information stored

…in the remote directory server
…provides identity, authentication and authorization

…services to the host machine.

Path	Description
`/var/log/sssd/*`	Service log files
`/var/lib/sss/db/`	Cache files

Use following command to verify the functionality of the sssd service [^trouble]:

sssd -c /etc/sssd/sssd.conf -d 9 -i # debug sssd in foreground
sss_cache -E                        # expire the in-memory cache
id $user                            # resolve a user-name
id -u $user                         # display the UID for a given user
id -g $user                         # display the GID (group) for a given user
getent passwd $user                 # get the passwd line for a given user

Check for the most recent (re-)start of sssd…

journalctl -u sssd | grep Started | tail -n 1

Configuration

Packages in enterprise Linux…

Package	Description
`sssd`	`sssd.service` unit including all dependencies
`sssd-ldap`	LDAP back end for SSSD to connect with an server

Configuration files needs to be deployed and eventually the sssd.service restarted:

Path	Description
`/etc/sssd/sssd.conf`	Default configuration file for SSSD
`/etc/sssd/conf.d/*.conf`	Additional configurations…

The configuration section [sssd] is used for general SSSD process and operational configuration:

[sssd]
config_file_version = 2
services = nss, pam, ssh
domains = LDAP

services lists all of the system services which use SSSD as a sources of information. These so called responders serves as a middle man between the target application and the local cache and include sssd_nss for NSS and sssd_pam for PAM.
domains configures LDAP as service backend. The goal of the backend is to keep the cache up to date. To do so, it talks to the remote server, requests required data and then stores the data in the cache. Each backend represents one SSSD domain that is configured in the [domain/$name] section of the SSSD configuration and it is started as its own instance of sssd_be process.

Following example illustrates the process tree for sssd.service:

>>> systemctl status sssd.service
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2022-02-14 07:16:56 CET; 1h 48min ago
 Main PID: 188406 (sssd)
    Tasks: 6 (limit: 822432)
   Memory: 56.7M
   CGroup: /system.slice/sssd.service
           ├─188406 /usr/sbin/sssd -i --logger=files
           ├─188407 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
           ├─188408 /usr/libexec/sssd/sssd_be --domain LDAP --uid 0 --gid 0 --logger=files
           ├─188409 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
           ├─188410 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files
           └─188411 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --logger=files

`authselect`

authselect is a utility that allows you to configure system identity and authentication sources by selecting a specific profile. Profile is a set of files that describes how the resulting Pluggable Authentication Modules (PAM) and Network Security Services (NSS) configuration will look like. You can choose the default profile set or create a custom profile.

The default sssd profile enables the SSSD for NSS and PAM:

authselect current               # show currently enable profile
authselect select --force sssd   # enable the sssd profile

LDAP

LDAP (Lightweight Directory Access Protocol) is a protocol that is used to communicate with directory servers. Directory is a sort of a database that is used heavily for identity management use cases. The terms “LDAP”, “LDAP database” and “directory server” are usually used interchangeably.

The distinguished name (DN) is a unique name that identifies the object in the database. It is created out of set of attributes that have unique value to the object and the parent’s DN. It basically resembles a hierarchical path to the entry.
Attributes are single or multi-valued properties of the entry. Their format and functions are defined by schema and object classes. Some standard and common attributes are:
- dc domain component – used to identify the directory domain
- ou organizational unit – used to split entries into named containers
- cn canonical name – used to provide name to an object

The LDAP schema defines Default attribute names retrieved on the server. Most widely used schemas are:

rfc2307 (default) - Group members listed by name in the memberUid attribute
rfc2307bis - Group members are listed by in a multi-valued attribute member (or sometimes uniqueMember)

Query information from an LDAP server

# install LDAP client tools
dnf install -y openldap-clients
# query the LDAP server
ldapsearch -x -ZZ -H ldap://$server -b $search_base

When querying LDAP, we usually also specify a search base and scope which tells the server from which object and how far in the hierarchy it should start searching.

SSSD can connect to any LDAP server to lookup POSIX accounts and other information such as sudo rules and autofs maps using an SSSD LDAP provider. The SSSD needs to include the LDAP backend configuration:

[domain/LDAP]
id_provider = ldap
sudo_provider = none
ldap_uri = ldap://lxldap07.gsi.de,ldap://lxldap08.gsi.de
ldap_id_use_start_tls = true
ldap_search_base = ou=posix,ou=identities,dc=gsi,dc=de
ldap_schema = rfc2307bis
ldap_user_search_base = ou=users,ou=posix,ou=identities,dc=gsi,dc=de
ldap_group_search_base = ou=groups,ou=posix,ou=identities,dc=gsi,dc=de
enumerate = true

NSS

Name Service Switch (NSS) determine the sources from which to obtain name-service information. The default sssd profile enabled with authselect establishes SSSD as a source of information by creating sss entries.

Path	Description
`/etc/nsswitch.conf`	Default NSS configuration file

# list SSSD configuration for NSS
>>> grep -v ^# /etc/nsswitch.conf | grep sss
passwd:     sss files systemd
group:      sss files systemd
netgroup:   sss files
automount:  sss files
services:   sss files
shadow:     files sss

This means that the system first looks to SSSD if information concerning one of those items is requested:

passwd for user information
group for user group information
netgroup for NIS netgroup information
automount for NFS automount information
services for information regarding services

The [nss] section in the SSSD configuration sets following parameters:

[nss]
filter_groups = root
filter_users = root

filter_users, filter_group tells SSSD to exclude certain users from being fetched from the NSS database. This is particularly useful for system accounts such as root.

PAM

PAM (Pluggable Authentication Modules) is a system of modules that handle the authentication tasks. PAM is pluggable because a PAM module exists for different types of authentication sources, such as Kerberos, SSSD, NIS, or the local file system. You can prioritize different authentication sources.

Path	Description
`/etc/pam.d/*`	PAM module configuration files

Each PAM-aware application or service has a file in the /etc/pam.d/ directory. Each file in this directory has the same name as the service to which it controls access and contains a group of directives formatted as follows:

<module interface>  <control flag>   <module name>   <module arguments>

Four types of PAM module interface are currently available. Each of these corresponds to a different aspect of the authorization process:

auth — This module interface authenticates use. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships or Kerberos tickets.
account — This module interface verifies that access is allowed. For example, it may check if a user account has expired or if a user is allowed to log in at a particular time of day.
password — This module interface is used for changing user passwords.
session — This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user’s home directory and making the user’s mailbox available.

authselect will enable the pam_sssd.so the required modules:

>>> grep sss /etc/pam.d/*
/etc/pam.d/password-auth:auth        sufficient                                   pam_sss.so forward_pass
/etc/pam.d/password-auth:account     [default=bad success=ok user_unknown=ignore] pam_sss.so
/etc/pam.d/password-auth:password    sufficient                                   pam_sss.so use_authtok
/etc/pam.d/password-auth:session     optional                                     pam_sss.so
/etc/pam.d/system-auth:auth        sufficient                                   pam_sss.so forward_pass
/etc/pam.d/system-auth:account     [default=bad success=ok user_unknown=ignore] pam_sss.so
/etc/pam.d/system-auth:password    sufficient                                   pam_sss.so use_authtok
/etc/pam.d/system-auth:session     optional                                     pam_sss.so

Autofs

Autofs is able to lookup maps stored in LDAP using an SSSD automounter lookup module.

Add the autofs service to the list of services that SSSD manages.
Create a new [autofs] service configuration section. This section can be left blank.
The Autofs support would be turned on by specifying autofs_provider = ldap in a domain section.
Configure the search base with ldap_autofs_* (according the structure of the LDAP server).
Configure Autofs to look for the automount map information in SSSD by editing the nsswitch.conf.

Example of an /etc/sssd/sssd.conf including an Autofs configuration:

[sssd]

...
services = nss, pam, ssh, autofs
...

[domain/LDAP]

...
autofs_provider = ldap
ldap_autofs_search_base = ou=automount,ou=services,dc=gsi,dc=de
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
...

[autofs]

In case automount is not working as expected:

Check the configuration /etc/sssd/sssd.conf and /etc/nsswitch.conf
Retrieve the autmounter maps from LDAP over SSSD with automount -m
Run automount in forground and debug mode

# ... check if the maps are resolved via SSSD
automount -m | grep $USER
# run in foreground for debugging, and look for error messages, for example...
automount -f -d

Cache

SSSD caches: users, groups, autofs maps, sudo rules, SSH keys

…cache lookup performed when data is requested
…for example when using id, getent, su or sudo commands
sss_cache commands used to perform cache cleanup

The SSSD Architecture documentation describes the cache levels…

Local cache …data currently cached and known to SSSD
- …on disk using the ldb database (LDAP-like embedded database)
- …object stored in cache with expiration time
- …SSSD tries to refresh expired objects
- …object stale if backend not reachable
Negative cache (ncache) …non-persistent cache for negative lookups
- …stored inside each SSSD responder
- …objects that are known to not exist (user does not exist)
In-memory cache (memcache) …volatile memory mapped cache of selected objects

Relevant options in sssd.conf…

NSS configuration…
- enum_cache_timeout …how many seconds should nss_sss cache enumerations …defaults 120
- memcache_timeout …time in seconds for which records in the in-memory cache will be valid …default 300
Domain configuration…
- account_cache_expiration …days entries are left in cache after last successful login …default 0 (unlimited)
- entry_cache_timeout …seconds nss_sss consider entries valid …defaults to 5400 (90 minutes)
- …additional options per object type …for example entry_cache_user_timeout

--- title: Authentication with SSSD categories: - Linux - Security date: 2018/05/19 date-modified: 2023/10/20 --- SSSD (System Security Services Daemon): * Manages communication with identity and authentication providers * Local clients connect to SSSD which connects to external information providers * Requires transport layer encryption against LDAP: LDAPS, TLS, or GSSAPI * Enforces one-to-one relationships between identities and authentication service * Support **automount**, **sudo**, and **ssh** (including host-keys) Credential caching, offline authentication: * Cache user, group, etc. information, and authentication credentials * Reduces load on the authentication/identification servers * Caching increases resilience against outages of LDAP, Kerberos servers References... * [SSSD Project](https://sssd.io) * ...[source code](https://github.com/SSSD/sssd), GitHub * ...[trouble shooting](https://sssd.io/troubleshooting/basics.html) * [SSSD Mailing List][tR1Dg] [tR1Dg]: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org Packages... * ...Fedora [rpms/sssd][2A2aF] * ...Rocky Linux [staging/rpms/sssd][uYWax] upstream [src-rhel/rpms/sssd][Q8lhf] [uYWax]: https://git.rockylinux.org/staging/rpms/sssd [Q8lhf]: https://git.rockylinux.org/staging/src-rhel/rpms/sssd [2A2aF]: https://src.fedoraproject.org/rpms/sssd ## `sssd` Client `sssd` serves and caches the information stored * ...in the remote directory server * ...provides identity, authentication and authorization ...services to the host machine. Path | Description -------------------------|-------------------------------- `/var/log/sssd/*` | Service log files `/var/lib/sss/db/` | Cache files Use following command to verify the functionality of the `sssd` service [^trouble]: ```bash sssd -c /etc/sssd/sssd.conf -d 9 -i # debug sssd in foreground sss_cache -E # expire the in-memory cache id $user # resolve a user-name id -u $user # display the UID for a given user id -g $user # display the GID (group) for a given user getent passwd $user # get the passwd line for a given user ``` Check for the most recent (re-)start of `sssd`... ```sh journalctl -u sssd | grep Started | tail -n 1 ``` ### Configuration Packages in enterprise Linux... Package | Description ---------------|---------------------------- `sssd` | `sssd.service` unit including all dependencies `sssd-ldap` | LDAP back end for SSSD to connect with an [](sssd:ldap) server Configuration files needs to be deployed and eventually the `sssd.service` restarted: Path | Description -------------------------|-------------------------------- `/etc/sssd/sssd.conf` | Default configuration file for SSSD `/etc/sssd/conf.d/*.conf`| Additional configurations... The configuration section `[sssd]` is used for general SSSD process and operational configuration: ```ini [sssd] config_file_version = 2 services = nss, pam, ssh domains = LDAP ``` * `services` lists all of the system services which use SSSD as a sources of information. These so called **responders** serves as a middle man between the target application and the local cache and include `sssd_nss` for NSS and `sssd_pam` for PAM. * `domains` configures LDAP as service **backend**. The goal of the backend is to keep the cache up to date. To do so, it talks to the remote server, requests required data and then stores the data in the cache. Each backend represents one SSSD domain that is configured in the `[domain/$name]` section of the SSSD configuration and it is started as its own instance of `sssd_be` process. Following example illustrates the process tree for `sssd.service`: ```bash >>> systemctl status sssd.service ● sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2022-02-14 07:16:56 CET; 1h 48min ago Main PID: 188406 (sssd) Tasks: 6 (limit: 822432) Memory: 56.7M CGroup: /system.slice/sssd.service ├─188406 /usr/sbin/sssd -i --logger=files ├─188407 /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files ├─188408 /usr/libexec/sssd/sssd_be --domain LDAP --uid 0 --gid 0 --logger=files ├─188409 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files ├─188410 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files └─188411 /usr/libexec/sssd/sssd_ssh --uid 0 --gid 0 --logger=files ``` ### `authselect` `authselect` is a utility that allows you to configure system identity and authentication sources by selecting a specific profile. Profile is a set of files that describes how the resulting Pluggable Authentication Modules (PAM) and Network Security Services (NSS) configuration will look like. You can choose the default profile set or create a custom profile. The default `sssd` profile enables the SSSD for NSS and PAM: ```bash authselect current # show currently enable profile authselect select --force sssd # enable the sssd profile ``` ## LDAP LDAP (Lightweight Directory Access Protocol) is a protocol that is used to communicate with directory servers. Directory is a sort of a database that is used heavily for identity management use cases. The terms “LDAP”, “LDAP database” and “directory server” are usually used interchangeably. * The **distinguished name** (DN) is a unique name that identifies the object in the database. It is created out of set of attributes that have unique value to the object and the parent’s DN. It basically resembles a hierarchical path to the entry. * **Attributes** are single or multi-valued properties of the entry. Their format and functions are defined by schema and object classes. Some standard and common attributes are: - `dc` domain component – used to identify the directory domain - `ou` organizational unit – used to split entries into named containers - `cn` canonical name – used to provide name to an object The LDAP **schema** defines Default attribute names retrieved on the server. Most widely used schemas are: * `rfc2307` (default) - Group members listed by name in the `memberUid` attribute * `rfc2307bis` - Group members are listed by in a multi-valued attribute member (or sometimes uniqueMember) Query information from an LDAP server ```bash # install LDAP client tools dnf install -y openldap-clients # query the LDAP server ldapsearch -x -ZZ -H ldap://$server -b $search_base ``` When querying LDAP, we usually also specify a **search base** and **scope** which tells the server from which object and how far in the hierarchy it should start searching. SSSD can connect to any LDAP server to lookup POSIX accounts and other information such as sudo rules and autofs maps using an SSSD LDAP provider. The SSSD needs to include the LDAP backend configuration: ```ini [domain/LDAP] id_provider = ldap sudo_provider = none ldap_uri = ldap://lxldap07.gsi.de,ldap://lxldap08.gsi.de ldap_id_use_start_tls = true ldap_search_base = ou=posix,ou=identities,dc=gsi,dc=de ldap_schema = rfc2307bis ldap_user_search_base = ou=users,ou=posix,ou=identities,dc=gsi,dc=de ldap_group_search_base = ou=groups,ou=posix,ou=identities,dc=gsi,dc=de enumerate = true ``` ## NSS Name Service Switch (NSS) determine the sources from which to obtain name-service information. The default `sssd` profile enabled with `authselect` establishes SSSD as a source of information by creating `sss` entries. Path | Description -------------------------|-------------------------------- `/etc/nsswitch.conf` | Default NSS configuration file ```bash # list SSSD configuration for NSS >>> grep -v ^# /etc/nsswitch.conf | grep sss passwd: sss files systemd group: sss files systemd netgroup: sss files automount: sss files services: sss files shadow: files sss ``` This means that the system first looks to SSSD if information concerning one of those items is requested: * `passwd` for user information * `group` for user group information * `netgroup` for NIS netgroup information * `automount` for NFS automount information * `services` for information regarding services The `[nss]` section in the SSSD configuration sets following parameters: ```ini [nss] filter_groups = root filter_users = root ``` `filter_users`, `filter_group` tells SSSD to exclude certain users from being fetched from the NSS database. This is particularly useful for system accounts such as root. ## PAM PAM (Pluggable Authentication Modules) is a system of modules that handle the authentication tasks. PAM is pluggable because a PAM module exists for different types of authentication sources, such as Kerberos, SSSD, NIS, or the local file system. You can prioritize different authentication sources. Path | Description -------------------------|-------------------------------- `/etc/pam.d/* ` | PAM module configuration files Each PAM-aware application or service has a file in the `/etc/pam.d/` directory. Each file in this directory has the same name as the service to which it controls access and contains a group of directives formatted as follows: ``` <module interface> <control flag> <module name> <module arguments> ``` Four types of PAM module interface are currently available. Each of these corresponds to a different aspect of the authorization process: * `auth` — This module interface authenticates use. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships or Kerberos tickets. * `account` — This module interface verifies that access is allowed. For example, it may check if a user account has expired or if a user is allowed to log in at a particular time of day. * `password` — This module interface is used for changing user passwords. * `session` — This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user's home directory and making the user's mailbox available. `authselect` will enable the `pam_sssd.so` the required modules: ```bash >>> grep sss /etc/pam.d/* /etc/pam.d/password-auth:auth sufficient pam_sss.so forward_pass /etc/pam.d/password-auth:account [default=bad success=ok user_unknown=ignore] pam_sss.so /etc/pam.d/password-auth:password sufficient pam_sss.so use_authtok /etc/pam.d/password-auth:session optional pam_sss.so /etc/pam.d/system-auth:auth sufficient pam_sss.so forward_pass /etc/pam.d/system-auth:account [default=bad success=ok user_unknown=ignore] pam_sss.so /etc/pam.d/system-auth:password sufficient pam_sss.so use_authtok /etc/pam.d/system-auth:session optional pam_sss.so ``` ## Autofs Autofs is able to lookup maps stored in LDAP using an SSSD automounter lookup module. * Add the `autofs` service to the list of services that SSSD manages. * Create a new `[autofs]` service configuration section. This section can be left blank. * The Autofs support would be turned on by specifying `autofs_provider = ldap` in a domain section. * Configure the search base with `ldap_autofs_*` (according the structure of the LDAP server). * Configure Autofs to look for the automount map information in SSSD by editing the `nsswitch.conf`. Example of an `/etc/sssd/sssd.conf` including an Autofs configuration: ```ini [sssd] ... services = nss, pam, ssh, autofs ... [domain/LDAP] ... autofs_provider = ldap ldap_autofs_search_base = ou=automount,ou=services,dc=gsi,dc=de 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 ... [autofs] ``` In case automount is not working as expected: 1. Check the configuration `/etc/sssd/sssd.conf` and `/etc/nsswitch.conf` 2. Retrieve the autmounter maps from LDAP over SSSD with `automount -m` 3. Run `automount` in forground and debug mode ```sh # ... check if the maps are resolved via SSSD automount -m | grep $USER # run in foreground for debugging, and look for error messages, for example... automount -f -d ``` ## Cache SSSD caches: users, groups, autofs maps, sudo rules, SSH keys - ...[cache lookup][00as2] performed when data is requested - ...for example when using `id`, `getent`, `su` or `sudo` commands - `sss_cache` commands used to perform cache cleanup [00as2]: https://sssd.io/docs/architecture.html#cache-lookup The [SSSD Architecture][YCpBu] documentation describes the **cache levels**... [YCpBu]: https://sssd.io/docs/architecture.html - Local cache ...data currently cached and known to SSSD - ...on disk using the ldb database (LDAP-like embedded database) - ...object stored in cache _with expiration time_ - ...SSSD tries to refresh expired objects - ...object stale if backend not reachable - Negative cache (ncache) ...non-persistent cache for negative lookups - ...stored inside each SSSD responder - ..._objects that are known to not exist_ (user does not exist) - In-memory cache (memcache) ...volatile memory mapped cache of selected objects Relevant options in `sssd.conf`... - NSS configuration... - `enum_cache_timeout` ...how many seconds should `nss_sss` cache enumerations ...defaults 120 - `memcache_timeout` ...time in seconds for which records in the in-memory cache will be valid ...default 300 - Domain configuration... - `account_cache_expiration` ...days entries are left in cache after last successful login ...default `0` (unlimited) - `entry_cache_timeout` ...seconds `nss_sss` consider entries valid ...defaults to 5400 (90 minutes) - ...additional options per object type ...for example `entry_cache_user_timeout`

sssd Client