Red Hat Training

A Red Hat training course is available for RHEL 8

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

要成功验证用户,您必须能够使用 SSSD 服务从存储用户信息的数据库检索用户信息。以下流程描述了测试身份验证流程的不同组件的步骤,以便您可以在用户无法登录时缩小身份验证问题的范围。

流程

  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_dnldap_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. (可选)创建一个红帽技术支持问题单,并提供您收集的故障排除信息。