支持控制台（Console）开发人员开始试用联系人

附录 A. 故障排除

A.1. SSSD 故障排除

A.1.1. 为 SSSD 域设置调试日志

每个域设置自己的调试日志级别。提高日志级别可以提供有关 SSSD 或域配置问题的更多信息。
要更改日志级别，请在 sssd.conf 文件中为每个部分设置 debug_level 参数，以生成额外日志。例如： 
[domain/LDAP]
cache_credentials = true
debug_level = 9
表 A.1. 调试日志级别
级别 Description
0 严重故障.阻止 SSSD 启动或导致 SSSD 停止运行的任何内容。
1 严重故障.没有终止 SSSD 的错误，但表明至少有一个主要功能无法正常工作的错误。
2 严重故障.声明特定请求或操作失败的错误。
3 小故障.这些错误会导致 2 操作失败。
4 配置设置.
5 功能数据.
6 跟踪操作功能的消息。
7 跟踪内部控制功能的消息。
8 功能内部变量的内容可能比较有趣。
9 极低级别的追踪信息。
要在 SSSD 运行时更改 debug 级别，请使用 sss_debuglevel 工具，这是 sssd-tools 软件包的一部分。有关它如何工作的详情请参考 sss_debuglevel man page。

A.1.2. 检查 SSSD 日志文件

SSSD 使用很多日志文件报告其操作的信息，位于 /var/log/sssd/ 目录中。SSSD 为每个域生成日志文件，以及 sssd_pam.log 和 sssd_nss.log 文件。
  • krb5_child.log: Kerberos 身份验证中涉及的短期帮助程序进程的日志文件
  • ldap_child.log: 与 LDAP 服务器通信的短期帮助程序进程的日志文件
  • selinux_child.log: 检索 SELinux 信息的短期帮助程序进程的日志文件
  • sssd.log ： SSSD 与响应器进程通信的日志文件
  • sssd_[domain].log ：每个 SSSD 域部分都记录与 LDAP 服务器通信的信息到单独的日志文件
  • sssd_ifp.log: InfoPipe 响应器的日志文件，提供了一个可通过系统总线访问的公共 D-Bus 接口
  • sssd_nss.log ：检索用户和组信息的 Name Services Switch (NSS)响应器的日志文件
  • sssd_pac.log: Microsoft Privilege Attribute 证书(PAC)响应器服务的日志文件，该服务定义 SSSD 如何与 Kerberos 一起工作来管理 Active Directory 用户和组
  • sssd_pam.log: 用于可插拔验证模块(PAM)响应器的日志文件
  • sssd_ssh.log: SSH 响应器进程的日志文件
另外，/var/log/secure 文件记录身份验证失败以及失败的原因。

A.1.3. SSSD 配置的问题

问：
SSSD 无法启动
答：
SSSD 要求在守护进程启动前正确设置配置文件，并包含所有需要的条目。
  • SSSD 需要至少一个正确配置的域才能启动该服务。如果没有域，尝试启动 SSSD 会返回一个没有配置域的错误： 
    # sssd -d4 -i

[sssd] [ldb] (3): server_sort:Unable to register control with rootdse!
[sssd] [confdb_get_domains] (0): No domains configured, fatal error!
[sssd] [get_monitor_config] (0): No domains configured.
    编辑 /etc/sssd/sssd.conf 文件并至少创建一个域。
  • SSSD 还需要至少一个可用的服务提供商才能启动。如果问题出现在服务供应商配置中，则错误消息表示没有配置服务： 
    [sssd] [get_monitor_config] (0): No services configured!
    编辑 /etc/sssd/sssd.conf 文件，并至少配置一个服务提供商。
    重要
    SSSD 要求在 /etc/sssd/sssd.conf 文件中的单个 services 条目中将服务提供商配置为用逗号分开的列表。如果服务在多个条目中列出，则 SSSD 只识别最后一个条目。
  • SSSD 还需要正确设置 /etc/sssd/sssd.conf 的所有权和权限。如果所有权或权限设置不正确，尝试启动 SSSD 会返回这些错误消息： 
    [sssd] [confdb_ldif_from_ini_file] (0x0020): Permission check on config file failed.
[sssd] [confdb_init_db] (0x0020): Cannot convert INI to LDIF [1]: [Operation not permitted]
[sssd] [confdb_setup] (0x0010): ConfDB initialization has failed [1]: Operation not permitted
[sssd] [load_configuration] (0x0010): Unable to setup ConfDB [1]: Operation not permitted
[sssd] [main] (0x0020): Cannot read config file /etc/sssd/sssd.conf. Please check that the file is accessible only by the owner and owned by root.root.
    设置 /etc/sssd/sssd.conf 文件的正确所有权和权限： 
    # chmod 600 /etc/sssd/sssd.conf
# chown root:root /etc/sssd/sssd.conf
问：
我没有看到 ID 或组成员 为 entent 组的任何 组。
答：
这可能是因为 sssd.conf 的 [domain/DOMAINNAME] 部分中的 ldap_schema 设置不正确。
SSSD 支持 RFC 2307 和 RFC 2307bis 模式类型。默认情况下，SSSD 使用更常见的 RFC 2307 模式。
RFC 2307 和 RFC 2307bis 之间的区别在于组成员资格存储在 LDAP 服务器中的方式。在 RFC 2307 服务器中，组成员存储为多值 memberuid 属性，其中包含属于成员的用户名称。在 RFC2307bis 服务器中，组成员存储为多值 member 或 uniqueMember 属性，其中包含属于这个组成员的用户或组群的 DN。RFC2307bis 还允许维护嵌套组。
如果组查找没有返回任何信息：
  1. 将 ldap_schema 设置为 rfc2307bis。
  2. Delete /var/lib/sss/db/cache_DOMAINNAME.ldb.
  3. 重启 SSSD.
如果这不起作用，请将此行添加到 sssd.conf 中： 
ldap_group_name = uniqueMember
然后，删除缓存并再次重新启动 SSSD。
问：
身份验证针对 LDAP 失败。
答：
要进行身份验证，SSSD 需要对通信通道进行加密。这意味着，如果 sssd.conf 被配置为通过标准协议(ldap://)连接，它会尝试使用 Start TLS 加密通信频道。如果将 sssd.conf 配置为通过安全协议连接(ldaps://)，则 SSSD 使用 SSL。
这意味着 LDAP 服务器必须配置为在 SSL 或 TLS 中运行。必须为标准 LDAP 端口(389)或在安全 LDAPS 端口(636)上启用 SSL 启用 TLS。对于 SSL 或 TLS，还必须为 LDAP 服务器配置有效的证书信任关系。
无效的证书信任是针对 LDAP 验证最常见的问题之一。如果客户端没有 LDAP 服务器证书的正确信任，则无法验证连接，SSSD 会拒绝发送密码。LDAP 协议要求以纯文本将密码发送到 LDAP 服务器。通过未加密的连接以纯文本形式发送密码是一个安全问题。
如果证书不被信任，则会写入 syslog 消息，表示无法启动 TLS 加密。证书配置可以通过检查除 SSSD 外是否可以访问 LDAP 服务器来测试证书配置。例如，这会测试通过 TLS 连接到 test.example.com 的匿名绑定： 
$ ldapsearch -x -ZZ -h test.example.com -b dc=example,dc=com
如果没有正确配置证书信任，测试会失败并显示以下错误： 
ldap_start_tls: Connect error (-11) additional info: TLS error -8179:Unknown code ___f 13
信任证书：
  1. 获取用于为 LDAP 服务器证书签名并将其保存到本地系统的证书颁发机构的公共 CA 证书副本。
  2. 向 sssd.conf 文件中添加一行，指向文件系统上的 CA 证书。 
    ldap_tls_cacert = /path/to/cacert
  3. 如果 LDAP 服务器使用自签名证书，请从 sssd.conf 文件中删除 ldap_tls_reqcert 行。
    此参数指示 SSSD 信任 CA 证书发布的任何证书，这是使用自签名 CA 证书的安全风险。
问：
连接到非标准端口上的 LDAP 服务器会失败。
答：
在强制模式下运行 SELinux 时，必须修改客户端的 SELinux 策略，以通过非标准端口连接到 LDAP 服务器。例如： 
# semanage port -a -t ldap_port_t -p tcp 1389
问：
NSS 无法返回用户信息
答：
这通常意味着 SSSD 无法连接到 NSS 服务。
  • 确保 NSS 服务正在运行： 
    # service sssd status
Redirecting to /bin/systemctl status sssd.service
  sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled)
   Active: active (running) since Wed 2015-01-14 10:17:26 CET; 1min 30s ago
   Process: 683 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 745 (sssd)
   CGroup: /system.slice/sssd.service
            ├─745 /usr/sbin/sssd -D -f
	    ├─746 /usr/libexec/sssd/sssd_be --domain default --debug-to-files...
	    ├─804 /usr/libexec/sssd/sssd_nss --debug-to-files
	    └─805 /usr/libexec/sssd/sssd_pam --debug-to-files
    当 SSSD 处于 Active: active (running) 状态以及输出包括 sssd_nss 时，NSS 服务正在运行。
  • 如果 NSS 正在运行，请确保在 /etc/sssd/sssd.conf 文件的 [nss] 部分中正确配置了供应商。特别是检查 filter_users 和 filter_groups 属性。
  • 确保 NSS 包含在 SSSD 使用的服务列表中。
  • 检查 /etc/nsswitch.conf 文件中的配置。如需更多信息，请参阅 “配置 NSS 服务以使用 SSSD”一节。
问：
NSS 返回不正确的用户信息
答：
如果搜索返回不正确的用户信息，请检查单独的域中是否没有冲突的用户名。当有多个域时，在 /etc/sssd/sssd.conf 文件中将 use_fully_qualified_domains 属性设置为 true。这会区分名称相同的不同域中的不同用户。
问：
为本地 SSSD 用户设置密码会提示输入两次密码
答：
当尝试更改本地 SSSD 用户的密码时，它可能会提示输入两次密码： 
[root@clientF11 tmp]# passwd user1000
Changing password for user user1000.
New password:
Retype new password:
New Password:
Reenter new Password:
passwd: all authentication tokens updated successfully.
这是 PAM 配置不正确的结果。确定在 /etc/pam.d/system-auth 文件中正确配置了 use_authtok 选项。有关正确配置的示例，请参阅 第 7.5.2 节 “配置服务：PAM”。
问：
在 sssd.conf 文件中正确配置了 Active Directory 身份提供程序，但 SSSD 无法连接到它，并显示 GSS-API 错误。
答：
SSSD 只能使用其主机名连接到 Active Directory 供应商。如果没有指定主机名，SSSD 客户端无法将 IP 地址解析到主机，身份验证会失败。
例如，使用这个配置： 
[domain/ADEXAMPLE]
debug_level = 0xFFF0
id_provider = ad
ad_server = 172.16.0.1
ad_domain = example.com
krb5_canonicalize = False
SSSD 客户端返回这个 GSS-API 失败，身份验证请求会失败： 
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error]
(Fri Jul 27 18:27:44 2012) [sssd[be[ADTEST]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Cannot determine realm for numeric host address)]
要避免这个错误，将 ad_server 设置为 Active Directory 主机的名称，或使用 _srv_ 关键字使用 DNS 服务发现，如 第 7.4.3 节 “配置 DNS 服务发现” 所述。
问：
我为中央身份验证配置了 SSSD，但现在我的几个应用程序（如 Firefox 或 Adobe）将不会启动。
答：
即使在 64 位系统中，32 位应用程序也需要 32 位版本的 SSSD 客户端库才能访问密码和身份缓存。如果 32 位版本的 SSSD 不可用，但系统被配置为使用 SSSD 缓存，则 32 位应用程序可能无法启动。
例如，Firefox 可能会因为 permission denied 错误而失败： 
Failed to contact configuration server. See http://www.gnome.org/projects/gconf/
for information. (Details -  1: IOR file '/tmp/gconfd-somebody/lock/ior'
not opened successfully, no gconfd located: Permission denied 2: IOR
file '/tmp/gconfd-somebody/lock/ior' not opened successfully, no gconfd
located: Permission denied)
对于 Adobe Reader，错误显示当前系统用户没有被识别： 
[jsmith@server ~]$ acroread
(acroread:12739): GLib-WARNING **: getpwuid_r(): failed due to unknown
user id (366)
其他应用可能会显示类似的用户或权限错误。
问：
SSSD 显示我删除的自动挂载位置。
答：
自动挂载位置的 SSSD 缓存会保留，即使该位置随后被更改或删除。在 SSSD 中更新 autofs 信息：
  1. 删除 autofs 缓存，如 第 A.1.4 节 “用户在 UID 或 GID 更改后无法登录” 所述。
  2. 重启 SSSD： 
    # systemctl restart sssd

A.1.4. 用户在 UID 或 GID 更改后无法登录

更改用户或组群 ID 后，SSSD 会阻止用户登录。

这意味着：

SSSD 根据用户 ID(UID)和组 ID(GID)识别用户和组。当现有用户或组的 UID 或 GID 发生变化时，SSSD 不识别该用户或组。

解决此问题：

使用 sss_cache 程序清除 SSSD 缓存：
  1. 确保已安装 sssd-tools。
  2. 要清除特定用户的 SSSD 缓存，并让缓存记录的其余部分保持不变： 
    # sss_cache --user user_name
    清除整个域的缓存： 
    # sss_cache --domain domain_name
实用程序使 SSSD 缓存中的记录无效，用于用户、组或域。之后，SSSD 从身份提供程序检索记录以刷新缓存。
有关 sss_cache 的详情，请查看 sss_cache(8) man page。

A.1.5. SSSD 控制和状态实用程序

SSSD 提供 sssctl 工具，以获取状态信息，在故障排除期间管理数据文件，以及其他与 SSSD 相关的任务。
  1. 要使用 sssctl，请安装 sssd-tools 软件包： 
    [root@server ~]# yum install sssd-tools
  2. sssctl 的一些选项使用 SSSD InfoPipe 响应器。要启用它，请将 ifp 添加到 /etc/sssd/sssd.conf 的 services 选项中： 
    [sssd]
services = nss, sudo, pam, ssh, ifp
  3. 重启 SSSD： 
    [root@server ~]# systemctl restart sssd.service

A.1.5.1. SSSD 配置验证

sssctl config-check 命令对 SSSD 配置文件执行静态分析。这可让您在重启 SSSD 前验证 /etc/sssd/sssd.conf 文件和 /etc/sssd/conf.d VRF 文件接收报告。
该命令对 SSSD 配置文件执行以下检查：
权限
所有者和组所有者必须设置为 root:root，权限设为 600。
文件名
/etc/sssd/conf.d/ 中的文件名必须使用后缀 .conf，而不能以句点（隐藏文件）开头。
拼写错误
部分和选项名称中将检查排字错误。请注意，值不会被检查。
选项
选项必须放在正确的部分中。
要验证配置，请运行： 
# sssctl config-check
Issues identified by validators: 3
[rule/allowed_sections]: Section [paM] is not allowed. Check for typos.
[rule/allowed_domain_options]: Attribute 'offline_timeoutX' is not allowed in section 'domain/idm.example.com'. Check for typos.
[rule/allowed_sudo_options]: Attribute 'homedir_substring' is not allowed in section 'sudo'. Check for typos.

Messages generated during configuration merging: 2
File /etc/sssd/conf.d/wrong-file-permissions.conf did not pass access check. Skipping.
File configuration.conf.disabled did not match provided patterns. Skipping.

Used configuration snippet files: 1
/etc/sssd/conf.d/sample.conf

A.1.5.2. 显示用户数据

sssctl user-checks 命令有助于调试使用 SSSD 作为用户查找、身份验证和授权的后端的问题。命令可显示通过 NSS 和 D-Bus 界面的 InfoPipe 响应器提供的用户数据。显示的数据显示用户是否被授权使用 system-auth PAM 服务登录。
例如，显示 admin 用户的用户数据： 
# sssctl user-checks admin
user: admin
action: acct
service: system-auth

SSSD nss user lookup result:
 - user name: admin
 - user id: 1194200000
 - group id: 1194200000
 - gecos: Administrator
 - home directory: /home/admin
 - shell: /bin/bash

SSSD InfoPipe user lookup result:
 - name: admin
 - uidNumber: 1194200000
 - gidNumber: 1194200000
 - gecos: Administrator
 - homeDirectory: /home/admin
 - loginShell: /bin/bash

testing pam_acct_mgmt

pam_acct_mgmt: Success

PAM Environment:
 - no env -
有关更多选项，请查看 sssctl user-checks --help 命令的输出。

A.1.5.3. 域信息

域状态显示域 SSSD 访问的列表，并可让您检索其状态。
  1. 列出 SSSD 内所有可用域，包括可信域： 
    [root@server ~]# sssctl domain-list
idm.example.com
ad.example.com
  2. 检索域 idm.example.com 的状态： 
    [root@server ~]# sssctl domain-status idm.example.com
Online status: Online

A.1.5.4. 缓存的条目信息

sssctl 命令允许您检索有关缓存条目的信息，以调查和调试与缓存相关的身份验证问题。
要查询用户帐户 admin 的缓存信息，请运行： 
[root@server ~]# sssctl user-show admin
Name: admin
Cache entry creation date: 07/10/16 16:09:18
Cache entry last update time: 07/14/16 10:13:32
Cache entry expiration time: 07/14/16 11:43:32
Initgroups expiration time: Expired
Cached in InfoPipe: No
要查询组或网络组的缓存信息，请使用： 
[root@server ~]# sssctl group-show groupname
[root@server ~]# sssctl netgroup-show netgroupname

A.1.5.5. 截断日志文件

调试问题时，您可以使用 sssctl logs-remove 截断 /var/log/sssd/ 目录中的所有 SSSD 日志文件，以仅捕获新创建的条目。 
[root@server ~]# sssctl logs-remove
Truncating log files...

A.1.5.6. 删除 SSSD 缓存

要删除 SSSD 缓存数据库文件，s ctl 命令提供 remove-cache 选项。在删除数据库之前，命令会自动创建备份。
使用以下命令备份所有本地数据并删除 SSSD 缓存： 
[root@server ~]# sssctl cache-remove
SSSD must not be running. Stop SSSD now? (yes/no) [yes]
Creating backup of local data...
Removing cache files...
SSSD needs to be running. Start SSSD now? (yes/no) [yes]
注意
备份仅将本地数据（如本地覆盖）存储在 /var/lib/sss/backup/ 目录中。
要自动导入备份的内容，请运行 sssctl restore-local-data。

A.1.5.7. 获取 LDAP 组获取长信息

涉及查找 LDAP 组信息的操作需要非常长，特别是在有大型组或嵌套组的情况下。

这意味着：

默认情况下，LDAP 组信息查找会返回组的所有成员。对于涉及大型组或嵌套组的操作，返回所有成员会使进程更长。

解决此问题：

评估用户是否属于某个组时，不会使用组查找返回的成员资格列表。要提高性能，特别是身份查找，请禁用组成员资格查找：
  1. 打开 /etc/sssd/sssd.conf 文件：
  2. 在 [domain] 部分中，将 ignore_group_members 选项设置为 true。 
    [domain/domain_name]
[... file truncated ...]
ignore_group_members = true
注意
当部署涉及具有 compat 树的 IdM 服务器时，不应该将此选项设置为 true。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务，以及可以信赖的内容，帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情，请参阅红帽博客.

關於紅帽

我们提供强化的解决方案，使企业能够更轻松地跨平台和环境（从核心数据中心到网络边缘）工作。

© 2024 Red Hat, Inc.