13.4. 缩小身份验证问题的范围
要成功验证用户,您必须能够使用 SSSD 服务从存储用户信息的数据库检索用户信息。以下流程描述了测试身份验证流程的不同组件的步骤,以便您可以在用户无法登录时缩小身份验证问题的范围。
流程
验证 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
验证客户端可以通过 IP 地址联系用户数据库服务器。
[user@client ~]$ ping <IP_address_of_the_database_server>
如果此步骤失败,请检查您的网络和防火墙设置是否允许 IdM 客户端和服务器之间进行直接通信。请参阅使用和配置 firewalld。
验证客户端可以通过完全限定的主机名发现并联系 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>
如果使用这些选项,请验证您可以联系它们中列出的服务器。
-
验证客户端是否可以对 LDAP 服务器进行身份验证,并使用
ldapsearch
命令检索用户信息。如果您的 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>
如果您的 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>
如果您的 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 服务器。
由于 SSSD 服务使用 Kerberos 加密,因此请以无法登录的用户身份获得 Kerberos 票据。
如果您的 LDAP 服务器是 IdM 服务器:
[user@client ~]$ kinit <user_name>
如果 LDAP 服务器数据库是 AD 服务器:
[user@client ~]$ kinit <user_name@AD.EXAMPLE.COM>
如果此步骤失败,请验证您的 Kerberos 服务器是否正常运行,所有服务器都已同步其时间,并且用户帐户未被锁定。
验证您是否可以检索有关命令行的用户信息。
[user@client ~]$ getent passwd <user_name> [user@client ~]$ id <user_name>
如果这一步失败,请验证客户端上的 SSSD 服务是否可以接收用户数据库的信息:
-
查看
/var/log/messages
日志文件中的错误。 - 在 SSSD 服务中启用详细的日志记录,收集调试日志,并查看日志以确定问题的根源。
- 可选:创建一个红帽技术支持问题单,并提供您收集的故障排除信息。
-
查看
如果您被允许在主机上运行
sudo
,请使用sssctl
工具验证用户是否被允许登录。[user@client ~]$ sudo sssctl user-checks -a auth -s ssh <user_name>
如果这一步失败,请验证您的授权设置,如 PAM 配置、IdM HBAC 规则和 IdM RBAC 规则:
-
确保用户的 UID 等于或大于
UID_MIN
,它在/etc/login.defs
文件中定义。 -
查看
/var/log/secure
和/var/log/messages
日志文件中的授权错误。 - 在 SSSD 服务中启用详细的日志记录,收集调试日志,并查看日志以确定问题的根源。
- 可选:创建一个红帽技术支持问题单,并提供您收集的故障排除信息。
-
确保用户的 UID 等于或大于