Estou tendo problemas com 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 fazer login sem problemas em qualquer host, mas em alguns hosts eles não podem executar comandos sudo.
O que eu sei:
Há uma política IPA sudo que é 'permitir que este usuário execute qualquer comando em qualquer host' e também uma política HBAC de 'permitir que este usuário use qualquer serviço em qualquer host', então acho que posso descartar a política IPA como um problema .
Isso só parece afetar as máquinas quando elas entram em contato com um servidor ipa específico (através do registro dns srv), de acordo com o tcpdump, que determinei limpando o sss_cache e fazendo sudo -k. Uma das máquinas em questão é, na verdade, o próprio servidor ipa, então descartei a rede / firewalls como a causa. Tenho certeza de que está limitado apenas a esse servidor ipa e aos clientes que usam esse servidor ipa específico.
Focando apenas no próprio servidor ipa e comparando-o com um dos meus outros servidores ipa, sudo.conf, sudoers, sssd.conf são idênticos (menos a depuração sendo adicionada ao quebrado). Ambos têm seu IP da LAN em /etc/hosts e ambos usam ntpd (o que eu acho que exclui problemas de temporização do Kerberos). Além de ativar a depuração, os arquivos sssd.conf e sudo.conf não são alterados na instalação limpa.
O servidor ipa quebrado foi o primeiro instalado, então é o master ca etc.
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
Logs: (nome de domínio e usuário higienizados)
=-=-=- 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 errado, 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 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
Edit1: Ok, por sugestão de 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]
ldbsearch dá 0 resultados, mas também mostra 'asq: Unable to register control with rootdse!' (embora diga isso 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 dá 3 nos outros servidores de autenticação, então acho que está de alguma forma relacionado à replicação, mas a questão agora é como consertar isso.
Edit2: 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, obtenho 48 registros no servidor quebrado e 51 nos outros. Apenas as 3 entradas da regra sudo estão faltando.
Eu fiz essas regras sudo em um dos servidores ipa em funcionamento, então sou levado 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. Há um firewall entre eles, mas a criação do usuário em um servidor ipa em funcionamento é replicada para o servidor ipa quebrado, então não sei se posso descartar o firewall. É importante notar, no entanto, que embora eu ache que todas as portas são permitidas entre eles, o servidor quebrado está em uma sub-rede DMZ, então não permito a porta 22 (ssh) de volta desse servidor ipa para os outros. Não sei se isso importa? No entanto, fiz o script conncheck e ele disse que tudo estava OK ou aviso para as duas portas que estavam em uso pelo próprio ipa
Edit3: OK, então fazer uma regra sudo no servidor quebrado que afeta todos os servidores (portanto, 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 aparece em sssd. Portanto, 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: Pelos 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 foi devido à atualização correspondente de libsss para 1.13.0.40.el7_2.9
Acredito que esteja relacionado a: https://fedorahosted.org/sssd/ticket/1108
e
https://bugzilla.redhat.com/show_bug.cgi?id=1256849
mas agora eu só preciso trabalhar em uma correção para isso. a árvore ipa-compat não estava habilitada no servidor ipa 'quebrado', agora está, mas ainda sem alegria.
Isso parece estar relacionado ao seguinte bug: https://fedorahosted.org/sssd/ticket/1108
e
https://bugzilla.redhat.com/show_bug.cgi?id=1256849
a sugestão de habilitar a árvore de compatibilidade parece ter funcionado, depois de permitir cerca de 30 minutos para o cache do sssd expirar na rede .
Resumindo, você precisa garantir que a árvore de compatibilidade esteja habilitada no ipa para que o sssd armazene em cache as regras do sudo corretamente. Eu desliguei a árvore de compatibilidade no único servidor ipa 'quebrado' e, quando os clientes estavam conversando com esse servidor ipa específico (via registro DNS SRV), eles não estavam armazenando em cache nenhuma regra sudo. Isso se manifesta por máquinas às vezes capazes de permitir que os usuários sudo e às vezes não. Como o próprio servidor ipa não usa o registro SRV, mas usa a si mesmo, o sudo no servidor ipa sempre foi interrompido.
Executar 'ipa-compat-manage enable' no servidor ipa e esperar que o cache sssd expire parece ter resolvido o problema.