Centralized identity and authentication management offers several
benefits over the ancient "solution" of spreading password files across
all the systems of an organization. User information can be added,
modified, and deleted in one central location and the change is
effective everywhere instantly. Most commonly in today's environments
user identity and authentication functions are carried out with
-based solutions. SSSD
System Security Services Daemon, is a fairly recent client-side
all-in-one component which aims to bring together all the features
previously available only in several separate components while adding
new ones and providing increased flexibility and robustness.
Linux client-side configuration for centralized
identity and authentication stores with caching and offline support has
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.
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
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
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
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"
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.
to post comments)