Verification Steps

1. Verify sss entries for SSSD are present in /etc/nsswitch.conf:

   passwd:     sss files
   group:      sss files
   netgroup:   sss files
   automount:  sss files
   services:   sss files
   ...

2. Review the contents of the /etc/pam.d/system-auth file for pam_sss.so entries:

   # Generated by authselect on Tue Sep 11 22:59:06 2018
   # Do not modify this file manually.
   
   auth        required        pam_env.so
   auth        required        pam_faildelay.so delay=2000000
   auth        [default=1 ignore=ignore success=ok]    pam_succeed_if.so uid >= 1000 quiet
   auth        [default=1 ignore=ignore success=ok]    pam_localuser.so
   auth        sufficient      pam_unix.so nullok try_first_pass
   auth        requisite       pam_succeed_if.so uid >= 1000 quiet_success
   auth        sufficient      pam_sss.so forward_pass
   auth        required        pam_deny.so
   
   account     required        pam_unix.so
   account     sufficient      pam_localuser.so
   ...

Procedure

1. Select an authselect profile, for example:

   # authselect select sssd

2. Edit the /etc/authselect/user-nsswitch.conf file with your desired changes.

3. Apply the changes from the /etc/authselect/user-nsswitch.conf file:

   # authselect apply-changes

Procedure

1. Create your custom profile by using the authselect create-profile command. For example, to create a custom profile called user-profile based on the ready-made sssd profile but one in which you can configure the items in the /etc/nsswitch.conf file yourself:

   # authselect create-profile user-profile -b sssd --symlink-meta --symlink-pam
   New profile was created at /etc/authselect/custom/user-profile

   Warning

   If you are planning to modify /etc/authselect/custom/user-profile/{password-auth,system-auth,fingerprint-auth,smartcard-auth,postlogin}, then enter the command above without the --symlink-pam option. This is to ensure that the modification persists during the upgrade of authselect-libs.

   Including the --symlink-pam option in the command means that PAM templates will be symbolic links to the origin profile files instead of their copy; including the --symlink-meta option means that meta files, such as README and REQUIREMENTS will be symbolic links to the origin profile files instead of their copy. This ensures that all future updates to the PAM templates and meta files in the original profile will be reflected in your custom profile, too.

   The command creates a copy of the /etc/nsswitch.conf file in the /etc/authselect/custom/user-profile/ directory.

2. Configure the /etc/authselect/custom/user-profile/nsswitch.conf file.

3. Select the custom profile by running the authselect select command, and adding custom/name_of_the_profile as a parameter. For example, to select the user-profile profile:

   # authselect select custom/user-profile

   Selecting the user-profile profile for your machine means that if the sssd profile is subsequently updated by Red Hat, you will benefit from all the updates with the exception of updates made to the /etc/nsswitch.conf file.

   Example 1.1. Creating a profile

   The following procedure shows how to create a profile based on the sssd profile which only consults the local static table lookup for hostnames in the /etc/hosts file, not in the dns or myhostname databases.

   1. Edit the /etc/nsswitch.conf file by editing the following line:

      hosts:      files

   2. Create a custom profile based on sssd that excludes changes to /etc/nsswitch.conf:

      # authselect create-profile user-profile -b sssd --symlink-meta --symlink-pam

   3. Select the profile:

      # authselect select custom/user-profile

   4. Optionally, check that selecting the custom profile has

      • created the /etc/pam.d/system-auth file according to the chosen sssd profile

      • left the configuration in the /etc/nsswitch.conf unchanged:

        hosts:      files

        Note

        Running authselect select sssd would, in contrast, result in hosts: files dns myhostname

1. It connects the client to a remote provider to retrieve identity and authentication information.
2. It uses the obtained authentication information to create a local cache of users and credentials on the client.

1. The primary /etc/sssd/sssd.conf file
2. Other *.conf files in /etc/sssd/conf.d/, in alphabetical order

Procedure

1. Install the requisite packages:

   # dnf -y install openldap-clients sssd sssd-ldap oddjob-mkhomedir

2. Switch the authentication provider to sssd:

   # authselect select sssd with-mkhomedir

3. Copy the core-dirsrv.ca.pem file containing the root CA signing certificate chain from the Certificate Authority that issued the OpenLDAP server’s SSL/TLS certificate into the /etc/openldap/certs folder.

   # cp core-dirsrv.ca.pem /etc/openldap/certs

4. Add the URL and suffix of your LDAP server to the /etc/openldap/ldap.conf file:

   URI ldap://ldap-server.example.com/
   BASE dc=example,dc=com

5. In the /etc/openldap/ldap.conf file, add a line pointing the TLS_CACERT parameter to /etc/openldap/certs/core-dirsrv.ca.pem:

   # When no CA certificates are specified the Shared System Certificates
   # are in use. In order to have these available along with the ones specified
   # by TLS_CACERTDIR one has to include them explicitly:
   TLS_CACERT /etc/openldap/certs/core-dirsrv.ca.pem

6. In the /etc/sssd/sssd.conf file, add your environment values to the ldap_uri and ldap_search_base parameters and set the ldap_id_use_start_tls to True:

   [domain/default]
   id_provider = ldap
   autofs_provider = ldap
   auth_provider = ldap
   chpass_provider = ldap
   ldap_uri = ldap://ldap-server.example.com/
   ldap_search_base = dc=example,dc=com
   ldap_id_use_start_tls = True
   cache_credentials = True
   ldap_tls_cacertdir = /etc/openldap/certs
   ldap_tls_reqcert = allow
   
   [sssd]
   services = nss, pam, autofs
   domains = default
   
   [nss]
   homedir_substring = /home
   …

7. In /etc/sssd/sssd.conf, specify the TLS authentication requirement by modifying the ldap_tls_cacert and ldap_tls_reqcert values in the [domain] section:

   …
   cache_credentials = True
   ldap_tls_cacert = /etc/openldap/certs/core-dirsrv.ca.pem
   ldap_tls_reqcert = hard
   …

8. Change the permissions on the /etc/sssd/sssd.conf file:

   # chmod 600 /etc/sssd/sssd.conf

9. Restart and enable the SSSD service and the oddjobd daemon:

   # systemctl restart sssd oddjobd
   # systemctl enable sssd oddjobd

10. (Optional) If your LDAP server uses the deprecated TLS 1.0 or TLS 1.1 protocols, switch the system-wide cryptographic policy on the client system to the LEGACY level to allow RHEL to communicate using these protocols:

    # update-crypto-policies --set LEGACY

    For more details, see the Strong crypto defaults in RHEL 8 and deprecation of weak crypto algorithms Knowledgebase article on the Red Hat Customer Portal and the update-crypto-policies(8) man page.

Procedure

1. Open the /etc/sssd/sssd.conf file.

2. Use the re_expression option to define a custom regular expression.

   Example 4.1. Defining regular expressions globally

   To define the regular expressions globally for all domains, add re_expression to the [sssd] section of the sssd.conf file.

   You can use the following global expression to define the username in the format of domain\\username or domain@username:

   [sssd]
   [... file truncated ...]
   re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)

   Example 4.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 the sssd.conf file.

   You can use the following global expression to define the username in the format of domain\\username or domain@username for the LDAP domain:

   [domain/LDAP]
   [... file truncated ...]
   re_expression = (?P<domain>[^\\]*?)\\?(?P<name>[^\\]+$)

Procedure

1. As root, open the /etc/sssd/sssd.conf file.

2. To define the expansion globally for all domains, add full_name_format to the [sssd] section of sssd.conf.

   [sssd]
   [... file truncated ...]
   full_name_format = %1$s@%2$s

   In this case the user name is displayed as user@domain.test.

3. To define the user name printing format for a particular domain, add full_name_format to the corresponding domain section of sssd.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 to AD.

Procedure

1. Open the /etc/sssd/sssd.conf file.

2. In a domain section, add the cache_credentials = true setting:

   [domain/your-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 Configuring user authentication using authselect for more details.

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

Procedure

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/your-domain-name]
   id_provider = ldap
   ldap_uri = _srv_

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

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 by using 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 by using 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.

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

Procedure

1. Open the /etc/sssd/sssd.conf file.

2. Set the access_provider option to simple:

   [domain/your-domain-name]
   access_provider = simple

3. Define the access control rules for users.

   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

      If you deny access to specific users, you automatically allow access to everyone else. Allowing access to specific users is considered safer than denying.

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

      If you deny access to specific groups, you automatically allow access to everyone else. Allowing access to specific groups is considered safer than denying.

      Example 4.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

Procedure

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.

     Example 4.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 a unixHomeDirectory 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=*))

Procedure

1. Display the current information for the user:

   # id username

   Replace username with the name of the user.

2. Add the secondary username:

   # sss_override user-add username -n secondary-username

   Replace username with the name of the user and replace secondary-username with the new username.

3. After creating the first override using the sss_override user-add command, restart SSSD for the changes to take effect:

   # systemctl restart sssd

Procedure

1. Display the current UID of the user:

   # id -u user-name

   Replace user-name with the name of the user.

2. Override the UID of the user’s account:

   # sss_override user-add user-name -u new-UID

   Replace user-name with the name of the user and replace new-UID with the new UID number.

3. Expire the in-memory cache:

   # sss_cache --users

4. After creating the first override using the sss_override user-add command, restart SSSD for the changes to take effect:

   # systemctl restart sssd

Procedure

1. Display the current GID of the user:

   # id -g user-name

   Replace user-name with the name of the user.

2. Override the GID of the user’s account:

   # sss_override user-add user-name -g new-GID

   Replace user-name with the name of the user and replace new-GID with the new GID number.

3. Expire the in-memory cache:

   # sss_cache --users

4. After creating the first override using the sss_override user-add command, restart SSSD for the changes to take effect:

   # systemctl restart sssd

Procedure

1. Display the current home directory of the user:

   # getent passwd user-name
   user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash

   Replace user-name with the name of the user.

2. Override the home directory of the user:

   # sss_override user-add user-name -h new-home-directory

   Replace user-name with the name of the user and replace new-home-directory with the new home directory.

3. Restart SSSD for the changes to take effect:

   # systemctl restart sssd

Procedure

1. Display the current shell of the user:

   # getent passwd user-name
   user-name:x:XXXX:XXXX::/home/home-directory:/bin/bash

   Replace user-name with the name of the user.

2. Override the shell of the user:

   # sss_override user-add user-name -s new-shell

   Replace user-name with the name of the user and replace new-shell with the new shell.

3. Restart SSSD for the changes to take effect:

   # systemctl restart sssd

Procedure

1. To display help for the sssctl command, enter:

   [root@client1 ~]# sssctl --help
   ....

2. To display a list of available domains, enter:

Procedure

1. To display help for the sssctl command, enter:

   [root@client1 ~]# sssctl --help

2. To display user data for a particular domain, enter:

   [root@client1 ~]# sssctl domain-status idm.example.com
   Online status: Online
   
   Active servers:
   IPA: server.idm.example.com
   
   Discovered IPA servers:
   - server.idm.example.com

Procedure

1. Configure SSSD to access the required domain or domains. Define the domains against which SSSD can authenticate in the domains option in the /etc/sssd/sssd.conf file:

   [sssd]
   domains = domain1, domain2, domain3

2. Specify the domain or domains to which a PAM service can authenticate by setting the domains option in the PAM configuration file. For example:

   auth        sufficient    pam_sss.so forward_pass domains=domain1
   account     [default=bad success=ok user_unknown=ignore] pam_sss.so
   password    sufficient    pam_sss.so use_authtok

   In this example, you allow the PAM service to authenticate against domain1 only.

Procedure

1. Back up the current authentication configuration:

   # authselect apply-changes -b --backup=ldap-configuration-backup

2. Install SSSD packages:

   # yum install sssd-ldap sssd-ad sssd-client \
                 sssd-common sssd-common-pac \
                 sssd-krb5 sssd-krb5-common

3. Stop and disable the nslcd and nscd services:

   # systemctl stop nslcd nscd
   # systemctl disable nslcd nscd

4. Configure authentication with SSSD:

   # authselect select sssd with-mkhomedir --force

5. Set the necessary ownership and permissions for the SSSD configuration file:

   # chown root:root /etc/sssd/sssd.conf
   # chmod 600 /etc/sssd/sssd.conf

6. Open the /etc/sssd/sssd.conf file for editing.

7. Enter the following configuration, replacing values such as example.com and dc=example,dc=com with values that are appropriate for your environment:

   [sssd]
   config_file_version = 2
   services = nss, pam
   domains = EXAMPLE.COM
   debug_level = 6
   
   [domain/EXAMPLE.COM]
   id_provider = ldap
   auth_provider = ldap
   ldap_uri = ldap://server.example.com/
   ldap_search_base = dc=example,dc=com
   ldap_default_bind_dn = CN=binddn,DC=example,DC=com
   ldap_default_authtok_type = password
   ldap_default_authtok = <bind_account_password>
   cache_credentials = True

   Note

   You might need to specify the LDAP schema in your SSSD configuration:

   If you are using the RFC-2307bis schema in your directory server, add the following line to the [domain/EXAMPLE.COM] section:

   ldap_schema = rfc2307bis

   If you are using a Microsoft Active Directory server, add the following line to the [domain/EXAMPLE.COM] section to enable LDAP-based authentication:

   ldap_schema = ad

   If you need Kerberos authentication, Red Hat recommends joining the RHEL client to your AD domain with the realm command, which automatically configures the SSSD service.

8. Enable and start the SSSD service:

   # systemctl enable sssd
   # systemctl start sssd

Verification steps

1. Ensure you can retrieve information about your LDAP users:

   # id ldapuser
    uid=100424(ldapuser) gid=100424(ldapuser) groups=100424(ldapuser)
   
   # getent passwd ldapuser
   ldapuser:*: 100424: 100424:User, LDAP:/home/ldapuser:/bin/bash

2. Ensure you can log in as an LDAP user:

   # ssh -l ldapuser localhost
   ldapuser@localhost's password:
   Last login: Tue Dec 07 19:34:35 2021 from localhost
   -sh-4.2$

1. The getent command triggers the getpwnam call from the libc library.
2. The libc library references the /etc/nsswitch.conf configuration file to check which service is responsible for providing user information, and discovers the entry sss for the SSSD service.
3. The libc library opens the nss_sss module.
4. The nss_sss module checks the memory-mapped cache for the user information. If the data is present in the cache, the nss_sss module returns it.
5. If the user information is not in the memory-mapped cache, the request is passed to the SSSD sssd_nss responder process.
6. The SSSD service checks its cache. If the data is present in the cache and valid, the sssd_nss responder reads the data from the cache and returns it to the application.
7. If the data is not present in the cache or it is expired, the sssd_nss responder queries the appropriate back-end process and waits for a reply. The SSSD service uses the IPA backend in an IdM environment, enabled by the setting id_provider=ipa in the sssd.conf configuration file.
8. The sssd_be back-end process connects to the IdM server and requests the information from the IdM LDAP Directory Server.
9. The SSSD back-end on the IdM server responds to the SSSD back-end process on the IdM client.
10. The SSSD back-end on the client stores the resulting data in the SSSD cache and alerts the responder process that the cache has been updated.
11. The sssd_nss front-end responder process retrieves the information from the SSSD cache.
12. The sssd_nss responder sends the user information to the nss_sss responder, completing the request.
13. The libc library returns the user information to the application that requested it.

1. The IdM client looks to its local SSSD cache for AD user information.
2. If the IdM client does not have the user information, or the information is stale, the SSSD service on the client contacts the extdom_extop plugin on the IdM server to perform an LDAP extended operation and requests the information.
3. The SSSD service on the IdM server looks for the AD user information in its local cache.
4. If the IdM server does not have the user information in its SSSD cache, or its information is stale, it performs an LDAP search to request the user information from an AD Domain Controller.
5. The SSSD service on the IdM server receives the AD user information from the AD domain controller and stores it in its cache.
6. The extdom_extop plugin receives the information from the SSSD service on the IdM server, which completes the LDAP extended operation.
7. The SSSD service on the IdM client receives the AD user information from the LDAP extended operation.
8. The IdM client stores the AD user information in its SSSD cache and returns the information to the application that requested it.

1. The authentication attempt with the ssh command triggers the libpam library.

2. The libpam library references the PAM file in the /etc/pam.d/ directory that corresponds to the service requesting the authentication attempt. In this example involving authenticating via the SSH service on the local host, the libpam library checks the /etc/pam.d/system-auth configuration file and discovers the pam_sss.so entry for the SSSD PAM:

   auth    sufficient    pam_sss.so

3. To determine which authentication methods are available, the libpam library opens the pam_sss module and sends an SSS_PAM_PREAUTH request to the sssd_pam PAM responder of the SSSD service.
4. If smart card authentication is configured, the SSSD service spawns a temporary p11_child process to check for a smart card and retrieve certificates from it.
5. If smart card authentication is configured for the user, the sssd_pam responder attempts to match the certificate from the smart card with the user. The sssd_pam responder also performs a search for the groups that the user belongs to, since group membership might affect access control.
6. The sssd_pam responder sends an SSS_PAM_PREAUTH request to the sssd_be back-end responder to see which authentication methods the server supports, such as passwords or 2-factor authentication. In an IdM environment, where the SSSD service uses the IPA responder, the default authentication method is Kerberos. For this example, the user authenticates with a simple Kerberos password.
7. The sssd_be responder spawns a temporary krb5_child process.
8. The krb5_child process contacts the KDC on the IdM server and checks for available authentication methods.

9. The KDC responds to the request:

   1. The krb5_child process evaluates the reply and sends the results back to the sssd_be backend process.
   2. The sssd_be backend process receives the result.
   3. The sssd_pam responder receives the result.
   4. The pam_sss module receives the result.
10. If password authentication is configured for the user, the pam_sss module prompts the user for their password. If smart card authentication is configured, the pam_sss module prompts the user for their smart card PIN.

11. The module sends an SSS_PAM_AUTHENTICATE request with the user name and password, which travels to:

    1. The sssd_pam responder.
    2. The sssd_be back-end process.
12. The sssd_be process spawns a temporary krb5_child process to contact the KDC.
13. The krb5_child process attempts to retrieve a Kerberos Ticket Granting Ticket (TGT) from the KDC with the user name and password the user provided.
14. The krb5_child process receives the result of the authentication attempt.

15. The krb5_child process:

    1. Stores the TGT in a credential cache.
    2. Returns the authentication result to the sssd_be back-end process.

16. The authentication result travels from the sssd_be process to:

    1. The sssd_pam responder.
    2. The pam_sss module.
17. The pam_sss module sets an environment variable with the location of the user’s TGT so other applications can reference it.

Procedure

1. Verify that the SSSD service and its processes are running.

   [root@client ~]# pstree -a | grep sssd
     |-sssd -i --logger=files
     |   |-sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
     |   |-sssd_be --domain example.com --uid 0 --gid 0 --logger=files
     |   |-sssd_ifp --uid 0 --gid 0 --logger=files
     |   |-sssd_nss --uid 0 --gid 0 --logger=files
     |   |-sssd_pac --uid 0 --gid 0 --logger=files
     |   |-sssd_pam --uid 0 --gid 0 --logger=files
     |   |-sssd_ssh --uid 0 --gid 0 --logger=files
     |   `-sssd_sudo --uid 0 --gid 0 --logger=files
     |-sssd_kcm --uid 0 --gid 0 --logger=files

2. Verify that the client can contact the user database server via the IP address.

   [user@client ~]$ ping <IP_address_of_the_database_server>

   If this step fails, check that your network and firewall settings allow direct communication between IdM clients and servers. See Using and configuring firewalld.

3. Verify that the client can discover and contact the IdM LDAP server (for IdM users) or AD domain controller (for AD users) via the fully qualified host name.

   [user@client ~]$ dig -t SRV _ldap._tcp.example.com @<name_server>
   [user@client ~]$ ping <fully_qualified_host_name_of_the_server>

   If this step fails, check your Dynamic Name Service (DNS) settings, including the /etc/resolv.conf file. See Configuring the order of DNS servers.

   Note

   By default, the SSSD service attempts to automatically discover LDAP servers and AD DCs through DNS service (SRV) records. Alternatively, you can restrict the SSSD service to use specific servers by setting the following options in the sssd.conf configuration file:

   • ipa_server = <fully_qualified_host_name_of_the_server>
   • ad_server = <fully_qualified_host_name_of_the_server>
   • ldap_uri = <fully_qualified_host_name_of_the_server>

   If you use these options, verify you can contact the servers listed in them.

4. Verify that the client can authenticate to the LDAP server and retrieve user information with ldapsearch commands.

   1. If your LDAP server is an IdM server, like server.example.com, retrieve a Kerberos ticket for the host and perform the database search authenticating with the host Kerberos principal:

      [user@client ~]$ kinit -k 'host/client.example.com@EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.example.com -b “dc=example,dc=com” uid=<user_name>

   2. If your LDAP server is an Active Directory (AD) Domain Controller (DC), like server.ad.example.com, retrieve a Kerberos ticket for the host and perform the database search authenticating with the host Kerberos principal:

      [user@client ~]$ kinit -k 'CLIENT$@AD.EXAMPLE.COM'
      [user@client ~]$ ldapsearch -LLL -Y GSSAPI -h server.ad.example.com -b “dc=example,dc=com” sAMAccountname=<user_name>

   3. If your LDAP server is a plain LDAP server, and you have set the ldap_default_bind_dn and ldap_default_authtok options in the sssd.conf file, authenticate as the same ldap_default_bind_dn account:

      [user@client ~]$ ldapsearch -xLLL -D "cn=ldap_default_bind_dn_value" -W -h ldapserver.example.com -b “dc=example,dc=com” uid=<user_name>

   If this step fails, verify that your database settings allow your host to search the LDAP server.

5. Since the SSSD service uses Kerberos encryption, verify you can obtain a Kerberos ticket as the user that is unable to log in.

   1. If your LDAP server is an IdM server:

      [user@client ~]$ kinit <user_name>

   2. If LDAP server database is an AD server:

      [user@client ~]$ kinit <user_name@AD.EXAMPLE.COM>

   If this step fails, verify that your Kerberos server is operating properly, all servers have their times synchronized, and that the user account is not locked.

6. Verify you can retrieve user information about the command line.

   [user@client ~]$ getent passwd <user_name>
   [user@client ~]$ id <user_name>

   If this step fails, verify that the SSSD service on the client can receive information from the user database:

   1. Review errors in the /var/log/messages log file.
   2. Enable detailed logging in the SSSD service, collect debugging logs, and review the logs for indications to the source of the issue.
   3. (Optional) Open a Red Hat Technical Support case and provide the troubleshooting information you have gathered.

7. If you are allowed to run sudo on the host, use the sssctl utility to verify the user is allowed to log in.

   [user@client ~]$ sudo sssctl user-checks -a auth -s ssh <user_name>

   If this step fails, verify your authorization settings, such as your PAM configuration, IdM HBAC rules, and IdM RBAC rules:

   1. Ensure that the user’s UID is equal to or higher than UID_MIN, which is defined in the /etc/login.defs file.
   2. Review authorization errors in the /var/log/secure and /var/log/messages log files.
   3. Enable detailed logging in the SSSD service, collect debugging logs, and review the logs for indications to the source of the issue.
   4. (Optional) Open a Red Hat Technical Support case and provide the troubleshooting information you have gathered.

Procedure

1. Open the /etc/sssd/sssd.conf file in a text editor.

2. Add the debug_level option to every section of the file, and set the debug level to the verbosity of your choice.

   [domain/example.com]
   debug_level = 6
   id_provider = ipa
   ...
   
   [sssd]
   debug_level = 6
   services = nss, pam, ifp, ssh, sudo
   domains = example.com
   
   [nss]
   debug_level = 6
   
   [pam]
   debug_level = 6
   
   [sudo]
   debug_level = 6
   
   [ssh]
   debug_level = 6
   
   [pac]
   debug_level = 6
   
   [ifp]
   debug_level = 6

3. Save and close the sssd.conf file.

4. Restart the SSSD service to load the new configuration settings.

   [root@server ~]# systemctl restart sssd

Procedure

1. Enable detailed SSSD debug logging on the IdM server.

   [root@server ~]# sssctl debug-level 6

2. Invalidate objects in the SSSD cache for the user that is experiencing authentication issues, so you do not bypass the LDAP server and retrieve information SSSD has already cached.

   [root@server ~]# sssctl cache-expire -u idmuser

3. Minimize the troubleshooting dataset by removing older SSSD logs.

   [root@server ~]# sssctl logs-remove

4. Attempt to switch to the user experiencing authentication problems, while gathering timestamps before and after the attempt. These timestamps further narrow the scope of the dataset.

   [root@server sssd]# date; su idmuser; date
   Mon Mar 29 15:33:48 EDT 2021
   su: user idmuser does not exist
   Mon Mar 29 15:33:49 EDT 2021

5. (Optional) Lower the debug level if you do not wish to continue gathering detailed SSSD logs.

   [root@server ~]# sssctl debug-level 2

6. Review SSSD logs for information about the failed request. For example, reviewing the /var/log/sssd/sssd_example.com.log file shows that the SSSD service did not find the user in the cn=accounts,dc=example,dc=com LDAP subtree. This might indicate that the user does not exist, or exists in another location.

   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [dp_get_account_info_send] (0x0200): Got request for [0x1][BE_REQ_USER][name=idmuser@example.com]
   ...
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=idmuser)(objectclass=posixAccount)(uid=)(&(uidNumber=)(!(uidNumber=0))))][cn=accounts,dc=example,dc=com].
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sdap_search_user_process] (0x0400): Search for users, returned 0 results.
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_delete_user] (0x0400): Error: 2 (No such file or directory)
   (Mon Mar 29 15:33:48 2021) [sssd[be[example.com]]] [sysdb_search_by_name] (0x0400): No such entry
   (Mon Mar 29 15:33:49 2021) [sssd[be[example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): Object not found, ending request

7. If you are unable to determine the cause of the authentication issue:

   1. Collect the SSSD logs you recently generated.

      [root@server ~]# sssctl logs-fetch sssd-logs-Mar29.tar

   2. Open a Red Hat Technical Support case and provide:

      1. The SSSD logs: sssd-logs-Mar29.tar

      2. The console output, including the time stamps and user name, of the request that corresponds to the logs:

         [root@server sssd]# date; id idmuser; date
         Mon Mar 29 15:33:48 EDT 2021
         id: ‘idmuser’: no such user
         Mon Mar 29 15:33:49 EDT 2021

Procedure

1. On the client: Open the /etc/sssd/sssd.conf file in a text editor.

2. On the client: Add the ipa_server option to the [domain] section of the file and set it to an IdM server. This avoids the IdM client autodiscovering other IdM servers, thus limiting this test to just one client and one server.

   [domain/example.com]
   ipa_server = server.example.com
   ...

3. On the client: Save and close the sssd.conf file.

4. On the client: Restart the SSSD service to load the configuration changes.

   [root@client ~]# systemctl restart sssd

5. On the server and client: Enable detailed SSSD debug logging.

   [root@server ~]# sssctl debug-level 6

   [root@client ~]# sssctl debug-level 6

6. On the server and client: Invalidate objects in the SSSD cache for the user experiencing authentication issues, so you do not bypass the LDAP database and retrieve information SSSD has already cached.

   [root@server ~]# sssctl cache-expire -u idmuser

   [root@client ~]# sssctl cache-expire -u idmuser

7. On the server and client: Minimize the troubleshooting dataset by removing older SSSD logs.

   [root@server ~]# sssctl logs-remove

   [root@server ~]# sssctl logs-remove

8. On the client: Attempt to switch to the user experiencing authentication problems while gathering timestamps before and after the attempt. These timestamps further narrow the scope of the dataset.

   [root@client sssd]# date; su idmuser; date
   Mon Mar 29 16:20:13 EDT 2021
   su: user idmuser does not exist
   Mon Mar 29 16:20:14 EDT 2021

9. (Optional) On the server and client: Lower the debug level if you do not wish to continue gathering detailed SSSD logs.

   [root@server ~]# sssctl debug-level 0

   [root@client ~]# sssctl debug-level 0

10. On the server and client: Review SSSD logs for information about the failed request.

    1. Review the request from the client in the client logs.
    2. Review the request from the client in the server logs.
    3. Review the result of the request in the server logs.
    4. Review the outcome of the client receiving the results of the request from the server.

11. If you are unable to determine the cause of the authentication issue:

    1. Collect the SSSD logs you recently generated on the IdM server and IdM client. Label them according to their hostname or role.

       [root@server ~]# sssctl logs-fetch sssd-logs-server-Mar29.tar

       [root@client ~]# sssctl logs-fetch sssd-logs-client-Mar29.tar

    2. Open a Red Hat Technical Support case and provide:

       1. The SSSD debug logs:

          1. sssd-logs-server-Mar29.tar from the server
          2. sssd-logs-client-Mar29.tar from the client

       2. The console output, including the time stamps and user name, of the request that corresponds to the logs:

          [root@client sssd]# date; su idmuser; date
          Mon Mar 29 16:20:13 EDT 2021
          su: user idmuser does not exist
          Mon Mar 29 16:20:14 EDT 2021

Procedure

1. To review your SSSD log file, open the log file using the less utility. For example, to view the /var/log/sssd/sssd_example.com.log:

   [root@server ~]# less /var/log/sssd/sssd_example.com.log

2. Review the SSSD logs for information about the client request.

   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_destructor] (0x0400): [RID#3] Number of active DP request: 0
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_req_reply_std] (0x1000): [RID#3] DP Request AccountDomain #3: Returning [Internal Error]: 3,1432158301,GetAccountDomain() not supported
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] DP Request Account #4: REQ_TRACE: New request. [sssd.nss CID #1] Flags [0x0001].
   (2021-07-26 18:26:37): [be[testidm.com]] [dp_attach_req] (0x0400): [RID#4] Number of active DP request: 1

   This sample output from an SSSD log file shows the unique identifiers RID#3 and RID#4 for two different requests.

Procedure

1. In the address bar of Firefox, type about:config to display the list of current configuration options.
2. In the Filter field, type negotiate to restrict the list of options.
3. Double-click the network.negotiate-auth.trusted-uris entry.

4. Enter the name of the domain against which to authenticate, including the preceding period (.). If you want to add multiple domains, enter them in a comma separated list.

   Figure 13.1. Manual Firefox Configuration

   

Procedure

1. In Mozilla Firefox, open the Firefox menu and select Preferences.

   

2. In the left panel, select the Privacy & Security section.

   
3. Scroll down to the Certificates section.

4. Click View Certificates to open the Certificate Manager.

   

Procedure

1. Open Certificate Manager.

2. Select the Authorities tab and click Import.

   Figure 13.2. Importing the CA Certificate in Firefox

   
3. Select the downloaded CA certificate from your device.

Prerequisites

1. You have successfully imported a certificate.

Procedure

1. Open Certificate Manager.
2. Under the Authorities tab, select the appropriate certificate and click Edit Trust.

3. Edit the certificate trust settings.

   Figure 13.3. Editing the Certificate Trust Settings in Firefox

   

Prerequisites

1. You have a personal certificate stored on your device.

Procedure

1. Open Certificate Manager.

2. Select the Your Certificates tab and click Import.

   Figure 13.4. Importing a Personal Certificate for Authentication in Firefox

   
3. Select the appropriate certificate from your computer.

Procedure

1. In Mozilla Thunderbird, open the main menu and select Preferences.

   Figure 13.5. Selecting preferences from menu

   

2. In the left panel, select the Privacy & Security section.

   Figure 13.6. Selecting security section

   
3. Scroll down to the Certificates section.

4. Click Manage Certificates to open the Certificate Manager.

   Figure 13.7. Opening certificate manager

   

Procedure

1. Open Certificate Manager.

2. Select the Authorities tab and click Import.

   Figure 13.8. Importing the CA certificate in Thunderbird

   
3. Select the downloaded CA certificate.

Procedure

1. Open Certificate Manager.
2. Under the Authorities tab, select the appropriate certificate and click Edit Trust.

3. Edit the certificate trust settings.

   Figure 13.9. Editing the certificate trust settings in Thunderbird

   

Prerequisites

1. You have a personal certificate stored on your device.

Procedure

1. Open Certificate Manager.

2. Under the Your Certificates tab, click Import.

   Figure 13.10. Importing a personal certificate for authentication in Thunderbird

   
3. Select the required certificate from your computer.
4. Close the Certificate Manager.

5. Open the main menu and select Account Settings.

   Figure 13.11. Selecting account settings from menu

   

6. Select End-To-End Encryption in the left panel under your account email address.

   Selecting end-to-end encryption section.

   
7. Under S/MIME section click the first Select button to choose your personal certificate to use for signing messages.

8. Under S/MIME section click the second Select button to choose your personal certificate to encrypt and decrypt messages.

   Choosing certificate for signing and encryption/decryption.