Not after step 4 you need to do this:

ipa group-add-members adtestdom_testgroup --groups=adtestdom_testgroup_external

Here's a little more info...not sure if it helps:

So, SSSD HBAC matching was searching for this?

(Wed Oct 24 11:53:28 2012) [sssd[be[testrelm.com]]] [sysdb_search_groups] (0x2000): Search groups with filter: (&(objectclass=group)(originalDN=cn=adtestdom_testgroup,cn=groups,cn=accounts,dc=testrelm,dc=com))

But couldn't find it?

(Wed Oct 24 11:53:28 2012) [sssd[be[testrelm.com]]] [sysdb_search_groups] (0x2000): No such entry


Here's what I see in LDAP:

[root@rhel6-1 ~]# ldapsearch -xLLL -D "$ROOTDN" -w "$ROOTDNPWD" -b "cn=adtestdom_testgroup,cn=groups,cn=accounts,dc=testrelm,dc=com"
dn: cn=adtestdom_testgroup,cn=groups,cn=accounts,dc=testrelm,dc=com
member: cn=adtestdom_testgroup_external,cn=groups,cn=accounts,dc=testrelm,dc=c
 om
memberOf: ipauniqueid=1d777416-1d85-11e2-845c-525400555d2f,cn=hbac,dc=testrelm
 ,dc=com
ipaNTSecurityIdentifier: S-1-5-21-1941887706-3747460317-4235707753-1031
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
description: adtestdom.com testgroup
cn: adtestdom_testgroup
ipaUniqueID: 2c390d9c-1ddb-11e2-89d3-525400555d2f
gidNumber: 1277200031

[root@rhel6-1 ~]# ldapsearch -xLLL -D "$ROOTDN" -w "$ROOTDNPWD" -b "cn=adtestdom_testgroup_external,cn=groups,cn=accounts,dc=testrelm,dc=com"
dn: cn=adtestdom_testgroup_external,cn=groups,cn=accounts,dc=testrelm,dc=com
memberOf: cn=adtestdom_testgroup,cn=groups,cn=accounts,dc=testrelm,dc=com
memberOf: ipauniqueid=1d777416-1d85-11e2-845c-525400555d2f,cn=hbac,dc=testrelm
 ,dc=com
ipaExternalMember: S-1-5-21-1246088475-3077293710-2580964704-1132
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: ipaexternalgroup
description: adtestdom.com testgroup external map
cn: adtestdom_testgroup_external
ipaUniqueID: 215ec470-1ddb-11e2-8cdf-525400555d2f

But, looking close at the filter SSSD log mentioned, the group doesn't have a group objectClass set?

[root@rhel6-1 ~]# ldapsearch -xLLL -D "$ROOTDN" -w "$ROOTDNPWD" -b "cn=adtestdom_testgroup,cn=groups,cn=accounts,dc=testrelm,dc=com" objectclass=group
[root@rhel6-1 ~]# 

If I create a new group though it doens't either?

[root@rhel6-1 ~]# ipa group-add --desc=test testlocal
-----------------------
Added group "testlocal"
-----------------------
  Group name: testlocal
  Description: test
  GID: 1277200032

[root@rhel6-1 ~]# ldapsearch -xLLL -D "$ROOTDN" -w "$ROOTDNPWD" -b "cn=testlocal,cn=groups,cn=accounts,dc=testrelm,dc=com" objectclass=group

[root@rhel6-1 ~]# ldapsearch -xLLL -D "$ROOTDN" -w "$ROOTDNPWD" -b "cn=testlocal,cn=groups,cn=accounts,dc=testrelm,dc=com"
dn: cn=testlocal,cn=groups,cn=accounts,dc=testrelm,dc=com
ipaNTSecurityIdentifier: S-1-5-21-1941887706-3747460317-4235707753-1032
objectClass: top
objectClass: groupofnames
objectClass: nestedgroup
objectClass: ipausergroup
objectClass: ipaobject
objectClass: posixgroup
objectClass: ipantgroupattrs
description: test
cn: testlocal
ipaUniqueID: 7fb4a454-1df4-11e2-8217-525400555d2f
gidNumber: 1277200032

So, is this a problem with how groups are getting created/set or how the SSSD HBAC filtering is occurring?  Or something else altogether?

Sorry, you are looking at two different directory trees. The search filter "(&(objectclass=group)(originalDN=cn=adtestdom_testgroup,cn=groups,cn=accounts,dc=testrelm,dc=com))" is for the local sssd cache, not for the LDAP server. You can see this by the sysdb_ prefix in the name of the function. The local sssd cache is organized as a directory tree, but is not a copy of the tree of the LDAP server.

You can use 'ldbsearch H /var/lib/sss/db/cache_testrelm.com.ldb <filter>' to search the local cache.

Ah, ok.

[root@rhel6-1 ~]# ldbsearch -H /var/lib/sss/db/cache_testrelm.com.ldb "(&(objectclass=group)(originalDN=cn=adtestdom_testgroup,cn=groups,cn=accounts,dc=testrelm,dc=com))"
asq: Unable to register control with rootdse!
# record 1
dn: name=adtestdom_testgroup,cn=groups,cn=testrelm.com,cn=sysdb
createTimestamp: 1351091602
gidNumber: 1277200031
name: adtestdom_testgroup
objectClass: group
isPosix: TRUE
originalDN: cn=adtestdom_testgroup,cn=groups,cn=accounts,dc=testrelm,dc=com
originalModifyTimestamp: 20121024131126Z
entryUSN: 1405
lastUpdate: 1351091602
dataExpireTimestamp: 1351097002
member: name=testuser1,cn=users,cn=adtestdom.com,cn=sysdb
memberuid: testuser1
distinguishedName: name=adtestdom_testgroup,cn=groups,cn=testrelm.com,cn=sysdb

# returned 1 records
# 1 entries
# 0 referrals

Ok, I dug into this today and found the root cause.

The relevant line from the log is this:
(Wed Oct 24 10:33:23 2012) [sssd[be[testrelm.com]]] [hbac_eval_user_element] (0x1000): No groups for [testuser1]

Reading the source, the only way this can happen is if the user has no "originalMemberOf" attributes in the sysdb cache. We look for this attribute as a way to "cheat" and shortcut lookups for groups the user belongs to.

For FreeIPA users (those that aren't coming from trust relationships), we have a guarantee that the LDAP entry for the user will contain memberOf attributes for ALL objects for which the use is a member. We then use some hackish DN comparisons to narrow that list down to actual group objects.

However, when users are added to our cache through the trust lookup, they are not coming from LDAP and therefore do not have the originalMemberOf attribute. As a result, the user appears to be a member of no groups, and thus they do not pass HBAC rules requiring group membership. The cache does have correct links to the FreeIPA groups, though.

There are two ways we could solve this bug that I see.

1) When saving the user, we could add "fake" originalMemberOf attributes by copying in the originalMemberOf attributes from any of the FreeIPA groups that the trust relationship is providing us. Then when we get to the HBAC code, we'll just proceed like we do for native users. The limitation of this approach is that it will be tricky and may require additional lookups to the FreeIPA server if the groups are not cached (since we need the complete set of their parent hierarchy)

2) When saving a trusted domain user, we can instead add an extra "objectClass: trusted_domain_user". When we get to the HBAC code, we can key on this for whether we need to follow the memberOf hierarchy instead of the originalMemberOf hierarchy.

Another thing to keep in mind is whether we want to support HBAC rules referencing groups from the trusted domain or only native FreeIPA groups. Supporting only FreeIPA groups is *much* simpler.

Stephen, thank you for the analysis. I think I will take the second way. Only native groups are supported but you can add groups from trusted domain via external groups to native groups.

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

Verified.

Version ::

Manual Test Results ::

<previously created groups>

[root@rhel6-1 log]# ipa group-show adtestdom_testgroup
  Group name: adtestdom_testgroup
  Description: adtestdom.com testgroup
  GID: 270000004
  Member groups: adtestdom_testgroup_external

[root@rhel6-1 log]# ipa group-show adtestdom_testgroup_external
  Group name: adtestdom_testgroup_external
  Description: adtestdom.com testgroup external map
  Member of groups: adtestdom_testgroup
  External member: S-1-5-21-1246088475-3077293710-2580964704-1135

[root@rhel6-1 log]# wbinfo -n "ADTESTDOM\adtestuser1"
S-1-5-21-1246088475-3077293710-2580964704-1136 SID_USER (1)

[root@rhel6-1 log]# wbinfo --user-sids S-1-5-21-1246088475-3077293710-2580964704-1136
S-1-5-21-1246088475-3077293710-2580964704-1136
S-1-5-21-1246088475-3077293710-2580964704-513
S-1-5-21-1246088475-3077293710-2580964704-1135

[root@rhel6-1 log]# wbinfo -s S-1-5-21-1246088475-3077293710-2580964704-1136
ADTESTDOM\adtestuser1 1

[root@rhel6-1 log]# wbinfo -s S-1-5-21-1246088475-3077293710-2580964704-513
ADTESTDOM\Domain Users 2

[root@rhel6-1 log]# wbinfo -s S-1-5-21-1246088475-3077293710-2580964704-1135
ADTESTDOM\adtestgroup1 2

[root@rhel6-1 log]# ipa hbacrule-add --desc=test test
----------------------
Added HBAC rule "test"
----------------------
  Rule name: test
  Description: test
  Enabled: TRUE

[root@rhel6-1 log]# ipa hbacrule-add-service --hbacsvcs=sshd  test
  Rule name: test
  Description: test
  Enabled: TRUE
  Services: sshd
-------------------------
Number of members added 1
-------------------------

[root@rhel6-1 log]# ipa hbacrule-add-user test --groups=adtestdom_testgroup
  Rule name: test
  Description: test
  Enabled: TRUE
  User Groups: adtestdom_testgroup
  Services: sshd
-------------------------
Number of members added 1
-------------------------

[root@rhel6-1 log]# ipa hbacrule-add-host --hosts=rhel6-1.testrelm.com test
  Rule name: test
  Description: test
  Enabled: TRUE
  User Groups: adtestdom_testgroup
  Hosts: rhel6-1.testrelm.com
  Services: sshd
-------------------------
Number of members added 1
-------------------------

[root@rhel6-1 log]# ipa hbacrule-disable allow_all
------------------------------
Disabled HBAC rule "allow_all"
------------------------------

[root@rhel6-1 log]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: admin

Valid starting     Expires            Service principal
11/12/12 16:55:03  11/13/12 16:55:01  krbtgt/TESTRELM.COM
11/12/12 16:55:04  11/13/12 16:55:01  HTTP/rhel6-1.testrelm.com

[root@rhel6-1 log]# kinit adtestuser1
Password for adtestuser1: 

[root@rhel6-1 log]# ssh -K -l adtestuser1 rhel6-1.testrelm.com
Last login: Mon Nov 12 16:07:22 2012 from rhel6-1.testrelm.com

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

[root@rhel6-1 log]# ssh -K -l adtestuser1 rhel6-2.testrelm.com
Connection closed by UNKNOWN

So, looks like it allows me to login where expected and denies where expected.

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