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

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

Reply via email to