[Freeipa-users] SUDO does not always works on first try

[Jakub Hrozek]

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 [jhrozek at redhat.com]
> Sent: Monday, October 12, 2015 11:47
> To: Zoske, Fabian
> Cc: freeipa-users at redhat.com
> 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)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%domänen-benutzer at de.eu.local)(sudoUser=+*)))]
>     (Fri Oct  9 12:24:09 2015) [sssd[sudo]]
>     [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for
>     [f.zoske at de.eu.local]
> 
> 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)(sudoUser=f.zoske at de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-administrators at de.eu.local)(sudoUser=%domänen-benutzer at de.eu.local)(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
>     [f.zoske at de.eu.local]
> 
> 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 f.zoske at de.eu.local
>     $ getent passwd f.zoske at de.eu.local
> 
> Then you can ignore those..