Bug 871160 - sudo failing for ad trusted user in IPA environment
Summary: sudo failing for ad trusted user in IPA environment
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks: 881827
TreeView+ depends on / blocked
 
Reported: 2012-10-29 19:03 UTC by Scott Poore
Modified: 2020-05-02 17:04 UTC (History)
5 users (show)

Fixed In Version: sssd-1.9.2-13.el6
Doc Type: Bug Fix
Doc Text:
No Documentation Needed
Clone Of:
Environment:
Last Closed: 2013-02-21 09:39:05 UTC
Target Upstream Version:


Attachments (Terms of Use)
sssd log with ssh and sudo failure (50.06 KB, application/x-gzip)
2012-10-29 19:03 UTC, Scott Poore
no flags Details
failure I saw with test patch (62.69 KB, application/x-tar)
2012-10-30 15:38 UTC, Scott Poore
no flags Details
failure with second test patch (46.41 KB, application/x-tar)
2012-11-01 17:40 UTC, Scott Poore
no flags Details
failure with third test patch (53.69 KB, application/x-tar)
2012-11-06 17:28 UTC, Scott Poore
no flags Details
logs from second test for third patch (40.48 KB, application/x-tar)
2012-11-06 22:35 UTC, Scott Poore
no flags Details
sudo failure with sssd.conf fixed and third patch (50.04 KB, application/x-tar)
2012-11-07 14:41 UTC, Scott Poore
no flags Details


Links
System ID Priority Status Summary Last Updated
Github SSSD sssd issues 2658 None None None 2020-05-02 17:04:11 UTC
Red Hat Product Errata RHSA-2013:0508 normal SHIPPED_LIVE Low: sssd security, bug fix and enhancement update 2013-02-20 21:30:10 UTC

Description Scott Poore 2012-10-29 19:03:38 UTC
Created attachment 635139 [details]
sssd log with ssh and sudo failure

Description of problem:

sudo is not working for an AD trusted user in my IPA environment.  I'm testing on IPA test server.

[root@rhel6-1 failure1]# cat /etc/sssd/sssd.conf
[domain/default]
debug_level = 10
cache_credentials = True

[domain/testrelm.com]
debug_level = 10
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = testrelm.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
subdomains_provider = ipa
ipa_hostname = rhel6-1.testrelm.com
chpass_provider = ipa
ipa_server = rhel6-1.testrelm.com
ldap_tls_cacert = /etc/ipa/ca.crt
sudo_provider = ldap
ldap_uri = ldap://rhel6-1.testrelm.com
ldap_sudo_search_base = ou=sudoers,dc=ipa,dc=testrelm,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/rhel6-1.testrelm.com
ldap_sasl_realm = TESTRELM.COM
krb5_server = rhel6-1.testrelm.com

[sssd]
debug_level = 10
services = nss, pam, ssh, pac, sudo
config_file_version = 2
domains = testrelm.com

[nss]
debug_level = 10

[pam]
debug_level = 10

[sudo]
debug_level = 10

[autofs]
debug_level = 10

[ssh]
debug_level = 10

[pac]
debug_level = 10


[root@rhel6-1 failure1]# ipa sudorule-show testrule
  Rule name: testrule
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: adtestdom_adtestgroup1

[root@rhel6-1 failure1]# ipa group-show adtestdom_adtestgroup1
  Group name: adtestdom_adtestgroup1
  Description: adtestdom.com adtestgroup1
  GID: 1277200040
  Member groups: adtestdom_adtestgroup1_external
  Member of Sudo rule: testrule

[root@rhel6-1 failure1]# ipa group-show adtestdom_adtestgroup1_external
  Group name: adtestdom_adtestgroup1_external
  Description: adtestdom.com adtestgroup1 external
  Member of groups: adtestdom_adtestgroup1
  Indirect Member of Sudo rule: testrule
  External member: S-1-5-21-1246088475-3077293710-2580964704-1135

[root@rhel6-1 failure1]# wbinfo -n "ADTESTDOM\adtestgroup1"
S-1-5-21-1246088475-3077293710-2580964704-1135 SID_DOM_GROUP (2)

In AD, user adtestuser1 is in adtestgroup1.

I added "debug_level = 10" to all sections of sssd.conf and reran the test:

[root@rhel6-1 sssd]# vi /etc/sssd/sssd.conf

[root@rhel6-1 sssd]# service sssd stop
Stopping sssd:                                             [  OK  ]

[root@rhel6-1 sssd]# ls
backup          ldap_child.log  sssd_nss.log  sssd_pam.log  sssd_sudo.log
krb5_child.log  sssd.log        sssd_pac.log  sssd_ssh.log  sssd_testrelm.com.log

[root@rhel6-1 sssd]# for file in $(ls *.log); do cat /dev/null > $file; done

[root@rhel6-1 sssd]# service sssd start
Starting sssd:                                             [  OK  ]

[root@rhel6-1 sssd]# ssh -l adtestuser1@adtestdom.com rhel6-1.testrelm.com
adtestuser1@adtestdom.com@rhel6-1.testrelm.com's password: 
Last login: Sun Oct 28 22:07:06 2012 from rhel6-1.testrelm.com
id: cannot find name for group ID 1232801136

-sh-4.1$ sudo id
[sudo] password for adtestuser1@adtestdom.com: 
adtestuser1@adtestdom.com is not in the sudoers file.  This incident will be reported.

-sh-4.1$ exit
logout
Connection to rhel6-1.testrelm.com closed.

Version-Release number of selected component (if applicable):
[root@rhel6-1 failure1]# rpm -qa|egrep "sssd|sudo"|sort
libsss_sudo-1.9.90-0.20121026T1831zgitac7a7ee.el6.x86_64
libsss_sudo-devel-1.9.90-0.20121026T1831zgitac7a7ee.el6.x86_64
sssd-1.9.90-0.20121026T1831zgitac7a7ee.el6.x86_64
sssd-client-1.9.90-0.20121026T1831zgitac7a7ee.el6.x86_64
sudo-1.8.6p3-4.el6.x86_64

How reproducible:
Seems to be always.

Steps to Reproduce:
1.  Install IPA Master
2.  Install AD server
3.  Setup Cross Realm Trust to AD Domain
4.  setup sudo rules like above
5.  ssh to log in and run sudo

More information and details about some of the setup can be found here:
https://fedoraproject.org/wiki/QA:Testcase_freeipav3_sudo_sssd

Actual results:
User is denied running command.

Expected results:
User can run command.

Additional info:

Comment 4 Scott Poore 2012-10-30 15:37:31 UTC
Ok, I tried the test patch but, it still fails.  It certainly runs faster though.

I'm attaching the latest logs here.

Comment 5 Scott Poore 2012-10-30 15:38:05 UTC
Created attachment 635664 [details]
failure I saw with test patch

Comment 6 Scott Poore 2012-10-30 15:39:08 UTC
FYI:  Just as a test I also checked the Kerberos ticket to see if that affected it.

[root@rhel6-1 sssd]# ssh -l adtestuser1@adtestdom.com rhel6-1
adtestuser1@adtestdom.com@rhel6-1's password: 
Last login: Tue Oct 30 11:30:48 2012 from rhel6-1.testrelm.com
id: cannot find name for group ID 1232801136

k-sh-4.1$ klist
Ticket cache: FILE:/tmp/krb5cc_1232801136_TVzMmD
Default principal: adtestuser1@ADTESTDOM.COM

Valid starting     Expires            Service principal
10/30/12 11:33:33  10/30/12 21:33:25  krbtgt/ADTESTDOM.COM@ADTESTDOM.COM
	renew until 10/31/12 11:33:33

-sh-4.1$ kinit 
Password for adtestuser1@ADTESTDOM.COM: 

-sh-4.1$ sudo id
[sudo] password for adtestuser1@adtestdom.com: 
adtestuser1@adtestdom.com is not in the sudoers file.  This incident will be reported.

Comment 8 Dmitri Pal 2012-11-01 13:43:55 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1616

Comment 9 Scott Poore 2012-11-01 17:40:44 UTC
Created attachment 636762 [details]
failure with second test patch

Comment 10 Scott Poore 2012-11-01 17:42:37 UTC
I saw the same failure from the command line with the new test patch but, sounds like that might be expected?  I tried clearing the cache to make sure this was clean before but, it did still fail.

Comment 12 Scott Poore 2012-11-06 17:27:37 UTC
I'm still seeing the same failure.  Is it possible that my environment affects how it's building and that is affecting what I'm seeing here?  

I'll also attach the logs again in case that helps.

Comment 13 Scott Poore 2012-11-06 17:28:11 UTC
Created attachment 639476 [details]
failure with third test patch

Comment 14 Pavel Březina 2012-11-06 21:48:39 UTC
Hi,
thank you for testing. I don't think that your environment should affect the build. The tarball is missing sssd_sudo.log, can you attach it please?

Comment 15 Scott Poore 2012-11-06 22:34:41 UTC
Ok, so the failure is a little different.  I just found that I was missing 2 things from the last test since I rebuilt my servers:

1. nsswitch.conf "sudoers: sss" line
2. libsss_sudo (and libsss_sudo-devel?)

After updating those, this is now what I see:

-sh-4.1$ id
uid=1232801136(adtestuser1@adtestdom.com) gid=1232801136(adtestuser1@adtestdom.com) groups=1232801136(adtestuser1@adtestdom.com),1606000004(adtestdom_adtestgroup1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

-sh-4.1$ klist
Ticket cache: FILE:/tmp/krb5cc_1232801136_CR4crh
Default principal: adtestuser1@ADTESTDOM.COM

Valid starting     Expires            Service principal
11/06/12 17:13:29  11/07/12 03:13:11  krbtgt/ADTESTDOM.COM@ADTESTDOM.COM
	renew until 11/07/12 17:13:29

-sh-4.1$ kinit 
Password for adtestuser1@ADTESTDOM.COM: 

-sh-4.1$ sudo id
[sudo] password for adtestuser1@adtestdom.com: 
adtestuser1@adtestdom.com is not allowed to run sudo on rhel6-1.  This incident will be reported.

...

Just double checking my config since I did have to rebuild my env:

[root@rhel6-1 sssd]# ipa sudorule-show testrule
  Rule name: testrule
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: adtestdom_adtestgroup1

[root@rhel6-1 sssd]# ipa group-show adtestdom_adtestgroup1
  Group name: adtestdom_adtestgroup1
  Description: adtestdom.com adtestgroup1
  GID: 1606000004
  Member groups: adtestdom_adtestgroup1_external
  Member of Sudo rule: testrule

[root@rhel6-1 sssd]# ipa group-show adtestdom_adtestgroup1_external
  Group name: adtestdom_adtestgroup1_external
  Description: adtestdom.com adtestgroup1 external
  Member of groups: adtestdom_adtestgroup1
  Indirect Member of Sudo rule: testrule
  External member: S-1-5-21-1246088475-3077293710-2580964704-1135

[root@rhel6-1 sssd]# wbinfo -n "ADTESTDOM\adtestgroup1"
S-1-5-21-1246088475-3077293710-2580964704-1135 SID_DOM_GROUP (2)

confirmed that I can see adtestuser1 in adtestgroup1 on AD server.

[root@rhel6-1 sssd]# cat /etc/sssd/sssd.conf 
[domain/default]
debug_level = 10
cache_credentials = True

[domain/testrelm.com]
debug_level = 10
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = testrelm.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
subdomains_provider = ipa
ipa_hostname = rhel6-1.testrelm.com
chpass_provider = ipa
ipa_server = rhel6-1.testrelm.com
ldap_tls_cacert = /etc/ipa/ca.crt
sudo_provider = ldap
ldap_uri = ldap://rhel6-1.testrelm.com
ldap_sudo_search_base = ou=sudoers,dc=ipa,dc=testrelm,dc=com
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/rhel6-1.testrelm.com
ldap_sasl_realm = TESTRELM.COM
krb5_server = rhel6-1.testrelm.com

[sssd]
debug_level = 10
services = nss, pam, ssh, pac, sudo
config_file_version = 2
domains = testrelm.com

[nss]
debug_level = 10

[pam]
debug_level = 10

[sudo]
debug_level = 10

[autofs]
debug_level = 10

[ssh]
debug_level = 10

[pac]
debug_level = 10

[root@rhel6-1 sssd]# grep sudoers /etc/nsswitch.conf 
sudoers:    sss

Just to see, I checked and non-AD users can't sudo either so something is wrong.  Maybe with my config?

[root@rhel6-1 sssd]# ipa sudorule-add-user testrule --users=testsudo1
  Rule name: testrule
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  Users: testsudo1
  User Groups: adtestdom_adtestgroup1
-------------------------
Number of members added 1
-------------------------

[root@rhel6-1 sssd]# ipa sudorule-remove-user --groups=adtestdom_adtestgroup1
Rule name: testrule
  Rule name: testrule
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  Users: testsudo1
---------------------------
Number of members removed 1
---------------------------

[root@rhel6-1 sssd]# service sssd stop
Stopping sssd:                                             [  OK  ]

[root@rhel6-1 sssd]# rm -f /var/lib/sss/db/*

[root@rhel6-1 sssd]# rm -f /var/lib/sss/mc/*

[root@rhel6-1 sssd]# !for
for file in $(ls *.log); do cat /dev/null > $file; done

[root@rhel6-1 sssd]# pwd
/var/log/sssd

[root@rhel6-1 sssd]# service sssd start
Starting sssd:                                             [  OK  ]

[root@rhel6-1 sssd]# su - testsudo1

-sh-4.1$ sudo id
[sudo] password for testsudo1: 
Sorry, try again.
[sudo] password for testsudo1: 
testsudo1 is not allowed to run sudo on rhel6-1.  This incident will be reported.

It case it helps or matter, I'm attaching a new set of logs.

Comment 16 Scott Poore 2012-11-06 22:35:56 UTC
Created attachment 639676 [details]
logs from second test for third patch

Comment 17 Scott Poore 2012-11-06 23:34:06 UTC
Also, I just noticed something:

[root@rhel6-1 sssd]# ipa group-show adtestdom_adtestgroup1_external
  Group name: adtestdom_adtestgroup1_external
  Description: adtestdom.com adtestgroup1 external
  Member of groups: adtestdom_adtestgroup1
  Indirect Member of Sudo rule: testrule
  External member: S-1-5-21-1246088475-3077293710-2580964704-1135

[root@rhel6-1 sssd]# su - adtestuser1@adtestdom.com
-sh-4.1$ id
uid=1232801136(adtestuser1@adtestdom.com) gid=1232801136(adtestuser1@adtestdom.com) groups=1232801136(adtestuser1@adtestdom.com) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

That is NOT showing that adtestuser1 is a member of either adtestdom_adtestgroup1_external or adtestdom_adtestgroup1.

-sh-4.1$ getent -s sss group adtestdom_adtestgroup1
adtestdom_adtestgroup1:*:1606000004:

-sh-4.1$ getent -s sss group adtestdom_adtestgroup1_external

-sh-4.1$ 

Not sure if that helps.

Comment 18 Pavel Březina 2012-11-07 12:50:54 UTC
I believe your sudo search base is set incorrectly (it has additional dc=ipa).

Comment 19 Scott Poore 2012-11-07 14:28:45 UTC
Oh no.  I got sidetracked yesterday and didn't update this bug,   Yeah, I caught that when going through the logs.  I fixed that and the IPA user started working but the AD one did not.

Let me re-run my tests just to make sure I've got a clean set of logs to send.

Comment 20 Scott Poore 2012-11-07 14:40:16 UTC
[root@rhel6-1 sssd]# service sssd stop
Stopping sssd:                                             [  OK  ]

[root@rhel6-1 sssd]# pwd
/var/log/sssd

[root@rhel6-1 sssd]# mkdir failure-20121107-1

[root@rhel6-1 sssd]# rm -f /var/lib/sss/db/* /var/lib/sss/mc/*

[root@rhel6-1 sssd]# ipa sudorule-find
-------------------
1 Sudo Rule matched
-------------------
  Rule name: testrule
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  Users: testsudo1
  User Groups: adtestdom_adtestgroup1
----------------------------
Number of entries returned 1
----------------------------

[root@rhel6-1 sssd]# service sssd start
Starting sssd:                                             [  OK  ]


[root@rhel6-1 sssd]# su - testsudo1

-sh-4.1$ sudo id
[sudo] password for testsudo1: 
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

-sh-4.1$ exit
logout
[root@rhel6-1 sssd]# su - adtestuser1@adtestdom.com

-sh-4.1$ sudo id
[sudo] password for adtestuser1@adtestdom.com: 
adtestuser1@adtestdom.com is not allowed to run sudo on rhel6-1.  This incident will be reported.

Will attach logs too.

Comment 21 Scott Poore 2012-11-07 14:41:49 UTC
Created attachment 640111 [details]
sudo failure with sssd.conf fixed and third patch

Comment 22 Scott Poore 2012-11-08 17:02:39 UTC
setting keyword to TestBlocker since I missed doing that earlier.   Will ping Jakub in IRC.

Comment 25 Scott Poore 2012-11-09 20:57:57 UTC
Looks like the last patch did the trick:

[root@rhel6-1 yum.local.d]# ssh -l adtestuser1@adtestdom.com rhel6-1
adtestuser1@adtestdom.com@rhel6-1's password: 
Last login: Fri Nov  9 15:53:59 2012 from rhel6-1.testrelm2.com

-sh-4.1$ id
uid=1232801136(adtestuser1@adtestdom.com) gid=1232801136(adtestuser1@adtestdom.com) groups=1232801136(adtestuser1@adtestdom.com),948400004(adtestdom_adtestgroup1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

-sh-4.1$ sudo id
[sudo] password for adtestuser1@adtestdom.com: 
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Thanks, Pavel.

Comment 27 Scott Poore 2012-11-19 22:07:04 UTC
Verified.

Version ::
sssd-1.9.2-13.el6.x86_64

Manual Test Results ::

[root@storm log]# ipa sudorule-show testrule
  Rule name: testrule
  Enabled: TRUE
  Host category: all
  Command category: all
  RunAs User category: all
  RunAs Group category: all
  User Groups: adlab_adgroup1

[root@storm log]# ipa group-show adlab_adgroup1
  Group name: adlab_adgroup1
  Description: adlab_adgroup1
  GID: 1610200004
  Member groups: adlab_adgroup1_external
  Member of Sudo rule: testrule

[root@storm log]# ipa group-show adlab_adgroup1_external
  Group name: adlab_adgroup1_external
  Description: adlab_adgroup1_external
  Member of groups: adlab_adgroup1
  Indirect Member of Sudo rule: testrule
  External member: S-1-5-21-3655990580-1375374850-1633065477-1150

[root@storm log]# wbinfo -s S-1-5-21-3655990580-1375374850-1633065477-1150
ADLAB\adgroup1 2

[root@storm log]# wbinfo -n "ADLAB\adtestuser1"
S-1-5-21-3655990580-1375374850-1633065477-1178 SID_USER (1)

[root@storm log]# wbinfo --user-sids S-1-5-21-3655990580-1375374850-1633065477-1178| grep S-1-5-21-3655990580-1375374850-1633065477-1150|wc -l
1

[root@storm log]# ssh -l adtestuser1@adlab.qe $(hostname)
adtestuser1@adlab.qe@storm.ipa3.example.com's password: 
Last login: Mon Nov 19 16:14:57 2012 from storm.ipa3.example.com
**  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **
                 This System is reserved by spoore@redhat.com.

 To return this system early. You can run the command: return2beaker.sh
  Ensure you have your logs off the system before returning to Beaker

 To extend your reservation time. You can run the command:
  extendtesttime.sh
 This is an interactive script. You will be prompted for how many
  hours you would like to extend the reservation.

 You should verify the watchdog was updated succesfully after
  you extend your reservation.
  https://beaker.engineering.redhat.com/recipes/708926

 For ssh, kvm, serial and power control operations please look here:
  https://beaker.engineering.redhat.com/view/storm.idm.lab.bos.redhat.com

      Beaker Test information:
                         HOSTNAME=storm.idm.lab.bos.redhat.com
                            JOBID=334713
                         RECIPEID=708926
                    RESULT_SERVER=127.0.0.1:7091
                           DISTRO=RHEL6.4-20121115.n.0
                     ARCHITECTURE=x86_64
**  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **  **

-sh-4.1$ sudo id
[sudo] password for adtestuser1@adlab.qe: 
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Comment 28 errata-xmlrpc 2013-02-21 09:39:05 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0508.html


Note You need to log in before you can comment on or make changes to this bug.