SupportConsoleDevelopersStart a trialContact

7.4. Additional Configuration for Identity and Authentication Providers

7.4.1. Adjusting User Name Formats

7.4.1.1. Defining the Regular Expression for Parsing 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>[^@]*$)

Note

For Identity Management and Active Directory providers, the default user name format is user_name@domain_name or NetBIOS_name\user_name.
To adjust how SSSD interprets full user names:
  1. Open the /etc/sssd/sssd.conf file.
  2. Use the re_expression option to define a custom regular expression.
    1. To define the regular expressions globally for all domains, add re_expression to the [sssd] section of sssd.conf.
    2. To define the regular expressions individually for a particular domain, add re_expression to the corresponding domain section of sssd.conf.
For example, to configure a regular expression for the LDAP domain: 
[domain/LDAP]
[... file truncated ...]
re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)
For details, see the descriptions for re_expression in the SPECIAL SECTIONS and DOMAIN SECTIONS parts of the sssd.conf(5) man page.

7.4.1.2. Defining 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

Note

If use_fully_qualified_names is not set or is explicitly set to false for trusted domains, only the user name is printed, without the domain component.
To adjust the format in which SSSD prints full user names:
  1. Open the /etc/sssd/sssd.conf file.
  2. Use the full_name_format option to define the expansion for the full user name format:
    1. To define the expansion globally for all domains, add full_name_format to the [sssd] section of sssd.conf.
    2. To define the expansion individually for a particular domain, add full_name_format to the corresponding domain section of sssd.conf.
For details, see the descriptions for full_name_format in the SPECIAL SECTIONS and DOMAIN SECTIONS parts of the sssd.conf(5) man page.
In some name configurations, SSSD could strip the domain component of the name, which can cause authentication errors. Because of this, if you set full_name_format to a non-standard value, a warning will prompt you to change it to a more standard format.

7.4.2. 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.

Important

SSSD never caches passwords in plain text. It stores only a hash of the password.
To ensure that users can authenticate even when the identity provider is unavailable, enable credential caching:
  1. Open the /etc/sssd/sssd.conf file.
  2. In a domain section, add the cache_credentials = true setting: 
    [domain/domain_name]
cache_credentials = true
  3. Optional, but recommended. Configure a time limit for how long SSSD allows offline authentication if the identity provider is unavailable.
    1. Configure the PAM service to work with SSSD. See Section 7.5.2, “Configuring Services: PAM”.
    2. Use the offline_credentials_expiration option to specify the time limit. For example, to specify that users are able to authenticate offline for 3 days since the last successful login: 
      [pam]
offline_credentials_expiration = 3
For details on offline_credentials_expiration, see the sssd.conf(5) man page.

7.4.3. Configuring DNS Service Discovery

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 [1].
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.

Note

SSSD cannot dynamically discover backup servers, only the primary server.

Configuring SSSD for DNS Service Discovery

  1. Open the /etc/sssd/sssd.conf file.
  2. Set the primary server value to _srv_. For an LDAP provider, the primary server is set using the ldap_uri option: 
    [domain/domain_name]
id_provider = ldap
ldap_uri = _srv_
  3. Enable service discovery in the password change provider by setting a service type: 
    [domain/domain_name]
id_provider = ldap
ldap_uri = _srv_

chpass_provider = ldap
ldap_chpass_dns_service_name = ldap
  4. 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 in the dns_discovery_domain option.
  5. Optional. By default, the service discovery scans for the LDAP service type. To use a different service type, specify the type in the ldap_dns_service_name option.
  6. 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. See the sssd.conf(5) man page for details.
  7. 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

7.4.4. Defining Access Control Using the simple Access Provider

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, on company laptops, you can use the simple access provider to restrict access to only a specific user or a specific group. Other users or groups will not be allowed to log in even if they authenticate successfully against the configured authentication provider.

Configuring simple Access Provider Rules

  1. Open the /etc/sssd/sssd.conf file.
  2. Set the access_provider option to simple: 
    [domain/domain_name]
access_provider = simple
  3. Define the access control rules for users. Choose one of the following:
    1. To allow access to users, use the simple_allow_users option.
    2. To deny access to users, use the simple_deny_users option.

      Important

      Allowing access to specific users is considered safer than denying. If you deny access to specific users, you automatically allow access to everyone else.
  4. Define the access control rules for groups. Choose one of the following:
    1. To allow access to groups, use the simple_allow_groups option.
    2. To deny access to groups, use the simple_deny_groups option.

      Important

      Allowing access to specific groups is considered safer than denying. If you deny access to specific groups, you automatically allow access to everyone else.
The following example allows access to user1, user2, and members of group1, while denying access to all other users. 
[domain/domain_name]
access_provider = simple
simple_allow_users = user1, user2
simple_allow_groups = group1
For details, see the sssd-simple(5) man page.

7.4.5. Defining Access Control Using the 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 in order to be allowed access to the system.
For example, when using an 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 will be denied access.

Note

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 Section 7.4.4, “Defining Access Control Using the simple Access Provider”.

Important

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.

Configuring SSSD to Apply an LDAP Access Filter

  1. Open the /etc/sssd/sssd.conf file.
  2. In the [domain] section, specify the LDAP access control filter.
    • For an LDAP access provider, use the ldap_access_filter option. See the sssd-ldap(5) man page for details.
    • For an AD access provider, use the ad_access_filter option. See the sssd-ad(5) man page for details.
    For example, to allow access only to AD users who belong to the admins user group and have a unixHomeDirectory attribute set: 
    [domain/AD_domain_name]
access provider = ad
[... file truncated ...]
ad_access_filter = (&(memberOf=cn=admins,ou=groups,dc=example,dc=com)(unixHomeDirectory=*))
SSSD can also check results by the authorizedService or host attribute in an entry. In fact, all options — LDAP filter, authorizedService, and host — can be evaluated, depending on the user entry and the configuration. The ldap_access_order parameter lists all access control methods to use, in order of 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
The attributes in the user entry to use to evaluate authorized services or allowed hosts can be customized. Additional access control parameters are listed in the sssd-ldap(5) man page.

[1] 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. DNS service discovery is defined in RFC 2782.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.