RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1449729 - org.freedesktop.sssd.infopipe.GetUserGroups does not resolve groups into names with AD
Summary: org.freedesktop.sssd.infopipe.GetUserGroups does not resolve groups into name...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: sssd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: SSSD Maintainers
QA Contact: Matt Pusateri
URL:
Whiteboard:
Depends On:
Blocks: 1432518
TreeView+ depends on / blocked
 
Reported: 2017-05-10 14:18 UTC by Jakub Hrozek
Modified: 2020-05-02 18:40 UTC (History)
13 users (show)

Fixed In Version: sssd-1.15.2-43.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 09:06:23 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 4419 0 None closed org.freedesktop.sssd.infopipe.GetUserGroups does not resolve groups into names with AD 2020-10-28 23:10:08 UTC
Red Hat Product Errata RHEA-2017:2294 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2017-08-01 12:39:55 UTC

Description Jakub Hrozek 2017-05-10 14:18:47 UTC 
This bug is created as a clone of upstream ticket:
https://pagure.io/SSSD/sssd/issue/3392

The AD provider only converts SIDs to GIDs during initgroups to improve performance. But this is not sufficient for the org.freedesktop.sssd.infopipe.GetUserGroups method, which needs to return names.

We need to resolve the GIDs to names ourselves in that method.
Comment 2 Lukas Slebodnik 2017-05-31 12:34:13 UTC 
master:
* 95acbbb3fbfe972fecd3d8dcbc40d6b1d6b1d354
* c59b7362644efb4546e7fae029b846b53bf48109
* ed15b405ff95e521df3028fc40360a1547ba84bd
Comment 7 Matt Pusateri 2017-06-12 15:54:30 UTC 
Doesn't handle a group with special characters(diacritic) like "SR-APP-EPM-Membre-équipe" 

dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups string:test-user5
method return sender=:1.37 -> dest=:1.44 reply_serial=2
   array [
      string "user-group-ad.bos.redhat.com"
      string "domain users.bos.redhat.com"
      string "$d51000-b7oq3n5m0tga.bos.redhat.com"


I also had another user fail that does exist but is another edge case. I think because it doesn't have a display name.

dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups string:test-user7
Error org.freedesktop.DBus.Error.Failed: No such user

Other than that it looks to be working.
Comment 9 Jakub Hrozek 2017-06-12 16:26:58 UTC 
Thank you for prepairing the test VM. I think the displayed name of the group is a matter of configuration, because the group in question really does have samaccountname set to $d51000-b7oq3n5m0tga:

dn: CN=ProblemGroup2,CN=Users,DC=ad,DC=cloudqe,DC=bos,DC=redhat,DC=com
sAMAccountName: $D51000-B7OQ3N5M0TGA
cn: ProblemGroup2

So here, sssd is displaying the value of samaccountname, because it is configured with id_provider=ad that defaults to using samaccountname for both users' and groups' names.

I wonder which attribute does CFME expect here. Joe, do you know?
Comment 10 Joe Vlcek 2017-06-15 14:15:14 UTC 
(In reply to Matt Pusateri from comment #7)
> Doesn't handle a group with special characters(diacritic) like
> "SR-APP-EPM-Membre-équipe" 
> 
> dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe
> /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups
> string:test-user5
> method return sender=:1.37 -> dest=:1.44 reply_serial=2
>    array [
>       string "user-group-ad.bos.redhat.com"
>       string "domain users.bos.redhat.com"
>       string "$d51000-b7oq3n5m0tga.bos.redhat.com"
> 
> 
> I also had another user fail that does exist but is another edge case. I
> think because it doesn't have a display name.
> 
> dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe
> /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserGroups
> string:test-user7
> Error org.freedesktop.DBus.Error.Failed: No such user
> 
> Other than that it looks to be working.

If you see this working except for groups with special characters. This issue should be closed/verified and a new issue opened to manage the special characters in group name failures.
Comment 11 Matt Pusateri 2017-06-15 14:48:33 UTC 
1. I question whether this is a new bug to handle special groups?
2. Is it really a bug, IDM team seems to think it's our SSSD configuration, which JoeV didn't really way in on. If I recall from talking to Jakub, there is a SSSD parameter that controls what to use for groups.
Comment 12 Jakub Hrozek 2017-06-15 14:54:28 UTC 
(In reply to Matt Pusateri from comment #11)
> 1. I question whether this is a new bug to handle special groups?
> 2. Is it really a bug, IDM team seems to think it's our SSSD configuration,
> which JoeV didn't really way in on. If I recall from talking to Jakub, there
> is a SSSD parameter that controls what to use for groups.

The issue is not about special groups or special characters.

The issue is that you put the name with the special characters into the "cn" attribute, but that's not where sssd reads the group name from. It reads the group name from "samaccountname".

From the conversation we had on IRC I understood you expected the "cn" value to be displayed. If yes, then the configuration should be changed to read the group name from "cn" not from "samaccountname".

So really, the question is -- what attributes did the "legacy" CFME connector use to read the groupname from?
Comment 13 Matt Pusateri 2017-06-15 15:43:02 UTC 
In talking with JoeV we'll look at making the configuration change on our side to use ldap_group_name = cn


Marking as verified.
Comment 14 errata-xmlrpc 2017-08-01 09:06:23 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.

https://access.redhat.com/errata/RHEA-2017:2294
Note You need to log in before you can comment on or make changes to this bug.