Discussion:
SUDO does not always works on first try
(too old to reply)
Zoske, Fabian
2015-10-02 06:35:41 UTC
Permalink
Hi folks,

we recently setup an IPA-Server on Centos 7.1 and connected some Ubuntu 14.04 LTS machines to this server.
The IPA-Realm is just for configuring the clients, such as HBAC and SUDO. The user information are stored in an AD to which we established a two-way trust.

Our problem is now, that sudo sometimes tells us, that a user is not allowed to run SUDO on that machine. But on the second try he can execute the command which failed the first time.

Any ideas, whats wrong?

Best regards,
Fabian Zoske
Jakub Hrozek
2015-10-02 13:05:08 UTC
Permalink
On Fri, Oct 02, 2015 at 06:35:41AM +0000, Zoske, Fabian wrote:
> Hi folks,
>
> we recently setup an IPA-Server on Centos 7.1 and connected some Ubuntu 14.04 LTS machines to this server.
> The IPA-Realm is just for configuring the clients, such as HBAC and SUDO. The user information are stored in an AD to which we established a two-way trust.
>
> Our problem is now, that sudo sometimes tells us, that a user is not allowed to run SUDO on that machine. But on the second try he can execute the command which failed the first time.
>
> Any ideas, whats wrong?

Not without logs, sorry. We need both from sudo itself and SSSD.

But the closes that comes to mind is:
https://bugzilla.redhat.com/show_bug.cgi?id=1247539

--
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
Zoske, Fabian
2015-10-05 13:25:09 UTC
Permalink
Dear Jakub,

I found only the following entries in the /var/log/auth.log:

Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): conversation failed
Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): auth could not identify password for [***@de.eu.local]
Oct 5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): authentication failure; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
Oct 5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): received for user ***@de.eu.local: 7 (Authentication failure)
Oct 5 11:57:38 hl-srv10 sudo: ***@de.eu.local : user NOT authorized on host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/cat /etc/sssd/sssd.conf
Oct 5 11:57:42 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
Oct 5 11:57:42 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
Oct 5 11:57:43 hl-srv10 sudo: ***@de.eu.local : user NOT authorized on host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash
Oct 5 11:57:46 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
Oct 5 11:57:47 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
Oct 5 11:57:47 hl-srv10 sudo: ***@de.eu.local : TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash
Oct 5 11:57:47 hl-srv10 sudo: pam_unix(sudo:session): session opened for user root by ***@de.eu.local(uid=0)<mailto:***@de.eu.local(uid=0)>

In /var/log/sssd/ no entries were logged.

My sssd.conf:
[domain/ipa-lx.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa-lx.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = hl-srv10.ipa-lx.com
chpass_provider = ipa
ipa_server = _srv_, dc01.ipa-lx.com
ldap_tls_cacert = /etc/ipa/ca.crt
ldap_sudo_use_host_filter = false

[sssd]
services = nss, pam, ssh, sudo
config_file_version = 2
default_domain_suffix = de.eu.local
domains = ei-ag.it

[nss]
override_shell = /bin/bash

[pam]

[sudo]

[autofs]

[ssh]

[pac]


Best regards,
Fabian
Jakub Hrozek
2015-10-07 08:02:41 UTC
Permalink
On Mon, Oct 05, 2015 at 01:25:09PM +0000, Zoske, Fabian wrote:
> Dear Jakub,
>
> I found only the following entries in the /var/log/auth.log:
>
> Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): conversation failed
> Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): auth could not identify password for [***@de.eu.local]
> Oct 5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): authentication failure; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
> Oct 5 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): received for user ***@de.eu.local: 7 (Authentication failure)
> Oct 5 11:57:38 hl-srv10 sudo: ***@de.eu.local : user NOT authorized on host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/cat /etc/sssd/sssd.conf
> Oct 5 11:57:42 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
> Oct 5 11:57:42 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
> Oct 5 11:57:43 hl-srv10 sudo: ***@de.eu.local : user NOT authorized on host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash
> Oct 5 11:57:46 hl-srv10 sudo: pam_unix(sudo:auth): authentication failure; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
> Oct 5 11:57:47 hl-srv10 sudo: pam_sss(sudo:auth): authentication success; logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost= user=***@de.eu.local
> Oct 5 11:57:47 hl-srv10 sudo: ***@de.eu.local : TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash
> Oct 5 11:57:47 hl-srv10 sudo: pam_unix(sudo:session): session opened for user root by ***@de.eu.local(uid=0)<mailto:***@de.eu.local(uid=0)>
>
> In /var/log/sssd/ no entries were logged.

Nothing gets logged in by default, you need to increase debug_level,
see:
https://fedorahosted.org/sssd/wiki/Troubleshooting

I would look into the domain log and krb5_child.log first

>
> My sssd.conf:
> [domain/ipa-lx.com]
>
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = ipa-lx.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = hl-srv10.ipa-lx.com
> chpass_provider = ipa
> ipa_server = _srv_, dc01.ipa-lx.com
> ldap_tls_cacert = /etc/ipa/ca.crt
> ldap_sudo_use_host_filter = false
>
> [sssd]
> services = nss, pam, ssh, sudo
> config_file_version = 2
> default_domain_suffix = de.eu.local
> domains = ei-ag.it
>
> [nss]
> override_shell = /bin/bash
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
>
>
> Best regards,
> Fabian

> --
> 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

--
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
Zoske, Fabian
2015-10-09 11:04:15 UTC
Permalink
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

SSSD_SUDO.LOG (two tries are logged in it): https://s.mit42.de/WF1Jl

SSSD_IPA-LX.COM: https://s.mit42.de/frBvx

Best regards,
Fabian

-----Ursprüngliche Nachricht-----
Von: freeipa-users-***@redhat.com [mailto:freeipa-users-***@redhat.com] Im Auftrag von Jakub Hrozek
Gesendet: Mittwoch, 7. Oktober 2015 10:03
An: freeipa-***@redhat.com
Betreff: Re: [Freeipa-users] SUDO does not always works on first try

On Mon, Oct 05, 2015 at 01:25:09PM +0000, Zoske, Fabian wrote:
> Dear Jakub,
>
> I found only the following entries in the /var/log/auth.log:
>
> Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): conversation
> failed Oct 5 11:57:38 hl-srv10 sudo: pam_unix(sudo:auth): auth could
> not identify password for [***@de.eu.local] Oct 5 11:57:38
> hl-srv10 sudo: pam_sss(sudo:auth): authentication failure;
> logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1
> ruser=***@de.eu.local rhost= user=***@de.eu.local Oct 5
> 11:57:38 hl-srv10 sudo: pam_sss(sudo:auth): received for user
> ***@de.eu.local: 7 (Authentication failure) Oct 5 11:57:38
> hl-srv10 sudo: ***@de.eu.local : user NOT authorized on host ;
> TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ;
> COMMAND=/bin/cat /etc/sssd/sssd.conf Oct 5 11:57:42 hl-srv10 sudo:
> pam_unix(sudo:auth): authentication failure;
> logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1
> ruser=***@de.eu.local rhost= user=***@de.eu.local Oct 5
> 11:57:42 hl-srv10 sudo: pam_sss(sudo:auth): authentication success;
> logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1
> ruser=***@de.eu.local rhost= user=***@de.eu.local Oct 5
> 11:57:43 hl-srv10 sudo: ***@de.eu.local : user NOT authorized on
> host ; TTY=pts/1 ; PWD=/home/de.eu.local/f.zoske ; USER=root ;
> COMMAND=/bin/bash Oct 5 11:57:46 hl-srv10 sudo: pam_unix(sudo:auth):
> authentication failure; logname=***@de.eu.local uid=1948403038
> euid=0 tty=/dev/pts/1 ruser=***@de.eu.local rhost=
> user=***@de.eu.local Oct 5 11:57:47 hl-srv10 sudo:
> pam_sss(sudo:auth): authentication success;
> logname=***@de.eu.local uid=1948403038 euid=0 tty=/dev/pts/1
> ruser=***@de.eu.local rhost= user=***@de.eu.local Oct 5
> 11:57:47 hl-srv10 sudo: ***@de.eu.local : TTY=pts/1 ;
> PWD=/home/de.eu.local/f.zoske ; USER=root ; COMMAND=/bin/bash Oct 5
> 11:57:47 hl-srv10 sudo: pam_unix(sudo:session): session opened for
> user root by
> ***@de.eu.local(uid=0)<mailto:***@de.eu.local(uid=0)>
>
> In /var/log/sssd/ no entries were logged.

Nothing gets logged in by default, you need to increase debug_level,
see:
https://fedorahosted.org/sssd/wiki/Troubleshooting

I would look into the domain log and krb5_child.log first

>
> My sssd.conf:
> [domain/ipa-lx.com]
>
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = ipa-lx.com
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = hl-srv10.ipa-lx.com
> chpass_provider = ipa
> ipa_server = _srv_, dc01.ipa-lx.com
> ldap_tls_cacert = /etc/ipa/ca.crt
> ldap_sudo_use_host_filter = false
>
> [sssd]
> services = nss, pam, ssh, sudo
> config_file_version = 2
> default_domain_suffix = de.eu.local
> domains = ei-ag.it
>
> [nss]
> override_shell = /bin/bash
>
> [pam]
>
> [sudo]
>
> [autofs]
>
> [ssh]
>
> [pac]
>
>
> Best regards,
> Fabian

> --
> 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

--
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

--
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 pro
Jakub Hrozek
2015-10-12 09:47:11 UTC
Permalink
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=***@de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-***@de.eu.local)(sudoUser=%domänen-***@de.eu.local)(sudoUser=+*)))]
(Fri Oct 9 12:24:09 2015) [sssd[sudo]]
[sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for
[***@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=***@de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-***@de.eu.local)(sudoUser=%domänen-***@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
[***@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 ***@de.eu.local
$ getent passwd ***@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
Zoske, Fabian
2015-10-13 07:19:20 UTC
Permalink
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 [***@redhat.com]
Sent: Monday, October 12, 2015 11:47
To: Zoske, Fabian
Cc: freeipa-***@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=***@de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-***@de.eu.local)(sudoUser=%domänen-***@de.eu.local)(sudoUser=+*)))]
(Fri Oct 9 12:24:09 2015) [sssd[sudo]]
[sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for
[***@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=***@de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-***@de.eu.local)(sudoUser=%domänen-***@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
[***@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 ***@de.eu.local
$ getent passwd ***@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
Jakub Hrozek
2015-10-16 08:32:14 UTC
Permalink
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 [***@redhat.com]
> Sent: Monday, October 12, 2015 11:47
> To: Zoske, Fabian
> Cc: freeipa-***@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=***@de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-***@de.eu.local)(sudoUser=%domänen-***@de.eu.local)(sudoUser=+*)))]
> (Fri Oct 9 12:24:09 2015) [sssd[sudo]]
> [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for
> [***@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=***@de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-***@de.eu.local)(sudoUser=%domänen-***@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
> [***@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 ***@de.eu.local
> $ getent passwd ***@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
Zoske, Fabian
2015-10-19 08:39:30 UTC
Permalink
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:***@redhat.com]
Gesendet: Freitag, 16. Oktober 2015 10:32
An: Zoske, Fabian
Cc: freeipa-***@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 [***@redhat.com]
> Sent: Monday, October 12, 2015 11:47
> To: Zoske, Fabian
> Cc: freeipa-***@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=***@de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-***@de.eu.local)(sudoUser=%domänen-***@de.eu.local)(sudoUser=+*)))]
> (Fri Oct 9 12:24:09 2015) [sssd[sudo]]
> [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for
> [***@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=***@de.eu.local)(sudoUser=#1948403038)(sudoUser=%ug_freeipa-***@de.eu.local)(sudoUser=%domänen-***@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
> [***@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 ***@de.eu.local
> $ getent passwd ***@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.or
Lukas Slebodnik
2015-10-19 08:51:51 UTC
Permalink
On (19/10/15 08:39), Zoske, Fabian wrote:
>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 "
>
python-sssdconfig is noarch package which is missing in
https://jhrozek.fedorapeople.org/sssd-test-builds/
I hope Jakub will upload it.

>Can you provide me this package or tell me where to find it?
>
Alternatively, you can test backported version from fedora 21.
It is the latest 1.12 release + few bugfixes.
https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12/

LS

--
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
Jakub Hrozek
2015-10-19 11:23:31 UTC
Permalink
On Mon, Oct 19, 2015 at 10:51:51AM +0200, Lukas Slebodnik wrote:
> On (19/10/15 08:39), Zoske, Fabian wrote:
> >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 "
> >
> python-sssdconfig is noarch package which is missing in
> https://jhrozek.fedorapeople.org/sssd-test-builds/
> I hope Jakub will upload it.

Yes, sorry, I keep forgetting the package since it's noarch and it shows
in a different part of the buildsystem page. Uploaded now.

--
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
Zoske, Fabian
2015-10-22 06:14:01 UTC
Permalink
Hi Lukas,

Thank you. These packages fixed the issue.

Best regards,
Fabian

-----Ursprüngliche Nachricht-----
Von: Lukas Slebodnik [mailto:***@redhat.com]
Gesendet: Montag, 19. Oktober 2015 10:52
An: Zoske, Fabian
Cc: freeipa-***@redhat.com
Betreff: Re: [Freeipa-users] SUDO does not always works on first try

On (19/10/15 08:39), Zoske, Fabian wrote:
>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 "
>
python-sssdconfig is noarch package which is missing in https://jhrozek.fedorapeople.org/sssd-test-builds/
I hope Jakub will upload it.

>Can you provide me this package or tell me where to find it?
>
Alternatively, you can test backported version from fedora 21.
It is the latest 1.12 release + few bugfixes.
https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12/

LS

--
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 pr
Jakub Hrozek
2015-10-22 09:33:46 UTC
Permalink
On Thu, Oct 22, 2015 at 06:14:01AM +0000, Zoske, Fabian wrote:
> Hi Lukas,
>
> Thank you. These packages fixed the issue.

Thank you very much for the testing and reporting back!

--
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
Zoske, Fabian
2015-10-26 12:34:21 UTC
Permalink
Hi folks,

Unfortunately the fix doesn't work as expected. On the first hosts I tried, there was no sign of the problem anymore, but when a colleage tried the hosts the problem occurs again.
And we discovered another side effect: new enrolled IPA clients are not able to communicate with the AD-DCs after the update of SSSD von IPA-DC.

Do you need any logs?

Best regards,
Fabian


-----Ursprüngliche Nachricht-----
Von: freeipa-users-***@redhat.com [mailto:freeipa-users-***@redhat.com] Im Auftrag von Jakub Hrozek
Gesendet: Donnerstag, 22. Oktober 2015 11:34
An: freeipa-***@redhat.com
Betreff: Re: [Freeipa-users] SUDO does not always works on first try

On Thu, Oct 22, 2015 at 06:14:01AM +0000, Zoske, Fabian wrote:
> Hi Lukas,
>
> Thank you. These packages fixed the issue.

Thank you very much for the testing and reporting back!

--
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

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-us
Jakub Hrozek
2015-10-26 13:23:48 UTC
Permalink
On Mon, Oct 26, 2015 at 12:34:21PM +0000, Zoske, Fabian wrote:
> Hi folks,
>
> Unfortunately the fix doesn't work as expected. On the first hosts I tried, there was no sign of the problem anymore, but when a colleage tried the hosts the problem occurs again.
> And we discovered another side effect: new enrolled IPA clients are not able to communicate with the AD-DCs after the update of SSSD von IPA-DC.
>
> Do you need any logs?

Yes, from both server and client.

>
> Best regards,
> Fabian
>
>
> -----Ursprüngliche Nachricht-----
> Von: freeipa-users-***@redhat.com [mailto:freeipa-users-***@redhat.com] Im Auftrag von Jakub Hrozek
> Gesendet: Donnerstag, 22. Oktober 2015 11:34
> An: freeipa-***@redhat.com
> Betreff: Re: [Freeipa-users] SUDO does not always works on first try
>
> On Thu, Oct 22, 2015 at 06:14:01AM +0000, Zoske, Fabian wrote:
> > Hi Lukas,
> >
> > Thank you. These packages fixed the issue.
>
> Thank you very much for the testing and reporting back!
>
> --
> 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

--
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
Continue reading on narkive:
Loading...