Product SiteDocumentation Site

15.2.2. SSSD Features

15.2.2.1. Performing Offline Authentication

One of the primary benefits of SSSD is offline authentication. This solves the case of users having a separate corporate account and a local machine account because of the common requirement to implement a Virtual Private Network (VPN).
SSSD can cache remote identities and authentication credentials. This means that you can still authenticate with these remote identities even when a machine is offline. In an SSSD system, you only need to manage one account.

15.2.2.2. Reducing Server Load

The use of SSSD also helps to reduce the load on identification servers. For example, using nss_ldap, every client application that needs to request user information opens its own connection to the LDAP server. Managing these multiple connections can lead to a heavy load on the LDAP server. In an SSSD system, only the SSSD Data Provider process actually communicates with the LDAP server, reducing the load to one connection per client system.

15.2.2.3. Specifying Multiple Domains

You can use SSSD to specify multiple domains of the same type. Compare this to an nsswitch.conf file configuration, with which you can only request user information from a single server of any particular type (LDAP, NIS, etc.). With SSSD, you can create multiple domains of the same, or of different types of identity provider.
Beginning with version 0.6.0, SSSD maintains a separate database file for each domain. This means that each domain has its own cache, and in the event that problems occur and maintenance is necessary, it is very easy to purge the cache for a single domain, by stopping sssd and deleting the corresponding cache file. These cache files are stored in the /var/lib/sss/db/ directory.
All cache files are named according to the domain that they represent, for example cache_DOMAINNAME.ldb.
Considerations Associated with Deleting Cache Files
Deleting a domain's cache file can have some unexpected side effects. You should be aware of the following before you proceed:
  • Deleting the cache file also deletes all user data (both identification and cached credentials). Consequently, you should not proceed unless you are online and can authenticate with your username against the domain's servers, because offline authentication will fail.
  • If you are online and change your configuration to reference a different identity provider, SSSD will recognize users from both providers until the cached entries from the original provider time out.
    To avoid this situation, you can either purge the cache or use a different domain name for the new provider (this is the recommended practice). Changing the domain name means that when you restart SSSD it will create a new cache file (with the new name) and the old file will be ignored.

15.2.2.4. Differentiating Like-named Users

SSSD supports the differentiation of like-named users in different domains. For example, you can differentiate the user kate in the ldap.example.com domain from the user kate in the ldap.myhome.com domain. You can use SSSD to make requests using fully-qualified usernames. If you request information for kate, you will receive the information from whichever domain is listed first in the look-up order. If you request information for kate@ldap.myhome.com, however, you will receive the correct user information.
SSSD also provides a filter_users option, which you can use to exclude certain users from being fetched from the database. Refer to the sssd.conf(5) manual page for full details about this option.

15.2.2.5. Integrating with Other Products

Beyond the offline authentication, multiple domain management and other features already described, SSSD is also designed to integrate with and enhance the functionality of IPA clients. In an environment with the latest version of IPA installed, SSSD provides added functionality, including host-based access control, and password migration from an LDAP-only environment into the LDAP/Kerberos 5 environment employed by IPA.