Thanks Jakub, turns out 'getent password [email protected]' only works on 1 of the 4 ipa servers (the one I created the domain trust with).
I re-ran ipa-adtrust-install on them and no change, is there a similar post I can follow to correct these & retrace my steps or does the trust need configured on each. Thank You, -Jake ----- Original Message ----- From: "Jakub Hrozek" <[email protected]> To: "Jake" <[email protected]> Cc: [email protected] Sent: Wednesday, August 3, 2016 3:51:26 PM Subject: Re: [Freeipa-users] Login Troubles with Centos7 and external users (4.2.0-15.0.1.el7.centos.17) > On 3 Aug 2016, at 20:14, Jake <[email protected]> wrote: > > Hello All, > I'm new to FreeIPA and am having some issues with my endpoints. > > First attempts to login as [email protected] always fail with: > Logs on client: > sshd[3771]: Invalid user [email protected] from 192.168.1.123 > sshd[3771]: input_userauth_request: invalid user [email protected] > [preauth] > > [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for > [0x1001][1][name=username] > [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): > ldap_extended_operation result: No such object(32), (null). > [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop > request failed. > [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. > Returned 0,0,Success (Success) > [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for > [0x1003][1][name=NOUSER] > [sssd[be[ipa.example.com]]] [sysdb_get_real_name] (0x0040): > sysdb_search_object_by_uuid did not return a single result. > [sssd[be[ipa.example.com]]] [groups_by_user_done] (0x0040): Failed to > canonicalize name, using [NOUSER]. > [sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): > Object not found, ending request > [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. > Returned 3,0,Account info lookup failed > [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for > [0x1001][1][idnumber=1644425765] > [sssd[be[ipa.example.com]]] [sdap_get_users_done] (0x0040): Failed to > retrieve users > [sssd[be[ipa.example.com]]] [ipa_id_get_account_info_orig_done] (0x0080): > Object not found, ending request > [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. > Returned 3,0,Account info lookup failed > [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for > [0x1001][1][idnumber=1644425765] > [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): > ldap_extended_operation result: No such object(32), (null). > [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop > request failed. > [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. > Returned 0,0,Success (Success) > [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for > [0x1001][1][idnumber=1644425765] > [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): > ldap_extended_operation result: No such object(32), (null). > [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop > request failed. > [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. > Returned 0,0,Success (Success) > [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for > [0x1001][1][idnumber=1644425765] > [sssd[be[ipa.example.com]]] [ipa_s2n_exop_done] (0x0040): > ldap_extended_operation result: No such object(32), (null). > [sssd[be[ipa.example.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop > request failed. OK, here looking up an ID failed. It would be interesting to see what happened with this lookup on the server. Normally I try to truncate the logs on both the server and the client, then run: date; id $username; date that allows to correlate logs from the server and the client and better pinpoint what fails.. > [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. > Returned 0,0,Success (Success) > > running the command 'getent password [email protected]' on the ipa > server works fine > > Logs from server: > [sssd[be[ipa.example.com]]] [be_get_account_info] (0x0200): Got request for > [0x1001][1][name=username] > [sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0080): Sudomain > lookup failed, will try to reset sudomain.. This log line doesn't look so successful :-) but as long as the server returns 'something' from the cache, the client should grab it > [sssd[be[ipa.example.com]]] [child_sig_handler] (0x0100): child [26269] > finished successfully. > [sssd[be[ipa.example.com]]] [set_srv_data_status] (0x0100): Marking SRV > lookup of service 'legacy.example.org' as 'neutral' > [sssd[be[ipa.example.com]]] [fo_set_port_status] (0x0100): Marking port 0 of > server '(no name)' as 'neutral' > [sssd[be[ipa.example.com]]] [ipa_srv_ad_acct_lookup_done] (0x0040): > ipa_get_*_acct request failed: [1432158262]: Subdomain is inactive. > [sssd[be[ipa.example.com]]] [ipa_subdomain_account_done] (0x0040): > ipa_get_*_acct request failed: 1432158262 > [sssd[be[ipa.example.com]]] [ipa_account_info_error_text] (0x0020): Bug: > dp_error is OK on failed request > [sssd[be[ipa.example.com]]] [acctinfo_callback] (0x0100): Request processed. > Returned 3,1432158262,Account info lookup failed > > > Stuff: > (4) IPA Masters at ipa.example.com > (4) root domain controllers in example.com > (4) child domain controllers in new.example.com > (4) second domain in legacy.example.org > > There is a (1) way trust between ipa.example.com and example.com (forest > trust) Are all the replicas either trust masters or was ipa-adtrust-install ran on all of them? > There is a (1) way trust between ipa.example.com and legacy.example.org > (forest with single domain) > There is a (2) way trust between example.com and legacy.example.org (forest > transitive trust) > > Users are in legacy.example.org and new.example.com > User Computers are in new.example.com > Linux Servers are in ipa.example.com as hostname linux.example.com > > Gist for kbr5.conf > https://gist.github.com/JakeDEvans/8e787bc5751d3d0e8f3b18943d63f00b > Gist for sssd.conf > https://gist.github.com/JakeDEvans/ed34098b96b6e061095da85e1db58d70 > > all other configs unmodified. > > Also, is it normal that the login is very slow? If there is a lot of large groups the login can be very slow. We summarized the known workarounds here: https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/ and improved the performance quite a bit in rhel-7.3 > > Thanks All, > -Jake > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
