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:
Additional Resources
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 | | sss_ssh_authorizedkeys | | sss_ssh_knownhostsproxy |
|
| Cache Maintenance | | sss_cache (cleanup) | | sss_useradd, sss_usermod, sss_userdel, sss_seed (user cache entry management) |
|
Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.