12.4. Narrowing the scope of authentication issues

Procédure

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