我在几台机器上使用 freeipa 时遇到了问题。到目前为止，调试过程非常令人沮丧。以下是问题的详细信息；
其表现方式：
用户可以正常登录到任何主机，但在某些主机上他们无法运行 sudo 命令。
我知道的：
有一个 IPA sudo 策略，即“允许此用户在任何主机上运行任何命令”，还有一个 HBAC 策略，即“允许此用户在任何主机上使用任何服务”，所以我想我可以排除 IPA 策略是个问题。
根据 tcpdump 的说法，这似乎只会在机器与某个特定 ipa 服务器（通过 dns srv 记录）联系时才会影响它们，我通过刷新 sss_cache 并执行 sudo -k 确定了这一点。有问题的机器之一实际上是该 ipa 服务器本身，因此我排除了网络/防火墙是原因。我非常确定它仅限于该 ipa 服务器以及使用该特定 ipa 服务器的客户端。
只关注 ipa 服务器本身，并将其与我的其他 ipa 服务器进行比较，sudo.conf、sudoers、sssd.conf 完全相同（除了在损坏的服务器上添加了调试）。两者的 LAN ip 都在 /etc/hosts 中，并且都使用 ntpd（我认为这可以排除 kerberos 计时问题）。除了打开调试之外，sssd.conf 和 sudo.conf 文件与全新安装时没有变化。
损坏的 ipa 服务器是第一个安装的，因此它是主 ca 等。
有问题的机器上的 Sudo（为简单起见，我关注损坏的 ipa 服务器本身）对在 /etc/sudoers 文件、/etc/passwd 等中本地定义的用户有效。
细节：
所有机器都使用 centos 7 和 ipa 4.2.0
日志：（域名和用户已清理）
=-=-=- from end of sssd logs on server1 =-=-=-
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [set_server_common_status] (0x0100): Marking server 'server1.domain.com' as 'working'
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success (Success)]
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [0][domain.com]
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [0][domain.com]
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [be_pam_handler] (0x0100): Got request with the following data
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): domain: domain.com
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): user: sirex
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): service: sudo
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): tty: /dev/pts/2
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): ruser: sirex
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): rhost:
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): authtok type: 0
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): newauthtok type: 0
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): priv: 0
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): cli_pid: 13960
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [pam_print_data] (0x0100): logon name: not set
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [ipa_hostgroup_info_done] (0x0200): Dereferenced host group: ipa-servers
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [hbac_get_category] (0x0200): Category is set to 'all'.
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [hbac_get_category] (0x0200): Category is set to 'all'.
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [hbac_get_category] (0x0200): Category is set to 'all'.
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow ops to anything]
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, <NULL>) [Success (Success)]
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [child_sig_handler] (0x0100): child [13965] finished successfully.
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success (Success)]
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [0][domain.com]
(Tue Jun 28 23:21:33 2016) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [0][domain.com]
=-=-=- sudo debugging output on server1 from password prompt to failure =-=-=-
Jun 28 21:59:07 sudo[9738] <- expand_prompt @ ./check.c:398 := [sudo] password for sirex:
Jun 28 21:59:07 sudo[9738] -> verify_user @ ./auth/sudo_auth.c:193
Jun 28 21:59:07 sudo[9738] -> sudo_pam_verify @ ./auth/pam.c:131
Jun 28 21:59:07 sudo[9738] -> converse @ ./auth/pam.c:305
Jun 28 21:59:07 sudo[9738] -> auth_getpass @ ./auth/sudo_auth.c:347
Jun 28 21:59:07 sudo[9738] -> tgetpass @ ./tgetpass.c:76
Jun 28 21:59:07 sudo[9738] -> tty_present @ ./tgetpass.c:329
Jun 28 21:59:07 sudo[9738] <- tty_present @ ./tgetpass.c:333 := true
Jun 28 21:59:07 sudo[9738] -> term_noecho @ ./term.c:88
Jun 28 21:59:07 sudo[9738] <- term_noecho @ ./term.c:99 := 1
Jun 28 21:59:07 sudo[9738] -> getln @ ./tgetpass.c:272
Jun 28 21:59:09 sudo[9738] <- getln @ ./tgetpass.c:315 := **********
Jun 28 21:59:09 sudo[9738] -> term_restore @ ./term.c:73
Jun 28 21:59:09 sudo[9738] <- term_restore @ ./term.c:82 := 1
Jun 28 21:59:09 sudo[9738] <- tgetpass @ ./tgetpass.c:202 := **********
Jun 28 21:59:09 sudo[9738] <- auth_getpass @ ./auth/sudo_auth.c:365 := **********
Jun 28 21:59:09 sudo[9738] <- converse @ ./auth/pam.c:387 := 0
Jun 28 21:59:09 sudo[9738] <- sudo_pam_verify @ ./auth/pam.c:142 := 0
Jun 28 21:59:09 sudo[9738] <- verify_user @ ./auth/sudo_auth.c:282 := 1
Jun 28 21:59:09 sudo[9738] -> sudo_auth_cleanup @ ./auth/sudo_auth.c:160
Jun 28 21:59:09 sudo[9738] -> sudo_pam_cleanup @ ./auth/pam.c:189
Jun 28 21:59:09 sudo[9738] <- sudo_pam_cleanup @ ./auth/pam.c:193 := 0
Jun 28 21:59:09 sudo[9738] <- sudo_auth_cleanup @ ./auth/sudo_auth.c:177 := 0
Jun 28 21:59:09 sudo[9738] -> sudo_pw_delref @ ./pwutil.c:249
Jun 28 21:59:09 sudo[9738] -> sudo_pw_delref_item @ ./pwutil.c:238
Jun 28 21:59:09 sudo[9738] <- sudo_pw_delref_item @ ./pwutil.c:243
Jun 28 21:59:09 sudo[9738] <- sudo_pw_delref @ ./pwutil.c:251
Jun 28 21:59:09 sudo[9738] <- check_user @ ./check.c:189 := true
Jun 28 21:59:09 sudo[9738] -> log_failure @ ./logging.c:318
Jun 28 21:59:09 sudo[9738] -> log_denial @ ./logging.c:256
Jun 28 21:59:09 sudo[9738] -> audit_failure @ ./audit.c:68
Jun 28 21:59:09 sudo[9738] -> linux_audit_command @ ./linux_audit.c:70
Jun 28 21:59:09 sudo[9738] -> linux_audit_open @ ./linux_audit.c:49
Jun 28 21:59:09 sudo[9738] <- linux_audit_open @ ./linux_audit.c:61 := 13
Jun 28 21:59:09 sudo[9738] <- linux_audit_command @ ./linux_audit.c:97 := 3
Jun 28 21:59:09 sudo[9738] <- audit_failure @ ./audit.c:81
Jun 28 21:59:09 sudo[9738] -> new_logline @ ./logging.c:746
Jun 28 21:59:09 sudo[9738] <- new_logline @ ./logging.c:867 := user NOT authorized on host ; TTY=pts/2 ; PWD=/home/sirex ; USER=root ; COMMAND=/bin/bash -l
除非我理解错误，否则在我看来，sudo 正在与 sssd 对话，而 sssd 通过 kerberos 与 IPA 对话（在同一台机器上）。这表示 OK，然后 sudo... 出于某种原因，拒绝了它并说不？
配置：（损坏的 ipa 服务器）
=-=-=- sudo.conf (comment lines removed) =-=-=-=-
Debug sudo /var/log/sudo_debug all@debug
Debug sudoers.so /var/log/sudo_debug all@debug
Plugin sudoers_policy sudoers.so
Plugin sudoers_io sudoers.so
Set disable_coredump false
=-=-=- sssd.conf (whitespace removed) =-=-=-=-
[domain/domain.com]
debug_level = 5
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = domain.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = server1.domain.com
chpass_provider = ipa
ipa_server = server1.domain.com
ipa_server_mode = True
ldap_tls_cacert = /etc/ipa/ca.crt
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
domains = domain.com
[nss]
memcache_timeout = 600
homedir_substring = /home
[pam]
[sudo]
[autofs]
[ssh]
[pac]
[ifp]
=-=-==- /etc/sudoers (comments removed) =-=-=-=-=-
Defaults !visiblepw
Defaults always_set_home
Defaults env_reset
Defaults env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
编辑1：好的，根据 jhrozek 的建议，我还在 [sudo] 部分启用了调试，这在日志中给出了以下内容：
(Wed Jun 29 21:08:27 2016) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving default options for [sirex] from [domain.com]
(Wed Jun 29 21:08:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=sirex)(sudoUser=#123607)(sudoUser=%confluence-administrators)(sudoUser=%jira-administrators)(sudoUser=%build_system_shell)(sudoUser=%jira-developers)(sudoUser=%publictracker)(sudoUser=%staff)(sudoUser=%wikiprivate)(sudoUser=%jira-users)(sudoUser=%vpn_users)(sudoUser=%ipausers)(sudoUser=%admins)(sudoUser=%gerrit)(sudoUser=%sirex)(sudoUser=%wiki)(sudoUser=%ops)(sudoUser=%gerrit-submit)(sudoUser=%sirex)(sudoUser=+*))(&(dataExpireTimestamp<=1467234507)))]
(Wed Jun 29 21:08:27 2016) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache
(Wed Jun 29 21:08:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(name=defaults)))]
(Wed Jun 29 21:08:27 2016) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [<default options>@domain.com]
ldbsearch 给出 0 个结果，但也显示“asq：无法使用 rootdse 注册控制！”（尽管其他服务器上也显示此信息）
在损坏的服务器上
ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb -b cn=sysdb '(objectClass=sudoRule)'
给出 0，而在其他身份验证服务器上给出 3，所以我猜它与复制有关，但现在的问题是如何解决这个问题。
编辑2：奇怪的是，在坏掉的服务器上
ipa sudorule-find All
返回 3 条规则！？我尝试删除损坏服务器上的 sssd 缓存文件并重新启动 sssd，但 ldbsearch 仍然显示 0 条规则。
如果我不使用过滤器执行 ldbsearch，我会在损坏的服务器上得到 48 条记录，在其他服务器上得到 51 条记录。仅缺少 3 条 sudo 规则条目。
我在一台正常运行的 ipa 服务器上制定了这些 sudo 规则，因此我认为要么是 sysdb 表的复制不起作用，要么是它的 sudo 规则不起作用。它们之间有防火墙，但用户创建是在正常运行的 ipa 服务器上进行的是复制到损坏的 ipa 服务器，所以我不知道是否可以排除防火墙。但值得注意的是，虽然我认为所有端口都允许在它们之间使用，但损坏的服务器位于 DMZ 子网中，因此我不允许端口 22 (ssh) 从该 ipa 服务器返回到其他服务器。我不知道这是否重要？但是我已经完成了 conncheck 脚本，它表示一切正常或对 ipa 本身正在使用的两个端口发出警告
编辑3：好的，因此在损坏的服务器上制定一条影响所有服务器的 sudo 规则（因此它应该缓存在 sssd 中）会使新规则显示在 UI 中（以及其他 3 个规则），但确实如此不是出现在 sssd 中。因此看起来 sssd 没有正确缓存规则。
我刚刚找到一个文件 ~/.ipa/log/cli.log，在损坏的服务器上（仅）有
2016-05-29T22:59:23Z 6583 MainThread ipa ERROR Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error)
我不知道这是转移注意力的幌子还是确凿的证据？
编辑 4：从 Danila Ladner 的评论和后续测试来看，这似乎发生在 4.2.0-15.0.1.el7.centos.17 中，但没有发生在 4.2.0-15.0.1.el7.centos.6.1 中，我认为这是由于 libsss 相应升级到 1.13.0.40.el7_2.9 造成的
我认为这与以下因素有关： https://fedorahosted.org/sssd/ticket/1108
和
https://bugzilla.redhat.com/show_bug.cgi?id=1256849
但是现在我只需要想办法修复它。ipa-compat 树未在“损坏的” ipa 服务器上启用，现在已启用但仍然没有问题。
答案1
这似乎与以下错误有关：https://fedorahosted.org/sssd/ticket/1108
和
https://bugzilla.redhat.com/show_bug.cgi?id=1256849
启用兼容树的建议似乎起了作用，等待约 30 分钟，让 sssd 缓存在网络上过期。
简而言之，您需要确保在 ipa 中启用了 compat 树，以便 sssd 能够正确缓存 sudo 规则。我在一个“损坏”的 ipa 服务器上关闭了 compat 树，当客户端与该特定 ipa 服务器通信时（通过 DNS SRV 记录），它们没有缓存任何 sudo 规则。这表现为机器有时能够让用户使用 sudo，有时则不能。由于 ipa 服务器本身不使用 SRV 记录，而是使用其自身，因此 ipa 服务器上的 sudo 总是损坏。
在 ipa 服务器上运行“ipa-compat-manage enable”并等待 sssd 缓存过期似乎已解决问题。