Пользователи ipa не могут использовать sudo только на некоторых машинах, включая сервер ipa

У меня проблемы с freeipa на нескольких машинах. До сих пор было очень сложно отлаживать. Вот подробности проблемы;

Как это проявляется:

Пользователь может нормально войти на любой хост, но на некоторых хостах они не могут запускать команды sudo.

Что я знаю:

Существует политика sudo IPA, которая `` разрешить этому пользователю запускать любую команду на любом хосте '', а также политика HBAC `` разрешить этому пользователю использовать любую службу на любом хосте '', поэтому я думаю, что могу исключить политику IPA, являющуюся проблемой .

Похоже, что это влияет на машины только тогда, когда они связываются с одним конкретным сервером ipa (через запись dns srv), согласно tcpdump, который я определил, очистив sss_cache и выполнив sudo -k. Одна из машин, о которых идет речь, на самом деле является самим сервером ipa, поэтому я исключил сетевые / межсетевые экраны, являющиеся причиной. Я почти уверен, что это ограничено только этим сервером ipa и клиентами, использующими этот конкретный сервер ipa.

Сосредоточившись только на этом сервере ipa и сравнив его с одним из моих других серверов ipa, sudo.conf, sudoers, sssd.conf идентичны (за вычетом отладки, добавленной к сломанному). У обоих есть свой сетевой IP-адрес в / etc / hosts, и оба используют ntpd (что, как мне кажется, исключает проблемы синхронизации Kerberos). Помимо включения отладки, файлы sssd.conf и sudo.conf остаются нетронутыми при чистой установке.

Сломанный сервер ipa был установлен первым, так что это главный сервер и т. Д.

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, который общается с IPA через kerberos (на той же машине). Это говорит ОК, затем 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: Хорошо, по предложению от 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 на других серверах аутентификации, поэтому я предполагаю, что это как-то связано с репликацией, но теперь вопрос в том, как это исправить.

Edit2: Как ни странно, на сломанном сервере

ipa sudorule-find All

возвращает 3 правила !? Я попытался удалить файл кеша sssd на сломанном сервере и перезапустить sssd, но ldbsearch по-прежнему дает 0 найденных правил.

Если я выполняю ldbsearch без фильтра, я получаю 48 записей на сломанном сервере и 51 на других. Отсутствуют только 3 записи правила sudo.

Я создал эти правила sudo на одном из рабочих серверов ipa, поэтому я пришел к выводу, что либо репликация не работает для таблицы sysdb, либо она не работает только для ее правил sudo. Между ними есть межсетевой экран, но создание пользователя на рабочем ipa сервере ЯВЛЯЕТСЯ реплицируется на сломанный сервер ipa, поэтому я не знаю, могу ли я исключить брандмауэр. Однако стоит отметить, что, хотя я думаю, что все порты между ними разрешены, сломанный сервер находится в подсети DMZ, поэтому я не разрешаю порт 22 (ssh) обратно с этого сервера ipa другим. Я не знаю, имеет ли это значение? Однако я выполнил сценарий conncheck, и он сказал, что все в порядке или предупреждение для двух портов, которые использовались самим ipa

Edit3: ОК, поэтому создание правила sudo на сломанном сервере, которое влияет на все серверы (поэтому оно должно быть кэшировано в sssd), заставляет новое правило отображаться в пользовательском интерфейсе (а также 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)

Я не знаю, отвлекающий маневр это или дымящийся пистолет?

Edit4: Из комментариев Данилы Ладнера и последующего тестирования, похоже, что это происходит в 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, теперь оно есть, но все равно без радости.