Bug 1449729

Summary:	org.freedesktop.sssd.infopipe.GetUserGroups does not resolve groups into names with AD
Product:	Red Hat Enterprise Linux 7	Reporter:	Jakub Hrozek <jhrozek>
Component:	sssd	Assignee:	SSSD Maintainers <sssd-maint>
Status:	CLOSED ERRATA	QA Contact:	Matt Pusateri <mpusater>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.3	CC:	grajaiya, igortiunov, jhrozek, jreznik, jvlcek, lmiksik, lslebodn, mkosek, mzidek, pbrezina, sgoveas, sssd-maint, tscherf
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.15.2-43.el7	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-01 09:06:23 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1432518

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