8.2.2.1. 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.
8.2.2.2. Server Load Reduction
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.
8.2.2.3. Support for 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.
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.
8.2.2.4. Support for LDAP Referrals
SSSD supports two types of LDAP referrals: object-level referrals and subtree referrals. These referral types and the extent of SSSD support is outlined below.
8.2.2.4.1. Object-level Referrals
SSSD provides full support for object-level referrals within the same LDAP server, correctly handling any differences in the distinguished name (DN) that might exist as part of the LDAP server referral configuration.
SSSD provides partial support for object-level referrals between different LDAP servers, and requires that the full DN of an LDAP request be identical on each server. SSSD does not support referrals to different DN paths on other servers.
8.2.2.4.2. Subtree Referrals
SSSD provides a similar level of support for subtree referrals as it does for object-level referrals. That is, it supports referrals to a changed DN on the local system or to an identical DN on a remote system. The difference with subtree referrals, however, is the ability to set up identical subtrees on each LDAP server and to then configure referrals between these subtrees.
8.2.2.4.3. Enabling LDAP Referrals
To take advantage of the SSSD LDAP referral functionality, you need to set the ldap_referrals option to TRUE in the LDAP domain configuration section of the /etc/sssd/sssd.conf file. This will enable anonymous access to the second LDAP server.
SSSD only supports LDAP referrals when it is compiled with OpenLDAP version 2.4.13 or later.
8.2.2.5. 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
[email protected], 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.
8.2.2.6. Integration with IPA
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 additional functionality, including support for dynamic DNS updates, host-based access control, and password migration from an LDAP-only environment into the LDAP/Kerberos 5 environment employed by IPA.
8.2.2.6.1. Support for Dynamic DNS Updates
Because the IP address of IPA clients can change, SSSD provides the ability to dynamically update the client's DNS entry on the IPA server. Using a combination of Kerberos and GSS-TSIG (Generic Security Service Algorithm for Secret Key Transaction), IPA can determine the identity of the host machine, authenticate it, and allow that machine to edit its own DNS record. These changes are then stored in the LDAP back end.
Using this authentication system means that each IPA client can only edit its own DNS record; it cannot edit the DNS record of any other client.
The SSSD configuration file provides two options used for setting up dynamic DNS updates: ipa_dyndns_update, used to enable dynamic DNS updates; and ipa_dyndns_iface, which specifies the interface whose IP address should be used for dynamic DNS updates.
Refer to the sssd-ipa manual page for more information about these options, and how to configure dynamic DNS updates.
Support for dynamic DNS updates is only available on IPA version 2 or later, and with DNS correctly configured.
