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) |
|