Most system authentication is configured locally, which means that services must check with a local user store to determine users and credentials. What SSSD does is allow a local service to check with a local cache in SSSD, but that cache may be taken from any variety of remote identity providers — an LDAP directory, an Identity Management domain, Active Directory, possibly even a Kerberos realm.
SSSD is an intermediary between local clients and any configured data store. This relationship brings a number of benefits for administrators:
While this chapter covers the basics of configuring services and domains in SSSD, this is not a comprehensive resource. Many other configuration options are available for each functional area in SSSD; check out the man page for the specific functional area to get a complete list of options.
Table 13.1. A Sampling of SSSD Man Pages
| Functional Area || Man Page |
| General Configuration || sssd.conf(8) |
| sudo Services || sssd-sudo |
| LDAP Domains || sssd-ldap |
| Active Directory Domains ||
| Identity Management (IdM or IPA) Domains ||
| Kerberos Authentication for Domains || sssd-krb5 |
| OpenSSH Keys || |
| Cache Maintenance || |
|sss_useradd, sss_usermod, sss_userdel, sss_seed (user cache entry management)|