SSSD: System Security Services Daemon

Linux client-side configuration for centralized identity and authentication stores with caching and offline support has traditionally required configuration of several independent components; the end result and operational efficiency has not always been optimal. Offline support means that previously logged-in users' password hashes and identity information are stored locally so that all operations requiring authentication or UID to username mapping can be processed locally.

Let us consider the components in a typical case where LDAP and Kerberos are used for identity and authentication and there are mobile users who roam around with their laptops between different networks. First, nss_ldap has to be configured to retrieve the user identity information from LDAP. Then pam_krb5 needs to be configured to allow for user authentication. Alas, neither of these components supports caching or offline mode. So nscd needs to be configured to cache user information. And then finally pam_ccreds is needed for caching authentication credentials while offline. Most readers would probably agree that this scheme isn't the most efficient and robust solution so there may be some room for improvement.

What SSSD does

SSSD provides several features but the most important is to provide access to identity and authentication resources through a common framework that can provide caching and offline support to the system. For offline support SSSD keeps the credentials in a local cache. When a user logs in to an organization's network with their centrally managed account on their laptop, the user information and credentials are automatically stored in the SSSD cache.

Secondly, it supports queries to multiple servers. Thus, one can query a number of different user databases. Third, the daemon has its own NSS and PAM interfaces for use by client systems. From a performance point of view, this offers advantages. Instead of needing to set up a connection for each and every application that queries the NSS LDAP database, only a single socket from SSSD to the LDAP server is required. And all these features can be configured in a single configuration file.

For users, authentication and Kerberos tickets will then work in a straightforward way: when logging in while online (i.e., a connection to the central user account service can be made), a user enters their username and password and, once verified, a Kerberos ticket for the user is automatically acquired. A successful online login also refreshes the user's cache entry without any manual steps.

When logging in while offline, authentication is done against the cached information. When SSSD observes that the system is online again (e.g., after the user has established a VPN connection), it can acquire a Kerberos ticket for the user in the background without any additional effort by the user. Kerberos tickets can be also be automatically renewed based on the SSSD configuration. If an organization has implemented single sign-on (SSO) using Kerberos then SSSD helps to provide very smooth but secure user experience.

In practical terms, 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. NSS and PAM are configured to use the SSSD modules, libnss_sss.so and pam_sss.so, respectively, and the sssd service needs to be enabled. Distributions like Fedora and RHEL have also integrated SSSD as part of their authconfig tool used to configure user information sources removing the need for manually editing NSS or PAM configuration files (also providing basic configuration for sssd.conf).

It should be noted that, in addition to sssd.conf, /etc/krb5.conf needs to be configured when using Kerberos for authentication. That is also required for applications and utilities using the Kerberos libraries directly. The manual page sssd.conf(5) provides a comprehensive overview of the available configuration options and Fedora SSSD Guide offers a complete walk-through for setting up SSSD.

In addition to identity and authentication methods like LDAP and Kerberos, SSSD also includes support for netgroups and proxied authentication (for example to be used with NIS, since a native NIS backend is not yet available, although it is in the roadmap). These might be helpful features for organizations during a transition when moving from NIS to LDAP/Kerberos. Another interesting feature is host-based access control (HBAC) using FreeIPA. HBAC rules can be used to control which users or groups can access a specific host.

Past and future

SSSD can trace its origins to the FreeIPA project. The SSSD project, originally codenamed "Bluebox" for reasons lost to history, was envisioned as the FreeIPA's primary client component. As SSSD began to take shape, it was realized that many of the enhancements that were being developed to support FreeIPA would also be valuable for users of other LDAP and Kerberos environments. Thus the long-term vision for SSSD was revised and it became a project in its own right, related to FreeIPA, but distinct. Since its introduction in Fedora 11, SSSD's user and developer community has grown rapidly. It is now available for all major distributions (Fedora, Ubuntu, RHEL, openSUSE, and others) and there are already some large enterprises which have already deployed it globally as part of their Linux installations.

Several notable new features are in the roadmap. Work is going on to use sudo's plugin interface in SSSD to make it easier to maintain centralized sudo rules that also function while offline. Another planned addition is automounter integration which would allow SSSD to retrieve LDAP served automount maps for autofs. Enhanced Active Directory integration and D-Bus based interfaces for extended user information and data are also coming. There are other interesting features planned for SSSD — additional suggestions and participation from the community is warmly welcomed.

The use of the SSSD offers many benefits, especially for administrators and mobile users. Instead of having multiple accounts, users can simply use a single account. Kerberos tickets can be automatically acquired and renewed, which makes the use of "kerberized" services seamless but secure. Offline mode can also be useful in data centers to help bridge the gap caused by a temporary failure of the LDAP or Kerberos servers. Compared with older solutions, SSSD offers far more flexible management and simplified administration for client-side identity and authentication needs.