Hi Jakub, I think there is a package missing. When I try to install the packages you provided, yum exits with an error. " Requires: python-sssdconfig = 1.12.2-58.el7_1.18 "
Can you provide me this package or tell me where to find it? Best regards, Fabian -----Ursprüngliche Nachricht----- Von: Jakub Hrozek [mailto:[email protected]] Gesendet: Freitag, 16. Oktober 2015 10:32 An: Zoske, Fabian Cc: [email protected] Betreff: Re: [Freeipa-users] SUDO does not always works on first try On Tue, Oct 13, 2015 at 07:19:20AM +0000, Zoske, Fabian wrote: > Hi Jakub, > > thanks for looking through the data. Sorry for late reply. > > I can not access the bug you mentioned. I already created an account for > Bugzilla, but so far nothing. Ah, it's probably marked as private b/c it contains some private customer information.. > > 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 Then it sounds like the bug we solved lately, can you try installing these packages on the IPA server (yes, server, not client): https://jhrozek.fedorapeople.org/sssd-test-builds/sssd-7.1-external-group/ > > 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
