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 683158 - multiple problems with sssd + ldap (Active-Directory) and groups members.
Summary: multiple problems with sssd + ldap (Active-Directory) and groups members.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 690093
TreeView+ depends on / blocked
 
Reported: 2011-03-08 17:32 UTC by M Boucher
Modified: 2020-05-02 16:19 UTC (History)
7 users (show)

Fixed In Version: sssd-1.5.1-16.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 690093 (view as bug list)
Environment:
Last Closed: 2011-05-19 11:39:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
sssd log with debug level 10 (1.09 MB, application/octet-stream)
2011-03-08 17:32 UTC, M Boucher
no flags Details
LDAP result for comment 2 (3.48 KB, text/plain)
2011-03-08 20:27 UTC, M Boucher
no flags Details
sssd log with debug level 10 (version 1.5.1) (5.98 MB, application/octet-stream)
2011-03-10 17:07 UTC, M Boucher
no flags Details
sssd log with debug level 10 (version 1.5.1-14.el6.0.1.x86_64) (1.63 MB, application/octet-stream)
2011-03-11 20:12 UTC, M Boucher
no flags Details
sssd log with debug level 10 (1.5.1-15.el6.0.1.x86_64) (799.07 KB, application/octet-stream)
2011-03-22 16:22 UTC, M Boucher
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 1866 0 None closed SSSD fails group lookups when group is missing GID 2020-09-18 13:50:55 UTC
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

Internal Links: 1003067

Description M Boucher 2011-03-08 17:32:29 UTC
Created attachment 482960 [details]
sssd log with debug level 10

Description of problem:

I've setup sssd with rhel6.0 and so far, everything works fine, except groups members are missing. 'id <user>' returns only primary group and 'getent group' returns a bunch of groups, ids but no users. So far, it looks like a bug we can read many times on this site.

Now, a deeper look on setup. My ldap server is Active-Directory 2008 R2. On my rhel5.x servers, I use nss_ldap with the same ldap/krb5 setup, everything works fine. So, I don't think my AD is a problem.

On my rhel6.0/sssd, when I use 'getent group' I see a bunch of groups and their gid. When I compare them with my actual ldap groups, I realize that it shows all my groups with gidNumber assigned to them, and also a bunch of groups that don't have gidNumbers assigned to them. These groups shouldn't show up at all.

Also, all my groups, except two, don't list any members which, of course, is not good. The strange thing here is for two groups, I see 1 member ?!?!?

If you look deeper into those two groups and that peticular member. First, those two groups shouldn't show up because they don't have gidNumbers assigned to them. Second, the member shown up in those two groups should be member of many other groups and we don't see that in the 'getent group' list. Third, if I use 'id <user>' and 'getent group' and compare the two. Both don't match! These's one group that I see in 'id' that I don't see in 'getent group'.

Take note that all my ldap groups have gid over 500.


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

How reproducible:
 always, on every rhel6.0 that I have.

Steps to Reproduce:
1. start the service
2. wait 2-3 seconds...
3. that's it 
  
Actual results:
 1-groups members in getent,id is wrong.
 2-groups not supposed to show up actually show up.

Expected results:
 1-make the groups members in getent,id right
 2-show groups that have gidNumbers assigned

Additional info:

 Here's my sssd.conf config:

[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = DOMAIN

[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3


[pam]
reconnection_retries = 3


[domain/DOMAIN]
debug_level=10
enumerate = true
min_id = 501
max_id = 0
id_provider = ldap
chpass_provider = ldap
ldap_uri = ldap://domain.com
ldap_search_base = dc=domain,dc=com
ldap_user_search_base = dc=domain,dc=com
ldap_group_search_base = dc=dc=domain,dc=com
ldap_schema = rfc2307bis
ldap_default_bind_dn = cn=ldap-linux,cn=users,dc=domain,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = <password>

# LDAP attributes
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

auth_provider = krb5
cache_credential = true;
krb5_kdcip = domain.com
krb5_realm = DOMAIN.COM
;krb5_changepw_principal = kadmin/changepw
krb5_ccachedir = /tmp
;krb5_ccname_template = FILE:%d/krb5cc_%U_XXXXXX
krb5_auth_timeout = 15

Comment 2 Stephen Gallagher 2011-03-08 20:13:28 UTC
This looks like a server misconfiguration issue. You have a group called dept-it that appears to be missing its gidNumber.

Can you show the output of
ldapsearch -x -W -H ldap://domain.com -b dc=dc=domain,dc=com -D cn=ldap-linux,cn=users,dc=domain,dc=com name=dept-it

I suspect that gidNumber will be missing or unreadable

Comment 3 M Boucher 2011-03-08 20:27:20 UTC
Created attachment 483009 [details]
LDAP result for comment 2

Comment 4 M Boucher 2011-03-08 20:35:26 UTC
The gidNumber for dept-it is missing and it doesn't show up in 'getent group'. This is expected behavior. It's not a good test for this bug.

Look in the logs if you see anything about 'dept-opit' which has an gidNumber and should list people in it and don't do so. 

Or, the group called 'acl_General-common-RO' which shows up in 'getent group' and should not because it doesn't have any gidNumber.

Comment 5 Stephen Gallagher 2011-03-08 20:40:00 UTC
This group is not a posixGroup (which I notice now that you have changed ldap_user_object_class and ldap_group_object_class to be user and group instead of posixUser and posixGroup).

This won't work, as Linux clients require that every user has:
 * user name
 * user id
 * primary group id
 * gecos/cn
 * home directory
 * shell

and every group has
 * group name
 * group id
 * members (member or memberuid, depending on ldap_schema)

The ActiveDirectory "group" objectClass does not mandate the group ID, and therefore is insufficient for use with SSSD (or any other Linux client).

Comment 6 Stephen Gallagher 2011-03-08 20:43:37 UTC
Please remove the ldap_user_object_class and ldap_group_object_class options in sssd.conf. This will set them back to their default of posixAccount and posixGroup, which is necessary for SSSD to function. (The only reason this option exists is for support of very old AD servers that didn't provide the posixAccount and posixGroup attributes). Active Directory 2003R2 and later provides the correct objectclasses and should be preferred.

Comment 7 M Boucher 2011-03-08 21:22:33 UTC
I removed them, but now no users or groups show up. After a closer look at my AD, I see that none of my users/groups are Class posixAccount/posixGroup. 
Honestly, I don't think this is the source of the bug.

On my rhel 5.x, I use nss_ldap and it works good with my AD as is. The setup simply filters the accounts/groups that don't have all required attributes and don't show them into linux. My opinion, sssd should do the same. 

What is happening now, with sssd, is that I see in linux groups that don't have gidNumbers don't see group members that have all required attributes (like dept-opit).

Comment 8 Stephen Gallagher 2011-03-09 20:29:29 UTC
Would you mind testing out a pre-release build? I think your problem may be fixed with the newer SSSD 1.5.1 which is targeted for inclusion in RHEL 6.1 (we've done a lot of cleanup work on RFC2307bis systems).

I've made the build available in a yum repository, you can access it by creating the file /etc/yum.repos.d/sssd-683158.repo on your system with the following contents:

[sssd-683158]
name=SSSD pre-release builds
baseurl=http://sgallagh.fedorapeople.org/repo/683158/$basearch/
enabled=1
gpgcheck=0


Then run 'yum update sssd' from the command-line. This should install sssd-1.5.1-14.el6 on your system. Please test with this build whether your group issues go away.

Comment 9 M Boucher 2011-03-10 16:03:31 UTC
no, I don't mind using pre-release builds. yum update sssd is complaning about dependencies "Requires: krb5-libs >= 1.9". I don't know if the tests would be valid without the right libs. Any idea where I could get it?

Comment 10 Stephen Gallagher 2011-03-10 16:07:35 UTC
Sorry, please try again. I forgot to include the krb5 dependencies in that repo. I've added them now.

Comment 11 M Boucher 2011-03-10 17:07:18 UTC
Created attachment 483514 [details]
sssd log with debug level 10 (version 1.5.1)

I installed the pre-build version. Now I'm unable to list any LDAP users or groups with getent! I included the log in attachemnt.

We're able to see this at some point in the log regarding "dept-opit":

(7): Adding member users to group [dept-opit]
(Thu Mar 10 11:56:06 2011) [sssd[be[CORPO]]] [sdap_fill_memberships] (9): [IPA or AD Schema]
(Thu Mar 10 11:56:06 2011) [sssd[be[CORPO]]] [sdap_save_grpmem] (2): Failed to save user dept-opit
(Thu Mar 10 11:56:06 2011) [sssd[be[CORPO]]] [sdap_save_groups] (2): Failed to store group 215 members.
(Thu Mar 10 11:56:06 2011) [sssd[be[CORPO]]] [sdap_save_grpmem] 

also at the end we can see a bunch of errors about cache connection, maybe you could tell me what this is ?!

Comment 12 Stephen Gallagher 2011-03-11 10:55:12 UTC
I've opened https://fedorahosted.org/sssd/ticket/824 upstream to track the missing GID issue. I've updated the SSSD build in the repo above with a potential fix for that part of the problem. Let's see how much this clears up.

Please try the new build (sssd-1.5.1-14.el6.0.1) and send report back (with logs).

I suspect there are two bugs here, so I want to take the known GID issue out of the picture.

Comment 13 M Boucher 2011-03-11 20:12:04 UTC
Created attachment 483807 [details]
sssd log with debug level 10 (version 1.5.1-14.el6.0.1.x86_64)

I'm able to list my users, but none of the groups with getent group. I attached the log.

Comment 14 Stephen Gallagher 2011-03-21 15:42:47 UTC
Sorry for the long delay. I think I've located the problem.

We're generating a bad search filter in sdap_find_entry_by_origDN() because we're being given an origDN value that contains a backslash and a comma. We need to convert this origDN to use \2C instead.

I should have a new build for you to test soon.

Comment 15 Stephen Gallagher 2011-03-21 20:40:37 UTC
Ok, I think (hope) we've got this fixed now. Please try out sssd-1.5.1-15.el6.0.1 which I've uploaded to the same repository as above.

Let me know if this works for you. If not, please provide logs again.

Comment 16 Jenny Severance 2011-03-22 14:50:02 UTC
Can you please add steps to reproduce this bug?

Comment 17 M Boucher 2011-03-22 16:22:06 UTC
Created attachment 486836 [details]
sssd log with debug level 10 (1.5.1-15.el6.0.1.x86_64)

Comment 18 M Boucher 2011-03-22 16:38:42 UTC
The new version 1.5.1-15.el6.0.1.x86_64 seems to be working fine! I'm able to see only the groups that have the right attributes and none of those that don't and I also see group members from each of those groups.

There wasn't any steps to reproduce the bug really. Just updated the rpms and restarted the service using same config. But now, everything works good.

I'll test it more within the next few days, but it look good so far.

Comment 20 Stephen Gallagher 2011-03-29 11:20:29 UTC
*** Bug 691678 has been marked as a duplicate of this bug. ***

Comment 21 M Boucher 2011-03-30 18:07:14 UTC
So far, so good...

I think we can say this bug is fixed.

Will those changes be in RHEL 6 patch 1 ?

Comment 22 Stephen Gallagher 2011-03-30 18:37:05 UTC
Yes, it's already slated for inclusion.

Comment 23 Jenny Severance 2011-03-30 18:43:58 UTC
Based on comment #18 and #21, marking bug customer verified

Comment 24 errata-xmlrpc 2011-05-19 11:39:00 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 25 errata-xmlrpc 2011-05-19 13:09:51 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.