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

[Zoske, Fabian]

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:jhrozek at redhat.com] 
Gesendet: Freitag, 16. Oktober 2015 10:32
An: Zoske, Fabian
Cc: freeipa-users at redhat.com
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 [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..