691678 – SSSD needs to fall back to 'cn' for GECOS information (was: SSSD configuration problem when configured with MSAD)

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 691678 - SSSD needs to fall back to 'cn' for GECOS information (was: SSSD configuration problem when configured with MSAD)

Summary: SSSD needs to fall back to 'cn' for GECOS information (was: SSSD configuratio...

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 6
Classification:	Red Hat
Component:	sssd
Sub Component:
Version:	6.0
Hardware:	x86_64
OS:	Unspecified
Priority:	unspecified
Severity:	high
Target Milestone:	rc
Target Release:	---
Assignee:	Stephen Gallagher
QA Contact:	Chandrasekar Kannan
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	691900 692090 748822
TreeView+	depends on / blocked

Reported:	2011-03-29 08:54 UTC by Kemot1000
Modified:	2015-01-04 23:47 UTC (History)
CC List:	7 users (show)
Fixed In Version:	sssd-1.5.1-28.el6
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Clones:	691900 692090 (view as bug list)
Environment:
Last Closed:	2011-05-19 11:39:17 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHSA-2011:0560	0	normal	SHIPPED_LIVE	Low: sssd security, bug fix, and enhancement update	2011-05-19 11:38:17 UTC

Description Kemot1000 2011-03-29 08:54:50 UTC

Description of problem:
I configured SSSD with kerberos authentication over MSAD (Windows Server 2003) on RHEL6. Before I had this on RHEL 5 configured with ldap.conf and krb5.conf. 
1. When I use enumerate true in sssd.conf I see groups returned with 'id DOMAINUSER' that are not defined as Linux groups. 
2. Also 'getent group GROUPNAME' works for groups that are not defined as Linux Groups(no GID on domain level)
3. 'getent passwd DOMAINUSER' doesn't show username as it used to only empty space
4. SSSD not showing group membership when account not added as group member under Unix Attributes on AD 

This was not happening in RHEL 5 configuration.  
See actual and expected results below. 

Version-Release number of selected component (if applicable):
sssd-client-1.2.1-28.el6_0.4.x86_64
sssd-1.2.1-28.el6_0.4.x86_64

How reproducible:
sssd.conf
[domain/AD]
description = AD Domain Controller server
enumerate = true
min_id = 10000

id_provider = ldap
#auth_provider = ldap
auth_provider = krb5
ldap_uri = ldap://example.com
ldap_schema = rfc2307bis
ldap_user_search_base = DC=example,DC=com
ldap_group_search_base = DC=example,DC=com
ldap_default_bind_dn = CN=List,OU=General,OU=Users,DC=example,DC=com
ldap_default_authtok_type = password
ldap_default_authtok = SOMEPASSWORD

ldap_user_object_class = user
ldap_user_name = uid
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = unixHomeDirectory
ldap_user_shell = loginShell
ldap_user_principal = userPrincipalName

ldap_group_object_class = group
ldap_group_name = name
ldap_group_member = member
ldap_group_gid_number = gidNumber
ldap_force_upper_case_realm = True

#krb5
krb5_kdcip = IPADDRESS
krb5_realm = EXAMPLE.COM
krb5_validate = true
krb5_keytab = /etc/krb5.keytab
krb5_store_password_if_offline = true
cache_credentials = true

krb5.conf
[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = EXAMPLE.COM
 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = yes
 default_keytab_name = FILE:/etc/krb5.keytab

[realms]
 EXAMPLE.COM = {
  kdc = IPADDRESS:88
  kdc = IPADDRESS2:88
  admin_server = IPADDRESS:749
  default_domain = example.com
 }

[domain_realm]
 .EXAMPLE.COM =  EXAMPLE.COM
 EXAMPLE.COM =  EXAMPLE.COM
 .example.com = example.com
 example.com = example.com

[appdefaults]
 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
   validate = true
 }

added sss in nsswitch.conf 

Steps to Reproduce:
1. Execute 'id DOMAINUSER' on console
2. Execute 'getent group DOMAINGROUPNAME'
3. Execute 'getent passwd DOMAINUSER'
4. Execute 'getent group domaingroup2' for group with no users defined under Unix Attributes tab on domain

Actual results:
1. 
[root@localhost ~]# id DOMAINUSER
uid=10041(DOMAINUSER) gid=10001(Linux_Users) groups=10001(Linux_Users),10656(ReadOnlyGroup)
2.
[root@localhost ~]# getent group ReadOnlyGroup
ReadOnlyGroup:*:10656:DOMAINUSER4,DOMAINUSER2,DOMAINUSER3,DOMAINUSER
3.
[root@localhost ~]# getent passwd DOMAINUSER
DOMAINUSER:*:10041:10001::/home/DOMAINUSER:/bin/bash
4. 
[root@localhost ~]$ getent group domaingroup2
No results


Expected results:
1. 
[root@localhost ~]$ id DOMAINUSER
uid=10041(DOMAINUSER) gid=10001(Linux_Users) groups=10001(Linux_Users)
2.
[root@localhost ~]# getent group ReadOnlyGroup
No results
3.
[root@localhost ~]# getent passwd DOMAINUSER
DOMAINUSER:*:10041:10001:Domain Username:/home/DOMAINUSER:/bin/bash
4. 
[root@localhost ~]$ getent group domaingroup2
domaingroup2:*:10045:domainuser12,domainuser22

Additional info:
group 10656(ReadOnlyGroup) is not defined on Domain as Unix group so actually it doesn't have gid 10656
domaingroup2:*:10045 has no users defined under Unix Attributes tab

Comment 2 Stephen Gallagher 2011-03-29 11:20:29 UTC


*** This bug has been marked as a duplicate of bug 683158 ***

Comment 3 Kemot1000 2011-03-29 14:49:43 UTC

I updated to 
sssd-client-1.5.1-15.el6.0.1.x86_64
sssd-1.5.1-15.el6.0.1.x86_64

and will check all the other but this is for sure still not returning names 

is:
[root@localhost ~]# getent passwd DOMAINUSER
DOMAINUSER:*:10041:10001::/home/DOMAINUSER:/bin/bash
should be:
[root@localhost ~]# getent passwd DOMAINUSER
DOMAINUSER:*:10041:10001:Domain Username:/home/DOMAINUSER:/bin/bash

Comment 4 Stephen Gallagher 2011-03-29 15:07:11 UTC

My guess is that you need to set
'ldap_user_gecos = cn' in your sssd.conf.

It defaults to the 'gecos' attribute, but this is not present in all environments. We have an open bug upstream to support fallback to the 'cn' attribute, but for now you need to set this explicitly.

If AD uses a different attribute for user full name, set ldap_user_gecos to be that attribute.

You may need to purge your cache (rm -f /var/lib/sss/db/cache_AD.ldb) and restart SSSD for this to take effect.

Comment 5 Stephen Gallagher 2011-03-29 20:19:53 UTC

Reopening this ticket.

As mentioned in comment #4 we had upstream bug https://fedorahosted.org/sssd/ticket/703 to track this issue.

I think we need to get this fixed in Red Hat Enterprise Linux 6.1, so I'm going to target this bug to that fix.

Comment 7 Kemot1000 2011-03-30 09:27:37 UTC

With sssd-1.5.1-15.el6.0.1.x86_64:

1. This is solved:

When I use enumerate true in sssd.conf I see groups returned with 'id
DOMAINUSER' that are not defined as Linux groups.

2. This is solved:

Also 'getent group GROUPNAME' works for groups that are not defined as Linux
Groups(no GID on domain level)

3. This is solved when added per your advice ldap_user_gecos = cn into sssd.conf

'getent passwd DOMAINUSER' doesn't show username as it used to only empty
space

4. SSSD not showing group membership when account not added as group member
under Unix Attributes on AD

This is still keeping me from switching to sssd since I would have to check hundreds of groups and add memberships.

Right now I would like to keep this setup:

1. I create domain local group in AD

domainlocalgroup

2. Add NIS Domain and GID on UNIX Attributes tab in Active Directory Users and Computers for domainlocalgroup

3. Create domain global group in AD as a member of domainlocalgroup
:

domainglobal

4. Add user members to domainglobal group that are defined in AD as a Linux Users

linuxuser1
linuxuser2

with above setup on old configuration I get
[root@localhost ~]$ getent group |grep -i domainlocalgroup
domainlocalgroup:*:10045:linuxuser1,linuxuser2

and on new sssd configuration:

[root@localhost ~]# getent group |grep -i domainlocalgroup
domainlocalgroup:*:10045:

so it looks that there is some problem with nested groups

This setup allows us to limit number of groups returned with 'getent group' as we have to only define Unix Attributes for the first group and users and not to all the groups below. With complicated membership setup I think that would be a great advantage.

Comment 8 Stephen Gallagher 2011-03-30 12:03:02 UTC

I split this ticket off into BZ #692090

This ticket is tracking the cn/GECOS fix. We will look into the nested groups issue in 692090.

Comment 10 Kaushik Banerjee 2011-04-06 15:20:32 UTC

Fallback from gecos to cn works now.

Steps to test:
1. Add a user user1 with gecos attribute as:
   uid: user1
   gecos: USER1 GECOS
   cn: user1
   ...
2. Appropriate gecos is returned.
   # getent passwd user1
   user1:*:11001:11001:USER1 GECOS :/home/user1:/bin/bash

3. Add a user user2 without a gecos attribute.
   uid: user2
   cn: user2
   ...
4. In absence of gecos, cn is returned appropriately.
   #getent passwd user2
   user2:*:11002:11002:user2:/home/user2:/bin/bash

Version:
# rpm -qi sssd | head
Name        : sssd                         Relocations: (not relocatable)
Version     : 1.5.1                             Vendor: Red Hat, Inc.
Release     : 24.el6                        Build Date: Sat 02 Apr 2011 01:24:54 AM IST
Install Date: Wed 06 Apr 2011 07:17:24 PM IST      Build Host: x86-012.build.bos.redhat.com
Group       : Applications/System           Source RPM: sssd-1.5.1-24.el6.src.rpm
Size        : 3462740                          License: GPLv3+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon

Comment 11 Kaushik Banerjee 2011-04-12 19:40:59 UTC

Reopening, this fix was incomplete.

Steps to reproduce:
1. Add a user without gecos attribute.
2. getent passwd user(gecos field is seen).
3. log in as user.
4. getent passwd user (gecos field missing after the second enumeration).

Comment 13 Kaushik Banerjee 2011-04-13 13:12:08 UTC

Steps to test:
1. Add a user user07 without gecos attribute.

2. Enumerate user07.
getent -s sss passwd user07
user07:*:20007:20007:user07:/home/user07:/bin/bash

3. Auth as user07.

4. Again enumerate user07.
getent -s sss passwd user07
user07:*:20007:20007:user07:/home/user07:/bin/bash

Verified in version:
# rpm -qi sssd | head
Name        : sssd                         Relocations: (not relocatable)
Version     : 1.5.1                             Vendor: Red Hat, Inc.
Release     : 28.el6                        Build Date: Wed 13 Apr 2011 01:25:54 AM IST
Install Date: Wed 13 Apr 2011 03:06:48 PM IST      Build Host: x86-003.build.bos.redhat.com
Group       : Applications/System           Source RPM: sssd-1.5.1-28.el6.src.rpm
Size        : 3462869                          License: GPLv3+
Signature   : (none)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
URL         : http://fedorahosted.org/sssd/
Summary     : System Security Services Daemon

Comment 14 errata-xmlrpc 2011-05-19 11:39:17 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0560.html

Comment 15 errata-xmlrpc 2011-05-19 13:10:14 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2011-0560.html

Note You need to log in before you can comment on or make changes to this bug.