13.4. 缩小身份验证问题的范围

流程

1. 验证 SSSD 服务及其进程是否正在运行。

   [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. 验证客户端可以通过 IP 地址联系用户数据库服务器。

   [user@client ~]$ ping <IP_address_of_the_database_server>

   如果此步骤失败，请检查您的网络和防火墙设置是否允许 IdM 客户端和服务器之间进行直接通信。请参阅使用和配置 firewalld。

3. 验证客户端可以通过完全限定的主机名发现并联系 IdM LDAP 服务器（适用于 IdM 用户）或 AD 域控制器（ AD 用户）。

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

   如果此步骤失败，请检查您的 Dynamic Name Service (DNS) 设置，包括 /etc/resolv.conf 文件。请参阅配置 DNS 服务器顺序。

   注意

   默认情况下，SSSD 服务会尝试通过 DNS 服务 (SRV) 记录自动发现 LDAP 服务器和 AD DC。另外，您可以通过在 sssd.conf 配置文件中设置以下选项，将 SSSD 服务限制为使用特定的服务器：

   • 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>

   如果使用这些选项，请验证您可以联系它们中列出的服务器。

4. 验证客户端是否可以对 LDAP 服务器进行身份验证，并使用 ldapsearch 命令检索用户信息。

   1. 如果您的 LDAP 服务器是 IdM 服务器，如 server.example.com，检索主机的 Kerberos 票据，并使用主机 Kerberos 主体进行身份验证数据库搜索：

      [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. 如果您的 LDAP 服务器是 Active Directory (AD) 域控制器 (DC)，如 server.ad.example.com，请检索主机的 Kerberos 票据，并使用主机 Kerberos 主体执行数据库搜索：

      [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. 如果您的 LDAP 服务器是普通 LDAP 服务器，且您在 sssd.conf 文件中设置了 ldap_default_bind_dn 和 ldap_default_authtok 选项，请验证是同一个 ldap_default_bind_dn 帐户：

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

   如果此步骤失败，请验证您的数据库设置是否允许您的主机搜索 LDAP 服务器。

5. 由于 SSSD 服务使用 Kerberos 加密，因此请以无法登录的用户身份获得 Kerberos 票据。

   1. 如果您的 LDAP 服务器是 IdM 服务器：

      [user@client ~]$ kinit <user_name>

   2. 如果 LDAP 服务器数据库是 AD 服务器：

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

   如果此步骤失败，请验证您的 Kerberos 服务器是否正常运行，所有服务器都已同步其时间，并且用户帐户未被锁定。

6. 验证您是否可以检索有关命令行的用户信息。

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

   如果这一步失败，请验证客户端上的 SSSD 服务是否可以接收用户数据库的信息：

   1. 查看 /var/log/messages 日志文件中的错误。
   2. 在 SSSD 服务中启用详细的日志记录，收集调试日志，并查看日志以确定问题的根源。
   3. 可选：创建一个红帽技术支持问题单，并提供您收集的故障排除信息。

7. 如果您被允许在主机上运行 sudo，请使用 sssctl 工具验证用户是否被允许登录。

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

   如果这一步失败，请验证您的授权设置，如 PAM 配置、IdM HBAC 规则和 IdM RBAC 规则：

   1. 确保用户的 UID 等于或大于 UID_MIN，它在 /etc/login.defs 文件中定义。
   2. 查看 /var/log/secure 和 /var/log/messages 日志文件中的授权错误。
   3. 在 SSSD 服务中启用详细的日志记录，收集调试日志，并查看日志以确定问题的根源。
   4. 可选：创建一个红帽技术支持问题单，并提供您收集的故障排除信息。