Este conteúdo não está disponível no idioma selecionado.
Chapter 5. Additional configuration for identity and authentication providers
Extend the System Security Services Daemon (SSSD) functionality beyond basic connectivity by modifying the /etc/sssd/sssd.conf file. Advanced configurations include customizing user name formats, enabling offline access, dynamically discovering servers via DNS, and enforcing granular access control rules.
- 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 Copiar o linkLink copiado para a área de transferência!
The System Security Services Daemon (SSSD) parses user inputs into name and domain components using Python-compatible regular expressions. You can override the default parsing logic by defining custom patterns with the re_expression parameter to match specific organizational naming conventions.
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.
Prerequisites
-
rootaccess
Procedure
-
Open the
/etc/sssd/sssd.conffile. Use the
re_expressionoption to define a custom regular expression.To define regular expressions globally for all domains, add
re_expressionto the[sssd]section of thesssd.conffile.You can use the following global expression to define the username in the format of
<domain>\_<username>_or<domain>@<user_name>:[sssd] [... file truncated ...] re_expression = (?P_<domain>_[\\]*?)\\?(?P_<name>_[\\]+$)To define the regular expressions individually for a particular domain, add
re_expressionto the corresponding domain section of thesssd.conffile.You can use the following global expression to define the username in the format of
<domain>\_<username>_or<domain>@<user_name>for the LDAP domain:[domain/LDAP] [... file truncated ...] re_expression = (?P_<domain>_[\\]*?)\\?(?P_<name>_[\\]+$)
5.2. Adjusting how SSSD prints full user names Copiar o linkLink copiado para a área de transferência!
The System Security Services Daemon (SSSD) displays fully qualified user names, for example, user@domain, by default when use_fully_qualified_names is active. You can customize this output format using the full_name_format option to match legacy requirements, such as displaying domain\user.
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
-
rootaccess
Procedure
-
As
root, open the/etc/sssd/sssd.conffile. To define the expansion globally for all domains, add
full_name_formatto the[sssd]section ofsssd.conf.[sssd] [... file truncated ...] full_name_format = %1$s@%2$sIn 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_formatto 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$sIn 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$sIn this case the user name is displayed as
AD\userif the flat domain name of the Active Directory domain is set toAD.
NoteSSSD can strip the domain component of the name in some name configurations, which can cause authentication errors. If you set
full_name_formatto a non-standard value, you will get a warning prompting you to change it to a standard format.
5.3. Enabling offline authentication Copiar o linkLink copiado para a área de transferência!
The System Security Services Daemon (SSSD) requires credential caching to enable authentication when the identity provider is unreachable. Enabling cache_credentials allows users to log in using locally stored hashes of their passwords during network outages, ensuring business continuity.
You can enable credential caching by setting cache_credentials to true in the /etc/sssd/sssd.conf file. Cached credentials refer to passwords and the first authentication factor if two-factor authentication is used. Note that for passkey and smart card authentication, you do not need to set cache_credentials to true or set any additional configuration; they are expected to work offline as long as a successful online authentication is recorded in the cache.
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
-
rootaccess
Procedure
-
Open the
/etc/sssd/sssd.conffile. In a domain section, add the
cache_credentials = truesetting:[domain/<domain_name>] cache_credentials = trueOptional, 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.
Use the
offline_credentials_expirationoption 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
5.4. Configuring DNS Service Discovery Copiar o linkLink copiado para a área de transferência!
DNS service discovery allows the System Security Services Daemon (SSSD) to automatically locate identity servers by using SRV records. This configuration removes the need to hardcode server IP addresses, enabling dynamic failover and load balancing by querying the DNS infrastructure.
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
-
rootaccess
Procedure
-
Open the
/etc/sssd/sssd.conffile. Set the primary server value to
_srv_.For an LDAP provider, the primary server is set using the
ldap_urioption:[domain/<ldap_domain_name>] id_provider = ldap ldap_uri = _srv_Enable service discovery in the password change provider by setting a service type:
[domain/<ldap_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_domainoption. -
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_nameoption. -
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_orderoption. For every service with which you want to use service discovery, add a DNS record to the DNS server:
_<service_name>.<protocol>.<domain_name> <TTL> <priority> <weight> <port_number> <hostname>_
5.5. Configuring simple Access Provider Rules Copiar o linkLink copiado para a área de transferência!
The simple access provider restricts system login access based on explicit lists of users or groups. Configure allow or deny rules directly in sssd.conf to enforce security policies locally without modifying the remote backend directory.
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
-
rootaccess
Procedure
-
Open the
/etc/sssd/sssd.conffile. Set the
access_provideroption tosimple:[domain/<domain_name>] access_provider = simpleDefine the access control rules for users.
-
To allow access to users, use the
simple_allow_usersoption. -
To deny access to users, use the
simple_deny_usersoption.
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_groupsoption. To deny access to groups, use the
simple_deny_groupsoption.ImportantIf you deny access to specific groups, you automatically allow access to everyone else. Allowing access to specific groups is considered safer than denying.
For example, you can grant access to
alice,bob, and members of theengineersgroup, while denying access to all other users:[domain/<domain_name>] access_provider = simple simple_allow_users = alice, bob simple_allow_groups = engineersImportantKeeping the deny list empty can lead to allowing access to everyone.
NoteIf you are adding a trusted AD user to the
simple_allow_userslist, ensure that you use the fully qualified domain name (FQDN) format, for example, aduser@ad.example.com. As short names in different domains can be the same, this prevents issues with the access control configuration.-
To allow access to groups, use the
5.6. Configuring SSSD to apply an LDAP access filter Copiar o linkLink copiado para a área de transferência!
LDAP access filters refine authorization by requiring specific attribute matches in the directory entry. SSSD evaluates these filters during login, granting access only if the user object satisfies the defined criteria, such as membership in a specific group.
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
-
rootaccess
Procedure
-
Open the
/etc/sssd/sssd.conffile. In the
[domain]section, specify the access control filter.-
For an LDAP, use the
ldap_access_filteroption. For an AD, use the
ad_access_filteroption. Additionally, you must disable the GPO-based access control by setting thead_gpo_access_controloption todisabled.For example, to allow access only to AD users who belong to the
adminsuser group and have aunixHomeDirectoryattribute set, use:[domain/<ad_domain_name>] access provider = ad [... file truncated ...] ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*)) ad_gpo_access_control = disabledSSSD can also check results by the
authorizedServiceorhostattribute in an entry. In fact, all options MDASH LDAP filter,authorizedService, andhostMDASH can be evaluated, depending on the user entry and the configuration. Theldap_access_orderparameter 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
-
For an LDAP, use the