ipa用户不能在某些机器上sudo，包括ipa服务器

我在几台机器上遇到freeipa问题。 debugging到目前为止非常令人沮丧。 这是问题的细节;

它如何体现：

用户可以很好地login到任何主机，但在一些主机上，他们不能运行sudo命令。

我知道的：

• 在FreeIPA 4中扩展已经存在的API和CLI调用的最小例子
• IPA服务器NFS服务添加问题centos 7.2
• 免费的IPA – Active Directory似乎设置，但身份validation不起作用
• FreeIPA：用于添加多个NFS客户端的Keytab文件
• 所有免费的IPA客户端无法login

有一个IPA的sudo策略是“允许这个用户在任何主机上运行任何命令”，还有一个“允许这个用户在任何主机上使用任何服务”的HBAC策略，所以我认为我可以排除IPA策略是一个问题。

这似乎只影响机器，当他们联系一台特定的ipa服务器（通过dns srvlogging）时，根据tcpdump，我通过刷新sss_cache和做sudo -k来确定。 其中一台机器实际上是ipa服务器本身，所以我排除了networking/防火墙的原因。 我非常确定它仅限于那个ipa服务器，以及使用特定ipa服务器的客户端。

只关注ipa服务器本身，并将其与我的其他ipa服务器之一sudo.conf，sudoers，sssd.conf是相同的（减去debugging添加到破碎的）。 两个都有自己的局域网ip在/ etc / hosts中，都使用ntpd（我认为这排除了kerberos计时问题）。 除了打开debuggingsssd.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交谈。 那就说好，那么sudo ……出于某种原因拒绝了，反正说不？

configuration:(破碎的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：好吧，build议从jhrozek我也启用debugging[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注册控件！ （尽pipe它也说在其他服务器上）

在破碎的服务器上

 ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb -b cn=sysdb '(objectClass=sudoRule)' 

给出0，而在其他auth服务器上给出3，所以我想这是以某种方式复制相关，但现在的问题是如何解决这个问题。

编辑2：奇怪的是，在破碎的服务器上

 ipa sudorule-find All 

返回3条规则！？ 我已经尝试删除破损的服务器上的sssdcaching文件，并重新启动sssd，但ldbsearch仍然给出0规则find。

如果我做了没有filter的ldbsearch，我得到了破损的服务器上的48条logging和其他的51条logging。 只有3个sudo规则条目丢失。

我在其中一个工作的ipa服务器上制定了这些sudo规则，所以我被引导认为复制不是为sysdb表工作，或者它不适用于sudo规则。 他们之间有一个防火墙，但在工作的ipa服务器上的用户创build被复制到破碎的ipa服务器，所以我不知道我是否可以统治防火墙。 值得注意的是，虽然我认为所有的端口之间允许它们，破损的服务器是在DMZ子网，所以我不允许端口22（ssh）从该ipa服务器回到其他人。 我不知道这是否重要？ 然而，我已经做了conncheck脚本，它说，一切正常或警告的ipa本身使用的两个端口

编辑3：好的，所以在影响所有服务器（所以它应该被caching在sssd）的破坏的服务器上做一个sudo规则使新的规则显示在用户界面（以及3其他），但它不显示在SSSD。 所以看起来sssd没有正确caching规则。

我刚刚发现了一个文件〜/ .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的评论和随后的testing，这似乎是发生在4.2.0-15.0.1.el7.centos.17但不是在4.2.0-15.0.1.el7.centos.6.1，我相信是由于相应的libss升级到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服务器上没有启用，现在它仍然不是快乐。