Instalei um IPA Server, criei um contrato de réplica e configurei uma confiança unidirecional para nossa floresta de AD. Os servidores IPA possuem DNS integrado e estão em sua própria zona dns. Isso funciona como esperado, eu sou capaz de fazer login nos servidores IPA com minha conta do AD.
Meu problema é ao configurar um cliente, posso usar usuários do IPA (ex. admin), mas não consigo autenticar / fazer login com minha conta do AD.
Executando um teste do HBAC no servidor IPA, verifique se meu usuário do AD tem acesso ao cliente. Também posso obter com êxito um ticket do kerberos para os usuários do AD no meu cliente IPA.
Quando executo um ID na conta do AD do cliente IPA, recebo um
unknown user error
Quando eu tento ssh, o log seguro é mostrado, usuário ilegal / usuário desconhecido para o módulo de autenticação subjacente.
[domain/ipa.us.example.com]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.us.example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = ipaclient.us.example.com
chpass_provider = ipa
ipa_server = _srv_, ipaserver02.ipa.us.example.com
dns_discovery_domain = ipa.us.example.com
subdomain_inherit = ignore_group_members
ignore_group_members = True
debug_level = 6
[sssd]
domains = ipa.us.example.com
config_file_version = 2
services = nss, sudo, pam, ssh, pac
subdomain_enumerate = all
debug_level = 6
[nss]
debug_level = 6
homedir_substring = /home
#File modified by ipa-client-install
includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = IPA.US.EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = true
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
IPA.US.EXAMPLE.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.ipa.us.example.com = IPA.US.EXAMPLE.COM
ipa.us.example.com = IPA.US.EXAMPLE.COM
ipaclient.us.example.com = IPA.US.EXAMPLE.COM
.us.example.com = IPA.US.EXAMPLE.COM
us.example.com = IPA.US.EXAMPLE.COM
May 17 10:23:23 lxmatazan100s sshd[8256]: reverse mapping checking getaddrinfo for dhcp-ngkusernetworkuzo-1921690252.revonly.kn [192.169.0.252] failed - POSSIBLE BREAK-IN ATTEMPT!
May 17 10:23:47 lxmatazan100s sshd[8256]: Invalid user [email protected] from 192.169.0.252
May 17 10:23:47 lxmatazan100s sshd[8256]: input_userauth_request: invalid user [email protected] [preauth]
May 17 10:23:50 lxmatazan100s sshd[8256]: Failed password for invalid user [email protected] from 192.169.0.252 port 51819 ssh2
May 17 10:23:53 lxmatazan100s sshd[8256]: Failed password for invalid user [email protected] from 192.169.0.252 port 51819 ssh2
May 17 10:23:56 lxmatazan100s sshd[8256]: Failed password for invalid user [email protected] from 192.169.0.252 port 51819 ssh2
May 17 10:23:56 lxmatazan100s sshd[8256]: error: PAM: User not known to the underlying authentication module for illegal user [email protected] from 192.169.0.252
May 17 10:23:56 lxmatazan100s sshd[8256]: Failed keyboard-interactive/pam for invalid user [email protected] from 192.169.0.252 port 51819 ssh2
May 17 10:23:56 lxmatazan100s sshd[8256]: Connection closed by 192.169.0.252 [preauth]
(Wed May 17 08:25:50 2017) [sssd[be[ipa.us.example.com]]] [_dp_req_recv] (0x0400): DP Request [Account #134]: Receiving request data.
(Wed May 17 08:25:50 2017) [sssd[be[ipa.us.example.com]]] [dp_req_reply_gen_error] (0x0080): DP Request [Account #134]: Finished. Backend is currently offline.
(Wed May 17 08:25:50 2017) [sssd[be[ipa.us.example.com]]] [dp_table_value_destructor] (0x0400): Removing [0:1:0x0001:1:1:U:usa.win.example.com:[email protected]] from reply table
(Wed May 17 08:25:50 2017) [sssd[be[ipa.us.example.com]]] [dp_req_destructor] (0x0400): DP Request [Account #134]: Request removed.
(Wed May 17 08:25:50 2017) [sssd[be[ipa.us.example.com]]] [dp_req_destructor] (0x0400): Number of active DP request: 0
(Novamente, eles existem para cada domínio na floresta do AD)
(Wed May 17 08:25:50 2017) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [[email protected]]
(Wed May 17 08:25:50 2017) [sssd[nss]] [sysdb_search_user_by_upn] (0x0400): No entry with upn [[email protected]] found.
(Wed May 17 08:25:50 2017) [sssd[nss]] [get_dp_name_and_id] (0x0400): Not a LOCAL view, continuing with provided values.
(Wed May 17 08:25:50 2017) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f99f622c880:1:[email protected]:[email protected]]
(Wed May 17 08:25:50 2017) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [usa.win.example.com][0x1][BE_REQ_USER][1][[email protected]:U]
(Wed May 17 08:25:50 2017) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f99f622c880:1:[email protected]:[email protected]]
(Wed May 17 08:25:50 2017) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f99f622c880:1:[email protected]:[email protected]]
(Wed May 17 08:25:50 2017) [sssd[nss]] [sss_dp_get_reply] (0x0010): The Data Provider returned an error [org.freedesktop.sssd.Error.DataProvider.Offline]
(Wed May 17 08:25:50 2017) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider
Error: 3, 5, Failed to get reply from Data Provider
Will try to return what we have in cache
A única coisa que me resta a tentar é mover o cliente para o domínio dns ipa.us.example.com, embora a documentação menciona especificamente que os clientes não precisam estar no mesmo domínio dns que o servidor.
EDIT ** - Eu já havia comentado uma linha /etc/pam.d/password-auth pensando que a autenticação de usuários era ipa (não confiável). Estou agora a pensar que permite a qualquer utilizador autenticar porque, quando removi o utilizador da regra do HBAC, eles ainda podiam autenticar. Eu descomentei a linha e agora os usuários do IPA não conseguem autenticar. Ainda posso fazer uma pesquisa para esses usuários (e não para usuários do AD).
/etc/pam.d/password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth [default=1 success=ok] pam_localuser.so
auth [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
#The following line is what I had commented out
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session optional pam_oddjob_mkhomedir.so umask=0077
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
EDIT # 2 **
Agora que usuários ipa trabalharam com meu cliente, tive que incluir "selinux_provider = none" na seção [domain / ipa.us.example.com] do sssd.conf. Os usuários do Trust AD ainda estão falhando com os mesmos erros.