Parent/s of primary group are not retrieved with tokengroups disabled

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/3115

• Created at 2016-08-01 16:05:59 by jstephen
• Assigned to nobody
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1478077

---

In AD I have 'Domain Users' which is a member of a basic group called 'nestedtestgroup'

When tokengroups is disabled and my primary group is Domain Users, running id does not find 'nestedtestgroup'

[root@rhel6-sssd-ad ~]# id justintime@jstephen.local
uid=489246999(justintime@jstephen.local) gid=489200513(domain users@jstephen.local) groups=489200513(domain users@jstephen.local),489201114(largegroup@jstephen.local)

If I change my primary group to a different group such as 'largegroup', or turn tokengroups on then the group is visible

[root@rhel6-sssd-ad ~]# id justintime@jstephen.local
uid=489246999(justintime@jstephen.local) gid=489201114 groups=489201114(largegroup@jstephen.local),489200513(domain users@jstephen.local),489247023(nestedtestgroup@jstephen.local)

Jakub's input:
With tokengroups we get the list of all SIDs the user is a member of,
including the parent group of the primary group, during the initgroups
operation, so the grouplist is complete. Normally, when we return the
grouplist during the initgroups operation, we return all the groups the
user is an explicit member of plus their primary group.

In contrast, when tokengroups are disabled, we run ldapsearches in the
rough form of:
1) objectclass=group and member=userDN <-- to get direct parents
2) then for each direct parent, until we either stop receiving groups
or hit the nesting limit
for groupdn dn this_nesting_level_groups:
objectclass=group and member=groupdn
but we only loop through the non-primary groups in the generic
LDAP code, because normally in LDAP, admins don't add parent
groups of the primary group.

I think what happens when tokengroups are disabled is that we don't
receive the parent group of the primary group from LDAP in some explicit
list like we do with tokengroups and we neither explicitly search for
it -- which I think is the missing piece.

Comments

---

Comment from lslebodn at 2016-08-02 21:25:13

Which version of sssd do you use?

cc: => lslebodn

---

Comment from jhrozek at 2016-08-03 13:22:59

I managed to reproduce this bug with sssd master as well. In fact, I asked Justin to file this ticket in the first place..but it's not a pressing issue because in the related downstream case, we were able to make tokengroups work.

By the way, see this comment in the code:

924     /* With AD we also want to merge in parent groups of primary GID as they
925      * are reported with tokenGroups, too
926      */
927     if (opts->schema_type == SDAP_SCHEMA_AD) {
928         ret = sdap_dn_by_primary_gid(memctx, attrs, group_dom, opts,
929                                      &userdns, &nuserdns);
930         if (ret != EOK) {
931             DEBUG(SSSDBG_MINOR_FAILURE,
932                   "sdap_dn_by_primary_gid failed: [%d][%s].\n",
933                   ret, strerror(ret));
934             goto fail;
935         }
936     }

So if you add an AD group and add Domain users as a member of this group, tokengroup reports this parent group, but w/o tokengroups, we never reach this group at all.

---

Comment from jhrozek at 2016-08-04 16:23:55

Fields changed

milestone: NEEDS_TRIAGE => SSSD Deferred

---

Comment from jhrozek at 2016-08-17 15:57:54

Fields changed

rhbz: => todo

---

Comment from jstephen at 2017-02-24 14:54:16

Metadata Update from @Jstephen:

• Issue set to the milestone: SSSD Patches welcome

---

Comment from jhrozek at 2017-08-23 21:34:20

Metadata Update from @jhrozek:

• Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1478077 (was: todo)

---

Comment from jhrozek at 2017-08-23 21:34:20

Metadata Update from @jhrozek:

• Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1478077 (was: todo)

---

Comment from jhrozek at 2017-08-23 21:34:21

Issue linked to Bugzilla: Bug 1478077

---

Comment from jhrozek at 2017-08-23 21:34:35

Metadata Update from @jhrozek:

• Custom field design_review reset (from 0)
• Custom field mark reset (from 0)
• Custom field patch reset (from 0)
• Custom field review reset (from 0)
• Custom field sensitive reset (from 0)
• Custom field testsupdated reset (from 0)
• Issue close_status updated to: None
• Issue set to the milestone: None (was: SSSD Patches welcome)

---

Comment from jhrozek at 2017-09-11 17:48:32

Metadata Update from @jhrozek:

• Custom field design_review reset (from false)
• Custom field mark reset (from false)
• Custom field patch reset (from false)
• Custom field review reset (from false)
• Custom field sensitive reset (from false)
• Custom field testsupdated reset (from false)
• Issue set to the milestone: SSSD Future releases (no date set yet)

---

Comment from thalman at 2020-03-11 15:27:18

Metadata Update from @thalman:

• Custom field design_review reset (from false)
• Custom field mark reset (from false)
• Custom field patch reset (from false)
• Custom field review reset (from false)
• Custom field sensitive reset (from false)
• Custom field testsupdated reset (from false)
• Issue tagged with: bugzilla

[sanjay-agrawal]

we see same issue as well, any ETA for this fix.

[andreboscatto]

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards,
André Boscatto

CC: @tscherf