Thanks Jakub,
turns out 'getent password usern...@legacy.example.org' 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" <jhro...@redhat.com>
To: "Jake" <free...@jacobdevans.com>
Cc: freeipa-users@redhat.com
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 <free...@jacobdevans.com> wrote:
> 
> Hello All,
> I'm new to FreeIPA and am having some issues with my endpoints.
> 
> First attempts to login as usern...@legacy.example.org always fail with:
> Logs on client:
> sshd[3771]: Invalid user usern...@legacy.example.org from 192.168.1.123
> sshd[3771]: input_userauth_request: invalid user usern...@legacy.example.org 
> [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 usern...@legacy.example.org' 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

Reply via email to