Estou tendo problemas com o freeipa em algumas máquinas. Tem sido muito frustrante depurar até agora. Aqui estão os detalhes do problema;
Como se manifesta:
O usuário pode logar muito bem em qualquer host, mas em alguns hosts eles não podem executar comandos sudo.
O que eu sei:
Existe uma política IPA sudo que 'permite que este usuário execute qualquer comando em qualquer host' e também uma diretiva HBAC de 'permitir que este usuário use qualquer serviço em qualquer host', então acho que posso descartar a diretiva IPA sendo um problema.
Isso só parece afetar as máquinas quando elas entram em contato com um servidor ipa em particular (através do registro dns srv), de acordo com o tcpdump, que eu determinei ao liberar o sss_cache e fazer o sudo -k. Uma das máquinas em questão é, na verdade, o próprio servidor ipa, então descartei a causa da rede / firewalls. Tenho certeza de que é limitado apenas àquele servidor ipa e aos clientes que usam esse servidor ipa em particular.
Focando apenas no próprio servidor ipa, e comparando-o com um dos meus outros servidores ipa, o sudo.conf, sudoers, sssd.conf são idênticos (menos a depuração sendo adicionada à quebrada). Ambos têm seu ip de LAN em / etc / hosts, e ambos usam o ntpd (que eu acho que exclui os problemas de tempo do kerberos). Além de ativar a depuração, o sssd.conf e os arquivos sudo.conf são intocados da instalação limpa.
O servidor ipa quebrado foi o primeiro instalado, por isso é o master ca etc.
O sudo na máquina em questão (estou focando no próprio servidor ipa quebrado para simplificar) funciona para usuários que são definidos localmente no arquivo / etc / sudoers, / etc / passwd, etc.
Detalhes:
Todas as máquinas estão usando centos 7 e ipa 4.2.0
Registros: (nome de domínio e usuário limpos)
=-=-=- 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
A menos que eu esteja lendo isso erroneamente, parece-me que o sudo está falando com o sssd, que fala com o IPA via kerberos (na mesma máquina). Isso diz OK, então sudo ... por algum motivo, rejeita isso e diz que não de qualquer maneira?
Configs: (do servidor ipa quebrado)
=-=-=- 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
Editar1:
Ok, sugiro do jhrozek também habilitei a depuração na seção [sudo], que fornece isso nos logs:
(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]
O ldbsearch fornece 0 resultados, mas também mostra 'asq: Não é possível registrar o controle com o rootdse!' (embora diga que nos outros servidores também)
no servidor quebrado
ldbsearch -H /var/lib/sss/db/cache_domain.com.ldb -b cn=sysdb '(objectClass=sudoRule)'
dá 0, enquanto que dá 3 nos outros servidores de autenticação, então eu acho que é de alguma forma relacionado à replicação, mas a questão agora é como consertar isso.
Editar2:
Estranhamente, no servidor quebrado
ipa sudorule-find All
retorna as 3 regras! Eu tentei remover o arquivo de cache sssd no servidor quebrado e reiniciar o sssd, mas o ldbsearch ainda fornece 0 regras encontradas.
Se eu fizer ldbsearch sem filtro eu recebo 48 registros no servidor quebrado e 51 nos outros. Apenas as entradas da regra 3 sudo estão faltando.
Eu fiz estas regras sudo em um dos servidores ipa de trabalho, então eu levei a acreditar que a replicação não está funcionando para a tabela sysdb, ou não está funcionando apenas para as regras sudo dela. Existe um firewall entre eles, mas a criação do usuário em um servidor ipa em funcionamento IS é replicada para o servidor ipa corrompido, então não sei se posso descartar o firewall. No entanto, é importante notar que, embora eu ache que todas as portas são permitidas entre elas, o servidor quebrado está em uma sub-rede DMZ, portanto, não permito que a porta 22 (ssh) volte desse servidor ipa para as outras. Eu não sei se isso importa? No entanto, fiz o script conncheck e ele disse que tudo estava OK ou alertando para as duas portas que estavam sendo usadas pelo próprio ipa
Editar3:
OK, então fazer uma regra sudo no servidor quebrado que afeta todos os servidores (por isso, deve ser armazenado em cache no sssd) faz com que a nova regra apareça na interface do usuário (assim como as outras 3) mas não aparecem em sssd. Então, parece que o sssd não está armazenando as regras corretamente.
Acabei de encontrar um arquivo ~ / .ipa / log / cli.log, que no servidor quebrado (somente) tem
2016-05-29T22:59:23Z 6583 MainThread ipa ERROR Certificate operation cannot be completed: Unable to communicate with CMS (Internal Server Error)
Eu não sei se isso é um arenque vermelho ou uma arma fumegante?
Edit4: A partir dos comentários de Danila Ladner e testes subsequentes, isso parece ocorrer em 4.2.0-15.0.1.el7.centos.17 mas não em 4.2.0-15.0.1.el7.centos.6.1 que eu acredito que foi devido à atualização correspondente de libsss para 1.13.0.40.el7_2.9
Acredito que esteja relacionado a:
link
e
link
mas agora só preciso de uma solução para isso. o ipa-compat tree não foi habilitado no servidor ipa 'quebrado', agora é, mas ainda não há alegria.