Ok, I tried the test patch but, it still fails.  It certainly runs faster though.

I'm attaching the latest logs here.

Created attachment 635664 [details]
failure I saw with test patch

FYI:  Just as a test I also checked the Kerberos ticket to see if that affected it.

[root@rhel6-1 sssd]# ssh -l adtestuser1 rhel6-1
adtestuser1@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

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

-sh-4.1$ kinit 
Password for adtestuser1: 

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

Upstream ticket:
https://fedorahosted.org/sssd/ticket/1616

Created attachment 636762 [details]
failure with second test patch

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.

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.

Created attachment 639476 [details]
failure with third test patch

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?

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) gid=1232801136(adtestuser1) groups=1232801136(adtestuser1),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

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

-sh-4.1$ kinit 
Password for adtestuser1: 

-sh-4.1$ sudo id
[sudo] password for adtestuser1: 
adtestuser1 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.

Created attachment 639676 [details]
logs from second test for third patch

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
-sh-4.1$ id
uid=1232801136(adtestuser1) gid=1232801136(adtestuser1) groups=1232801136(adtestuser1) 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.

I believe your sudo search base is set incorrectly (it has additional dc=ipa).

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.

[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

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

Will attach logs too.

Created attachment 640111 [details]
sudo failure with sssd.conf fixed and third patch

setting keyword to TestBlocker since I missed doing that earlier.   Will ping Jakub in IRC.

Looks like the last patch did the trick:

[root@rhel6-1 yum.local.d]# ssh -l adtestuser1 rhel6-1
adtestuser1@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) gid=1232801136(adtestuser1) groups=1232801136(adtestuser1),948400004(adtestdom_adtestgroup1) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

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

Thanks, Pavel.

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 $(hostname)
adtestuser1@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.

 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: 
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

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