SSSD solves many problems in the Linux realm, such as integration with Microsoft Active Directory, centralized host-based access control (HBAC) and sudo rules, and offline login if the identity server is unavailable.

Before the introduction of SSSD, the configuration required for the use of LDAP and Kerberos for identity, and authentication was complex. Manual configuration included nss_ldap for LDAP identities, pam_krb5 for Kerberos authentication, nscd to cache the information retrieved from the LDAP directory, and pam_ccreds to cache Kerberos credentials.

Figure 2.1: SSSD Architecture

SSSD does not only cache user and group information; it can also cache sudo rules and SSH keys, among others. Note that back ends are the only components that can write to the local cache.

Three types of cache are used within SSSD.

The local cache is stored persistently on disk, and is the primary store.

A negative cache exists inside each responder, and is used to store negative lookups; information that proves that something does not exist in the identity management server. Negative caches are not persistent.

The third type of cache is the in-memory cache of the name service switch (NSS) responder. This serves the standard purpose of speeding up responses for information that was recently successfully retrieved.

Manually configuring SSSD, NSS, and Pluggable Authentication Modules (PAM) can be a complex task. Because these services need to work together, several tools are available that can simplify configuration. In Red Hat Enterprise Linux 7 and earlier, authconfig was the tool of choice for configuring the system to use centralized authentication. You can use authconfig by using its GUI, text-based user interface (TUI), or command-line interfaces.

With the introduction of RHEL 8, authconfig was replaced by authselect. Instead of configuring elements of PAM and NSS individually, authselect uses preconfigured profiles:

The sssctl command enables interaction with SSSD, such as verifying the state of the daemon, servers, domains, and objects in the cache. The sssctl command is provided by the sssd-tools package, which is not installed by default.

When configuring a system as an IdM client, the ipa-client-install command configures SSSD, replacing any existing configuration. There is no need to use the authselect command. You also do not need authselect when using the realm join command to join a system to Active Directory.

The NSS configuration is stored in the /etc/nsswitch.conf file. Each line in the file consists of a database name followed by a series of services to try in order. Some common database names, such as passwd, group, and hosts, match the files of the same name in the /etc directory.

The following example entry in /etc/nsswitch.conf defines the order of services to resolve hostnames:

hosts:      files dns

The /etc/hosts file is tried first, followed by DNS if the queried name is not found.

As a general rule, you only change the order of services to override the default behavior for a specific system. The configuration implemented by tools is usually correct.

For example, overriding DNS records with entries in /etc/hosts requires the files service to be listed first.

When a service such as sss is listed first, you should not remove the files service. Having a local NSS service to fall back on when the network is unavailable can enable system services to continue functioning.

Because SSSD can cache several different types of information, it can be listed as a service for different NSS databases. The following content is part of the /etc/nsswitch.conf file on the workstation machine.

passwd:     sss files systemd
shadow:     files
group:      sss files systemd
hosts:      files dns myhostname
services:   files sss
netgroup:   sss
automount:  files sss

aliases: files
ethers: files
gshadow: files
networks: files dns
protocols: files
publickey: files
rpc: files

In this example, SSSD is queried for user and group information before the local /etc/passwd and /etc/group files.

Because the passwd and shadow information is combined into one structure in network databases, shadow information is included in the sss lookup for passwd.

The netgroup database only exists in a network context, and has no local equal.

The systemd module ensures that the root and nobody users and groups (UID and GID of 0 and 65534, respectively) always remain resolvable, even if not listed in the /etc/passwd or /etc/group files, or if these files are missing.

The myhostname module provides hostname resolution for the locally configured system hostname. This module returns the information of the gethostname() system call, meaning localhost, localhost.localdomain, routing gateway addresses, and default outbound interfaces.

Most of the databases at the bottom of the file have no available network service.

PAM can enforce security controls in four different management groups:

The system is pluggable because multiple modules can be stacked for each management group. Each stack of modules is processed from the top down, so module order is important.

Each of the management groups support various levels of control:

Traditionally, the syntax for a PAM rule in /etc/pam.conf consists of the service type control module-path module-arguments fields. In modern Linux systems, /etc/pam.conf has been replaced with multiple files located under the /etc/pam.d directory.

File names in /etc/pam.d match the name of the service, enabling that field to be removed from the rules. Rules in these files now follow the type control module-path module-arguments format.

This change allows packages to install their own default PAM configuration.

The following examples show the default content of the /etc/pam.d/sshd file.

Many PAM modules are available that can perform myriad checks before approving a login. All PAM modules should provide a man page; use the name of the module without the .so extension.

[user@host ~]$ man 8 pam_unix
PAM_UNIX(8)                     Linux-PAM Manual                    PAM_UNIX(8)

NAME
       pam_unix - Module for traditional password authentication

SYNOPSIS
       pam_unix.so [...]

DESCRIPTION
       This is the standard Unix authentication module. It uses standard calls
       from the system's libraries to retrieve and set account information as
       well as authentication. Usually this is obtained from the /etc/passwd
       and the /etc/shadow file as well if shadow is enabled.
...output omitted...