System Security Service (SSSD) was initially developed to be the primary client component for FreeIPA but later became an independent project in its own right.
The primary role of SSSD is to provide access to identity and authentication resources through a common framework that can provide caching and offline support to a system. When a user logs into a network with centrally managed accounts, the user information and credentials are automatically stored in an SSSD cache on the user’s system. For offline support, SSSD authenticates the user’s credentials against the local SSSD cache. Authentication through SSSD enables LDAP, NIS, and FreeIPA services to provide an offline mode, something which is otherwise impossible. Thus SSSD is acts as an intermediary between local clients and any configured user database. Local clients connect to SSSD and then SSSD contacts the external providers if it can otherwise uses local cache to authenticate the client.
SSSD supports queries to multiple servers. Thus, a client can query a number of different user databases. It also has its own NSS and PAM interfaces for use by client systems. As of SSSD 1.9.0, an Active Directory provider is available. This provider simplifies configuration against an Active Directory server. It uses LDAP for identity and Kerberos for authentication and single-sign-on.
SSSD has one central configuration file, /etc/sssd/sssd.conf, which contains all the configuration options needed for one or several domains, possibly with different retention policies for each domain. You can define multiple domains of the same type and also different types of domain. SSSD maintains a separate cache for each domain, meaning each domain has its own cache. These cache files are stored in the /var/lib/sss/db/ directory.
SSSD was initially introduced in Fedora 11 and is now available in Red hat and downstream distributions. I suspect it will become more popular as users in lagre organizations migrate from legacy desktops to laptops and other mobile devices which may not always be able to authenticate a user against a centrally managed database such as LDAP or Active Directory.
