Hi Jakub, thanks for looking through the data.
I can not access the bug you mentioned. I already created an account for Bugzilla, but so far nothing. In the second query there is a group which isn't present in the first one ((sudoUser=%ug_freeipa-administrators_int)). This is the IPA-equivalent of the AD-Group (ug_freeipa-administrators). AD -> IPA_EXT -> IPA_INT The second command you mentioned works and returns the correct passwd entry for my user. The first command ist not found on the client. Best regards, Fabian ________________________________________ From: Jakub Hrozek [[email protected]] Sent: Monday, October 12, 2015 11:47 To: Zoske, Fabian Cc: [email protected] Subject: Re: [Freeipa-users] SUDO does not always works on first try On Fri, Oct 09, 2015 at 11:04:15AM +0000, Zoske, Fabian wrote: > Hi Jakub, > > I increased the log level in every SSSD section to 6 and got following > output, hope that helps. > > KRB5_CHILD.LOG: https://s.mit42.de/IR6tu All is OK here.. > > SSSD_SUDO.LOG (two tries are logged in it): https://s.mit42.de/WF1Jl So the interesting part is that the first try doesn't match any rules for the user: (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)([email protected])(sudoUser=#1948403038)(sudoUser=%[email protected])(sudoUser=%domä[email protected])(sudoUser=+*)))] (Fri Oct 9 12:24:09 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [[email protected]] While the second does: (Fri Oct 9 12:24:14 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)([email protected])(sudoUser=#1948403038)(sudoUser=%[email protected])(sudoUser=%domä[email protected])(sudoUser=%admins)(sudoUser=%ug_freeipa-administrators_int)(sudoUser=+*)))] (Fri Oct 9 12:24:14 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 2 rules for [[email protected]] It would be interesting to see the dump of the cache from when 0 rules are returned. I suspect the user's membership wouldn't be correct, which might be because of the bug I linked earlier. > > SSSD_IPA-LX.COM: https://s.mit42.de/frBvx There are some failures here: (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: No such object(32), (null) (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=*] (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [be_req_set_domain] (0x0400): Changing request domain from [ipa-lx.com] to [de.eu.local] (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Fri Oct 9 12:24:19 2015) [sssd[be[ipa-lx.com]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: No such object(32), (null) But I think this is a really minor bug we fixed later where we marked requests as failed if they simply didn't find anything. If this works without issues: $ sss_cache -u [email protected] $ getent passwd [email protected] Then you can ignore those.. -- 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
