ipaユーザーは、ipaサーバーを含む一部のマシンでのみSudoを実行できません
いくつかのマシンでfreeipaに問題があります。これまでのところ、デバッグするのは非常にイライラしています。問題の詳細は次のとおりです。
それがどのように現れるか：
ユーザーはどのホストにも問題なくログインできますが、一部のホストではSudoコマンドを実行できません。
私が知っていること：
「このユーザーが任意のホストで任意のコマンドを実行できるようにする」というIPASudoポリシーと、「このユーザーが任意のホストで任意のサービスを使用できるようにする」というHBACポリシーがあるため、IPAポリシーが問題になることはないと思います。 。
Sss_cacheをフラッシュしてSudo-kを実行することで決定した、tcpdumpによると、これは特定のipaサーバーに（dns srvレコードを介して）接続するときにのみマシンに影響を与えるようです。問題のマシンの1つは、実際にはそのipaサーバー自体であるため、ネットワーク/ファイアウォールが原因であるとは除外しました。私はそれがそのipaサーバーとその特定のipaサーバーを使用しているクライアントだけに限定されていると確信しています。
そのipaサーバー自体だけに焦点を当て、それを他のipaサーバーの1つと比較すると、Sudo.conf、sudoers、sssd.confは同じです（壊れたサーバーにデバッグが追加されます）。どちらも/ etc/hostsにLANIPがあり、どちらもntpdを使用しています（これにより、Kerberosのタイミングの問題が除外されると思います）。デバッグをオンにする以外に、sssd.confファイルとSudo.confファイルはクリーンインストールから変更されません。
壊れたipaサーバーが最初にインストールされたので、マスターcaなどです。
問題のマシンのSudo（簡単にするために壊れたipaサーバー自体に焦点を当てています）は、/ etc/sudoersファイルや/ etc/passwdなどでローカルに定義されているユーザーに対して機能します。
詳細：
すべてのマシンはcentos7とipa4.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が（同じマシン上の）Kerberosを介してIPAと通信するsssdと話しているように見えます。それは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
Edit1：OK、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)'
他の認証サーバーでは3を与えるのに対し、0を与えるので、何らかの形でレプリケーションに関連していると思いますが、問題はそれを修正する方法です。
Edit2：奇妙なことに、壊れたサーバー上
ipa sudorule-find All
3つのルールを返します！？壊れたサーバー上のsssdキャッシュファイルを削除してsssdを再起動しようとしましたが、ldbsearchで0個のルールが見つかりました。
フィルタなしでldbsearchを実行すると、壊れたサーバーで48レコード、その他のサーバーで51レコードが取得されます。 3つのSudoルールエントリのみが欠落しています。
動作しているipaサーバーの1つでこれらのSudoルールを作成したので、sysdbテーブルに対してレプリケーションが機能していないか、Sudoルールに対してのみ機能していないと思われます。それらの間にファイアウォールがありますが、動作中のipaサーバーでのユーザー作成[〜＃〜]は[〜＃〜]が壊れたipaサーバーに複製されているので、ファイアウォールを除外できます。ただし、すべてのポートがそれらの間で許可されていると思いますが、壊れたサーバーはDMZサブネットにあるため、そのipaサーバーからポート22（ssh）に戻ることはできません。それが重要かどうかはわかりませんが、conncheckスクリプトを実行したところ、ipa自体が使用していた2つのポートに対してすべてがOKまたは警告であると表示されました。
Edit3：OK、壊れたサーバーですべてのサーバーに影響するSudoルールを作成すると（したがって、sssdにキャッシュする必要があります）、新しいルールがUI（および他の3つ）に表示されますが、表示されますnotは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)
それが赤いニシンなのか煙を吐く銃なのかわかりませんか？
Edit4：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サーバーで有効にされていませんでしたが、今では有効になっていますが、それでも喜びはありません。
これは次のバグに関連しているようです： https://fedorahosted.org/sssd/ticket/1108
そして
https://bugzilla.redhat.com/show_bug.cgi?id=1256849
互換性ツリーを有効にするという提案は、ネットワーク全体でsssdキャッシングが期限切れになるまで約30分待った後、トリックを実行したようです。
つまり、sssdがSudoルールを正しくキャッシュするには、ipaで互換性ツリーが有効になっていることを確認する必要があります。 1つの「壊れた」ipaサーバーで互換性ツリーをオフにしました。クライアントがその特定のipaサーバーと（DNS SRVレコードを介して）通信しているとき、Sudoルールをキャッシュしていませんでした。これは、マシンがユーザーにSudoを許可できる場合とできない場合があることで明らかになりました。 ipaサーバー自体はSRVレコードを使用せず、代わりに自分自身を使用するため、ipaサーバー上のSudoは常に壊れていました。
Ipaサーバーで「ipa-compat-manageenable」を実行し、sssdキャッシュの有効期限が切れるのを待つことで、問題が解決したようです。