Bug 683158
Summary: | multiple problems with sssd + ldap (Active-Directory) and groups members. | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | M Boucher <sboucher.secondary> | |
Component: | sssd | Assignee: | Stephen Gallagher <sgallagh> | |
Status: | CLOSED ERRATA | QA Contact: | Chandrasekar Kannan <ckannan> | |
Severity: | high | Docs Contact: | ||
Priority: | unspecified | |||
Version: | 6.0 | CC: | benl, dpal, grajaiya, jgalipea, kbanerje, kemot1000, prc | |
Target Milestone: | rc | |||
Target Release: | --- | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | sssd-1.5.1-16.el6 | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 690093 (view as bug list) | Environment: | ||
Last Closed: | 2011-05-19 11:39:00 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: | 690093 | |||
Attachments: |
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 Created attachment 483009 [details] LDAP result for comment 2 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. 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). 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. 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). 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. 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? Sorry, please try again. I forgot to include the krb5 dependencies in that repo. I've added them now. 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 ?!
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. 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.
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. 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. Can you please add steps to reproduce this bug? Created attachment 486836 [details]
sssd log with debug level 10 (1.5.1-15.el6.0.1.x86_64)
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. *** Bug 691678 has been marked as a duplicate of this bug. *** So far, so good... I think we can say this bug is fixed. Will those changes be in RHEL 6 patch 1 ? Yes, it's already slated for inclusion. Based on comment #18 and #21, marking bug customer verified 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 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 |
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