Chapter 2. Using Active Directory as an Identity Provider for SSSD

The System Security Services Daemon (SSSD) provides access to different identity and authentication providers. This service ties a local system to a larger back-end system. That can be a simple LDAP directory, domains for Active Directory (AD) or Identity Management (IdM) in Red Hat Enterprise Linux, or Kerberos realms.
SSSD configures a way to connect to an identity store to retrieve authentication information and then uses that to create a local cache of users and credentials. SSSD can also pull in group information. Authorization information is gathered by SSSD by using host-based access control (HBAC) in IdM and group policy object (GPO) settings in AD.

2.1. About SSSD

The SSSD service is an intermediary between local applications and any configured data store. This relationship brings a number of benefits for administrators:
  • Reduced load on identification and authentication servers. Rather than having every application service attempt to contact the identification server directly, each local application can contact SSSD, which in turn connects to the identification server or checks its cache.
  • Option for offline authentication. SSSD keeps a cache of user identities (and optionally also user credentials) that it retrieves from remote services. This allows users to authenticate even if the remote identification server or the local machine is offline.
  • Single user account. Users can have two or more user accounts. For example, one for their local system and another for the organizational system. This is necessary to connect to a virtual private network (VPN). Because SSSD supports caching and offline authentication, remote users can connect to network resources simply by authenticating to their local machine and then SSSD maintains their network credentials.

2.1.1. SSSD Configuration

SSSD is a local service, which connects a system to a larger, external identity service. This is done by configuring domains in the SSSD configuration file. Each domain represents a different, external data source. Domains always represent an identity provider, which supplies user information, and, optionally, define other providers for different kinds of operations, such as authentication or password changes.


SSSD allows all user identities to be created and maintained in a separate, external identity source. For Windows integration, an AD domain is typically used to manage user accounts. Local system users do not need to be created or synced with user accounts in AD – SSSD uses those Windows identities and lets the Windows users access the local system and local services.
SSSD also defines which services on the system use SSSD for credentials caching and user accounts. These relate to foundational security services such as the Name Service Switch (NSS) and Pluggable Authentication Modules (PAM), which are then used by higher-level applications.

Example 2.1. Simple sssd.conf File

domains = WIN.EXAMPLE.COM 
services = nss, pam
config_file_version = 2

id_provider = ad
auth_provider = ad
access_provider = ad

2.1.2. Active Directory Domain Configuration

As shown in Example 2.1, “Simple sssd.conf File”, the SSSD configuration file has two major sections: the first configures the SSSD service ([sssd]), the second configures configures the identity domains ([domain/NAME]). There might be additional sections that configure system services which use SSSD as an identity cache; for example [nss] or [pam].
By default, only the identity provider (id_provider) and authorization provider (access_provider) options need to be configured. The id_provider option is used for the authentication (auth_provider) and password provider (chpass_provider) options if no other types or servers are set. Active Directory can be configured as any kind of provider using the ad value.
id_provider = ad
auth_provider = ad
access_provider = ad
chpass_provider = ad

ad_server =
# only needed if DNS discovery is not working
ad_hostname =
# only needed if the host name of the client machine is incorrect
ad_domain =
# only needed if AD domain is named differently than SSSD domain
The connection information is required to identify what Active Directory server to use. Past the basic configuration, the Active Directory identity provider can be configured specifically for the Active Directory environment and specific features, such as whether to use POSIX attributes or mapping for Windows SIDs on the local system, failover servers, and account information such as home directories.
All of the LDAP domain parameters are available to the Active Directory provider, as well as Active Directory-specific configuration parameters. The complete lists are available in the sssd-ldap and sssd-ad man pages.
There is a number of options in the generic LDAP provider configuration which can be used to configure an Active Directory provider. Using the ad value is a shortcut which automatically pulls in the parameters and values to configure a given provider for Active Directory. For example, the shortcut for an access provider is:
access_provider = ad
Using generic LDAP parameters, that configuration expands to:
access_provider = ldap
ldap_access_order = expire
ldap_account_expire_policy = ad
Those settings are all set implicitly by using the ad provider type.