Chapter 5. Additional configuration for identity and authentication providers
The System Security Services Daemon (SSSD) is a system service to access remote directories and authentication mechanisms. The main configuration file for SSSD is /etc/sssd/sssd.conf
. The following chapters outline how you can configure SSSD services and domains by modifying the /etc/sssd/sssd.conf
file to:
- Adjust how SSSD interprets and prints full user names to enable offline authentication.
- Configure DNS Service Discovery, simple Access Provider Rules, and SSSD to apply an LDAP Access Filter.
5.1. Adjusting how SSSD interprets full user names
SSSD parses full user name strings into the user name and domain components. By default, SSSD interprets full user names in the format user_name@domain_name
based on the following regular expression in Python syntax:
(?P<name>[^@]+)@?(?P<domain>[^@]*$)
For Identity Management and Active Directory providers, the default user name format is user_name@domain_name
or NetBIOS_name\user_name
.
You can adjust how SSSD interprets full user names by adding the re_expression
option to the /etc/sssd/sssd.conf
file and defining a custom regular expression.
-
To define the regular expression globally, add the regular expression to the
[sssd]
section of thesssd.conf
file as shown in the Defining regular expressions globally example. -
To define the regular expression for a particular domain, add the regular expression to the corresponding domain section (for example,
[domain/LDAP]
) of thesssd.conf
file as shown in the Defining regular expressions a particular domain example.
Prerequisites
-
root
access
Procedure
-
Open the
/etc/sssd/sssd.conf
file. Use the
re_expression
option to define a custom regular expression.Example 5.1. Defining regular expressions globally
To define the regular expressions globally for all domains, add
re_expression
to the[sssd]
section of thesssd.conf
file.You can use the following global expression to define the username in the format of
domain\\username
ordomain@username
:[sssd] [... file truncated ...] re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
Example 5.2. Defining regular expressions a particular domain
To define the regular expressions individually for a particular domain, add
re_expression
to the corresponding domain section of thesssd.conf
file.You can use the following global expression to define the username in the format of
domain\\username
ordomain@username
for the LDAP domain:[domain/LDAP] [... file truncated ...] re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
For more details, see the descriptions for re_expression
in the SPECIAL SECTIONS
and DOMAIN SECTIONS
parts of the sssd.conf(5)
man page.
5.2. Adjusting how SSSD prints full user names
If the use_fully_qualified_names
option is enabled in the /etc/sssd/sssd.conf
file, SSSD prints full user names in the format name@domain
based on the following expansion by default:
%1$s@%2$s
If use_fully_qualified_names
is not set or is explicitly set to false
for trusted domains, it only prints the user name without the domain component.
You can adjust the format in which SSSD prints full user names by adding the full_name_format
option to the /etc/sssd/sssd.conf
file and defining a custom expansion.
Prerequisites
-
root
access
Procedure
-
As
root
, open the/etc/sssd/sssd.conf
file. To define the expansion globally for all domains, add
full_name_format
to the[sssd]
section ofsssd.conf
.[sssd] [... file truncated ...] full_name_format = %1$s@%2$s
In this case the user name is displayed as
user@domain.test
.To define the user name printing format for a particular domain, add
full_name_format
to the corresponding domain section ofsssd.conf
.To configure the expansion for the Active Directory (AD) domain using
%2$s\%1$s
:[domain/ad.domain] [... file truncated ...] full_name_format = %2$s\%1$s
In this case the user name is displayed as
ad.domain\user
.To configure the expansion for the Active Directory (AD) domain using
%3$s\%1$s
:[domain/ad.domain] [... file truncated ...] full_name_format = %3$s\%1$s
In this case the user name is displayed as
AD\user
if the flat domain name of the Active Directory domain is set toAD
.
For more details, see the descriptions for full_name_format
in the SPECIAL SECTIONS
and DOMAIN SECTIONS
parts of the sssd.conf(5)
man page.
SSSD can strip the domain component of the name in some name configurations, which can cause authentication errors. If you set full_name_format
to a non-standard value, you will get a warning prompting you to change it to a standard format.
5.3. Enabling offline authentication
SSSD does not cache user credentials by default. When processing authentication requests, SSSD always contacts the identity provider. If the provider is unavailable, user authentication fails.
To ensure that users can authenticate even when the identity provider is unavailable, you can enable credential caching by setting cache_credentials
to true
in the /etc/sssd/sssd.conf
file.
SSSD never caches passwords in plain text. It stores only a hash of the password.
While credentials are stored as a salted SHA-512 hash, this potentially poses a security risk in case an attacker manages to access the cache file and break a password using a brute force attack. Accessing a cache file requires privileged access, which is the default on RHEL.
Prerequisites
-
root
access
Procedure
-
Open the
/etc/sssd/sssd.conf
file. In a domain section, add the
cache_credentials = true
setting:[domain/your-domain-name] cache_credentials = true
Optional, but recommended: Configure a time limit for how long SSSD allows offline authentication if the identity provider is unavailable:
Configure the PAM service to work with SSSD.
See Configuring user authentication using authselect for more details.
Use the
offline_credentials_expiration
option to specify the time limit.Note that the limit is set in days.
For example, to specify that users are able to authenticate offline for 3 days since the last successful login, use:
[pam] offline_credentials_expiration = 3
Additional resources
-
The
sssd.conf(5)
man page
5.4. Configuring DNS Service Discovery
DNS service discovery enables applications to check the SRV records in a given domain for certain services of a certain type, and then returns any servers that match the required type. If the identity or authentication server is not explicitly defined in the /etc/sssd/sssd.conf
file, SSSD can discover the server dynamically using DNS service discovery.
For example, if sssd.conf
includes the id_provider = ldap
setting, but the ldap_uri
option does not specify any host name or IP address, SSSD uses DNS service discovery to discover the server dynamically.
SSSD cannot dynamically discover backup servers, only the primary server.
Prerequisites
-
root
access
Procedure
-
Open the
/etc/sssd/sssd.conf
file. Set the primary server value to
_srv_
.For an LDAP provider, the primary server is set using the
ldap_uri
option:[domain/your-domain-name] id_provider = ldap ldap_uri = _srv_
Enable service discovery in the password change provider by setting a service type:
[domain/your-domain-name] id_provider = ldap ldap_uri = _srv_ chpass_provider = ldap ldap_chpass_dns_service_name = ldap
-
Optional: By default, the service discovery uses the domain portion of the system host name as the domain name. To use a different DNS domain, specify the domain name by using the
dns_discovery_domain
option. -
Optional: By default, the service discovery scans for the LDAP service type. To use a different service type, specify the type by using the
ldap_dns_service_name
option. -
Optional: By default, SSSD attempts to look up an IPv4 address. If the attempt fails, SSSD attempts to look up an IPv6 address. To customize this behavior, use the
lookup_family_order
option. For every service with which you want to use service discovery, add a DNS record to the DNS server:
_service._protocol._domain TTL priority weight port host_name
Additional resources
- RFC 2782 on DNS service discovery
-
The
sssd.conf(5)
man page
5.5. Configuring simple Access Provider Rules
The simple
access provider allows or denies access based on a list of user names or groups. It enables you to restrict access to specific machines.
For example, you can use the simple
access provider to restrict access to a specific user or group. Other users or groups will not be allowed to log in even if they authenticate successfully against the configured authentication provider.
Prerequisites
-
root
access
Procedure
-
Open the
/etc/sssd/sssd.conf
file. Set the
access_provider
option tosimple
:[domain/your-domain-name] access_provider = simple
Define the access control rules for users.
-
To allow access to users, use the
simple_allow_users
option. To deny access to users, use the
simple_deny_users
option.ImportantIf you deny access to specific users, you automatically allow access to everyone else. Allowing access to specific users is considered safer than denying.
-
To allow access to users, use the
Define the access control rules for groups. Choose one of the following:
-
To allow access to groups, use the
simple_allow_groups
option. To deny access to groups, use the
simple_deny_groups
option.ImportantIf you deny access to specific groups, you automatically allow access to everyone else. Allowing access to specific groups is considered safer than denying.
Example 5.3. Allowing access to specific users and groups
The following example allows access to user1, user2, and members of group1, while denying access to all other users:
[domain/your-domain-name] access_provider = simple simple_allow_users = user1, user2 simple_allow_groups = group1
-
To allow access to groups, use the
Keeping the deny list empty can lead to allowing access to everyone.
Additional resources
-
The
sssd-simple5
man page
5.6. Configuring SSSD to Apply an LDAP Access Filter
When the access_provider
option is set in /etc/sssd/sssd.conf
, SSSD uses the specified access provider to evaluate which users are granted access to the system. If the access provider you are using is an extension of the LDAP provider type, you can also specify an LDAP access control filter that a user must match to be allowed access to the system.
For example, when using the Active Directory (AD) server as the access provider, you can restrict access to the Linux system only to specified AD users. All other users that do not match the specified filter have access denied.
The access filter is applied on the LDAP user entry only. Therefore, using this type of access control on nested groups might not work. To apply access control on nested groups, see Configuring simple
Access Provider Rules.
When using offline caching, SSSD checks if the user’s most recent online login attempt was successful. Users who logged in successfully during the most recent online login will still be able to log in offline, even if they do not match the access filter.
Prerequisites
-
root
access
Procedure
-
Open the
/etc/sssd/sssd.conf
file. In the
[domain]
section, specify the LDAP access control filter.-
For an LDAP access provider, use the
ldap_access_filter
option. See thesssd-ldap(5)
man page for details. For an AD access provider, use the
ad_access_filter
option. See thesssd-ad(5)
man page for details.Example 5.4. Allowing access to specific AD users
For example, to allow access only to AD users who belong to the
admins
user group and have aunixHomeDirectory
attribute set, use:[domain/your-AD-domain-name] access provider = ad [... file truncated ...] ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
-
For an LDAP access provider, use the
SSSD can also check results by the authorizedService
or host
attribute in an entry. In fact, all options MDASH LDAP filter, authorizedService
, and host
MDASH can be evaluated, depending on the user entry and the configuration. The ldap_access_order
parameter lists all access control methods to use, ordered as how they should be evaluated.
[domain/example.com] access_provider = ldap ldap_access_filter = memberOf=cn=allowedusers,ou=Groups,dc=example,dc=com ldap_access_order = filter, host, authorized_service
Additional resources
-
The
sssd-ldap(5)
man page