Bug 1180684
Summary: | Active directory SSSD/Kerberos/LDAP configuration get uid wrong for group member list | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Allen Zhao <a.zhao> | ||||||
Component: | sssd | Assignee: | Lukas Slebodnik <lslebodn> | ||||||
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Kaushik Banerjee <kbanerje> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | unspecified | ||||||||
Version: | 6.6 | CC: | a.zhao, grajaiya, jgalipea, jhrozek, lslebodn, mkosek, mzidek, pbrezina, preichl | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2015-04-30 06:37:12 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Allen Zhao
2015-01-09 16:57:37 UTC
For /etc/nsswitch.conf: passwd: files sss shadow: files sss group: files sss For /etc/sssd/sssd.conf: [domain/default] id_provider = ldap ldap_uri = ldap://server1.gtisoft.com,ldap://server2.gtisoft.com ldap_search_base = dc=gtisoft,dc=com ldap_default_bind_dn = cn=ldapadmin,cn=Users,dc=gtisoft,dc=com ldap_default_authtok_type = password ldap_default_authtok = yyyyyyyy auth_provider = krb5 chpass_provider = krb5 krb5_kpasswd = server1.gtisoft.com,server2.gtisoft.com krb5_server = server1.gtisoft.com,server2.gtisoft.com krb5_realm = GTISOFT.COM krb5_kdcip = server1.gtisoft.com,server2.gtisoft.com cache_credentials = True ldap_user_object_class = person ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_principal = userPrincipalName ldap_user_home_directory = unixHomeDirectory ldap_user_name = sAMAccountName ldap_user_shell = loginShell ldap_group_object_class = group ldap_group_name = sAMAccountName ldap_group_gid_number = gidNumber ldap_force_upper_case_realm = True ldap_id_use_start_tls = False ldap_tls_cacertdir = /etc/openldap/cacerts [sssd] services = nss, pam config_file_version = 2 domains = default [nss] [pam] [sudo] [autofs] [ssh] [pac] (In reply to Allen Zhao from comment #0) > Description of problem: > > We recently configured a rhel 6.6 based file server integrated with Windows > server 2008R2 using sssd. We notice that for some users who have capital > letter in their user name on Windows AD, the `id <user>` and `getent group > <group>` will give wrong results, and therefore causing permission issue in > the file server operation (both NFS and Samba). > > Example: an user who has a uid as JonZ on Active Directory. > > > On a Solaris 10 and RHEL5.x (AD/Krb5/LDAP) box, > > Version-Release number of selected component (if applicable): > > > How reproducible: > > Steps to Reproduce: > 1. Create an user on Windows 2008R2 with JonZ as uid, do a `getent passwd > jonz` > 2. do a `id JonZ` and `id jonz` > 3. do a `getent group Marketing` where JonZ is a member on the active > directory > > Actual results: > [root@strauss models]# getent passwd jonz > jonz:*:8597:302:Jon ZXXX:/User/jonz:/bin/bash > [root@strauss models]# id JonZ > id: JonZ: No such user > [root@strauss models]# id jonz > uid=8597(jonz) gid=302(Support) groups=302(Support) > [root@strauss models]# getent group Marketing > Marketing:*:312:JonZ You are using "id_provider = ldap" which is by default case sensitive. You can change this behaviour with the configuration option case_sensitive in domain section. man sssd.conf -> case_sensitive >For /etc/nsswitch.conf: >passwd: files sss >shadow: files sss >group: files sss What is a value of a key "initgroups"? By default it should be commented out otherwise it can explain why "id jonz" did not return groups. A workaround to fix above issue is to update the AD using ADSI Edit: For the offending user: update the msSFU30Name to all lower case, For the troubling group: update the memberUid to use the lower case uid. Then of course, restart the sssd and cleanup all cache. But my problem is that Solaris and RHEL5 integrated with AD using Krb5/LDAP can all handle the case perfect, why sssd is so bad about it? I think this is a bug. (In reply to Lukas Slebodnik from comment #2) > (In reply to Allen Zhao from comment #0) > You are using "id_provider = ldap" which is by default case sensitive. > > You can change this behaviour with the configuration option case_sensitive > in domain section. > > man sssd.conf -> case_sensitive > We tried this, it brought all user/group name to lowercase when doing a `id <user>`, and `getent group`. But it does not fix the file access permission issue. Is that another bug? > > >For /etc/nsswitch.conf: > > >passwd: files sss > >shadow: files sss > >group: files sss > What is a value of a key "initgroups"? > By default it should be commented out otherwise it can explain why "id jonz" > did not return groups. There is no "initgroups" line in our nsswitch.conf (In reply to Allen Zhao from comment #5) > (In reply to Lukas Slebodnik from comment #2) > > (In reply to Allen Zhao from comment #0) > > > You are using "id_provider = ldap" which is by default case sensitive. > > > > You can change this behaviour with the configuration option case_sensitive > > in domain section. > > > > man sssd.conf -> case_sensitive > > > > We tried this, it brought all user/group name to lowercase when doing a `id > <user>`, and `getent group`. But it does not fix the file access permission > issue. Is that another bug? > In this case, we need to see sssd log files. 1. Add "debug_level = 9" into domain and nss section of sssd.conf. 2. Remove sssd cache and log files rm -f /var/lib/sss/{db,mc}/* /var/log/sssd/* 3. start sssd 4. reproduce problem id jonz 5. Attach log files to this BZ. > > > > >For /etc/nsswitch.conf: > > > > >passwd: files sss > > >shadow: files sss > > >group: files sss > > What is a value of a key "initgroups"? > > By default it should be commented out otherwise it can explain why "id jonz" > > did not return groups. > > There is no "initgroups" line in our nsswitch.conf That's good. On a UNIX system, file permissions have nothing to do with case sensitiveness of a user name. It's really about user ID and group membership. What is the file ownership of the file that denies access? Do you expect to be allowed based on your ownership or the group membership? Can you paste (sanitized) output of "stat(1)" on the file you're trying to access and the output of "id -G $username" ? (In reply to Jakub Hrozek from comment #7) > On a UNIX system, file permissions have nothing to do with case > sensitiveness of a user name. It's really about user ID and group membership. I know. it is all about getuid() and getgid() calls. > > What is the file ownership of the file that denies access? Do you expect to > be allowed based on your ownership or the group membership? We have a directory that is readable only by people in Marketing group. When I say accessible denied, it means that this jonz user can not go there, even though on AD he is in the Marketing group. On linux, I use the `getent group Marketing` to identify the issue. With case_sensitive=false setting: [root@strauss realtimes]# id jonz uid=8597(jonz) gid=302(support) groups=302(support) [root@strauss realtimes]# id JonZ uid=8597(jonz) gid=302(support) groups=302(support) [root@strauss realtimes]# getent group Marketing marketing:*:312:jonz you see from `id` that jonz is not in marketing group, and directory access is naturally denied. > > Can you paste (sanitized) output of "stat(1)" on the file you're trying to > access and the output of "id -G $username" ? Access: (2770/drwxrws---) Uid: ( 8543/ tomw) Gid: ( 312/Marketing) BTW, because case_sensitive=false does not resolve the issue, let's not to focus on that. It is just a side trap. The main thing: why I can not see jonz in Marketing group from `id jonz` Created attachment 978375 [details]
sssd_default.log and sssd_nss.log for `id jonz` and `id JonZ`
This is a log from a production environment. So it will have stuff other than the `id jonz` and `id JonZ` command.
(In reply to Lukas Slebodnik from comment #6) > In this case, we need to see sssd log files. > > 1. Add "debug_level = 9" into domain and nss section of sssd.conf. > 2. Remove sssd cache and log files > rm -f /var/lib/sss/{db,mc}/* /var/log/sssd/* > 3. start sssd > 4. reproduce problem > id jonz > 5. Attach log files to this BZ. Check the log.tgz I just attached. The command I did: [root@strauss models]# id jonz uid=8597(jonz) gid=302(Support) groups=302(Support) [root@strauss models]# id JonZ id: JonZ: No such user Well it is a busy production machine (I do not have a test machine for this), so the log collected could be populated by real user access. In fact, the issue is a very unpleasant discovery after a major file server migration from Solaris10 to RHEL6. We are just hit by big surprise and user cries - almost to the point I have to either move back to Solaris or replace sssd with krb5/ldap as the AD integration mechanism. From log: (Fri Jan 9 13:16:59 2015) [sssd[be[default]]] [sdap_save_user] (0x0400): Original memberOf is not available for [jonz]. From my first comment (ldapsearch result section for user jonz): memberOf: CN=GUI,CN=Users,DC=gtisoft,DC=com memberOf: CN=Support,CN=Users,DC=gtisoft,DC=com memberOf: CN=Marketing,CN=Users,DC=gtisoft,DC=com memberOf: CN=Solver,CN=Users,DC=gtisoft,DC=com Does it tell us something? (In reply to Allen Zhao from comment #10) > > Check the log.tgz I just attached. > > The command I did: > [root@strauss models]# id jonz > uid=8597(jonz) gid=302(Support) groups=302(Support) Log files does not contain output from this command. sh$ grep be_get_account sssd_default.log (Fri Jan 9 13:16:59 2015) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=JonZ] (Fri Jan 9 13:17:06 2015) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=kathy] (Fri Jan 9 13:17:06 2015) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=kathy] (Fri Jan 9 13:17:11 2015) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=8586] (Fri Jan 9 13:17:29 2015) [sssd[be[default]]] [be_get_account_info] (0x0100): Got request for [4097][1][idnumber=8492] > [root@strauss models]# id JonZ > id: JonZ: No such user just his one and we are not interested in that output. (Fri Jan 9 13:16:59 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [default][4097][1][name=JonZ] (Fri Jan 9 13:16:59 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x418850:1:JonZ@default] (Fri Jan 9 13:17:00 2015) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (Fri Jan 9 13:17:00 2015) [sssd[nss]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/default/JonZ] (Fri Jan 9 13:17:00 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [JonZ@default] (Fri Jan 9 13:17:00 2015) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/default/JonZ] to negative cache (Fri Jan 9 13:17:00 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0040): No results for getpwnam call Please follow next instructions: 1. stop sssd service sssd stop 2. Remove sssd cache and log files rm -f /var/lib/sss/{db,mc}/* /var/log/sssd/* 3. start sssd service sssd start 4. reproduce problem id jonz 5. Attach log files to this BZ. Created attachment 978524 [details]
2nd try
(In reply to Lukas Slebodnik from comment #12) > (In reply to Allen Zhao from comment #10) > > > > Check the log.tgz I just attached. > > > > The command I did: > > [root@strauss models]# id jonz > > uid=8597(jonz) gid=302(Support) groups=302(Support) > Log files does not contain output from this command. > sh$ grep be_get_account sssd_default.log > (Fri Jan 9 13:16:59 2015) [sssd[be[default]]] [be_get_account_info] > (0x0100): Got request for [4097][1][name=JonZ] > (Fri Jan 9 13:17:06 2015) [sssd[be[default]]] [be_get_account_info] > (0x0100): Got request for [4097][1][name=kathy] > (Fri Jan 9 13:17:06 2015) [sssd[be[default]]] [be_get_account_info] > (0x0100): Got request for [4099][1][name=kathy] > (Fri Jan 9 13:17:11 2015) [sssd[be[default]]] [be_get_account_info] > (0x0100): Got request for [4097][1][idnumber=8586] > (Fri Jan 9 13:17:29 2015) [sssd[be[default]]] [be_get_account_info] > (0x0100): Got request for [4097][1][idnumber=8492] Strange, I thought I have been careful enough not to let cache get into the game. Anyway, please the 2nd try. For this try (now that no one works during weekend, the log will be less dirty), the logs are corresponding to following session: [root@strauss models]# id allen uid=1004(allen) gid=301(Solver) groups=301(Solver),307(RealTime),306(License),305(WebMgr),302(Support),300(GUI) [root@strauss models]# id jonz uid=8597(jonz) gid=302(Support) groups=302(Support) [root@strauss models]# id steven uid=8526(steven) gid=302(Support) groups=302(Support),311(Accounting),303(Release),310(FRM_DATABASE) I use allen/steven to tag the before and after of the `id jonz`. > > > [root@strauss models]# id JonZ > > id: JonZ: No such user > just his one and we are not interested in that output. May I know why `id JonZ` failure is not important? I am well aware of the fact that on Unix/Linux, username is case sensitive, but consider this is a file server serving both NFS (30% to Unix/Linux users) and Samba (70% to Windows users), I have to ask for a fix for this for 2 reasons: 1) Solaris10 and RHEL5.x (both use krb5/ldap to do the Active Directory integration) will work great for such query, why sssd implementation should change the behavior? If I were the developer, I would strive to make the user experience the same with regardless to the subsystem is krb5/ldap or sssd. Shouldn't this be expected as RHEL is an 'enterprise' OS? We have been hosting our file server on Solaris10 for the last 5 years. A sudden change of behavior is certainly not welcoming sign, no matter how fixable it is. 2) Windows users are educated that case in login name does not matter. So previous windows sysadmin has been using username such as JonZ, and Windows user uses jonz and JonZ interchangeably. So here is my question (I do not have time to set up a box to test the scenario quickly, but you probably can answer my question based on the sssd code implementation): When `id JonZ` fails, will user 'JonZ' also gets messed with his samba access permission? (my understand of samba implementation is that it uses getuid() and getgid() system calls to implement the user permission - then it seems the current sssd will let smbd deny access for user 'JonZ', right?) Note: I am both a unix admin, and a well versed Unix/C programmer (did a lot daemon programming for our company), so you can use detailed technical language to convince me. (In reply to Allen Zhao from comment #14) > For this try (now that no one works during weekend, the log will be less > dirty), the logs are corresponding to following session: > > [root@strauss models]# id allen > uid=1004(allen) gid=301(Solver) > groups=301(Solver),307(RealTime),306(License),305(WebMgr),302(Support), > 300(GUI) > [root@strauss models]# id jonz > uid=8597(jonz) gid=302(Support) groups=302(Support) > [root@strauss models]# id steven > uid=8526(steven) gid=302(Support) > groups=302(Support),311(Accounting),303(Release),310(FRM_DATABASE) > > I use allen/steven to tag the before and after of the `id jonz`. > > > > > > [root@strauss models]# id JonZ > > > id: JonZ: No such user > > just his one and we are not interested in that output. > > May I know why `id JonZ` failure is not important? In id=1180684#c5, you confirmed that issue is fixed by changing vale of the option case_sensitive. (In reply to Allen Zhao from comment #11) > From my first comment (ldapsearch result section for user jonz): > > memberOf: CN=GUI,CN=Users,DC=gtisoft,DC=com > memberOf: CN=Support,CN=Users,DC=gtisoft,DC=com > memberOf: CN=Marketing,CN=Users,DC=gtisoft,DC=com > memberOf: CN=Solver,CN=Users,DC=gtisoft,DC=com > > Does it tell us something? memberOf is not in rfc2307 schema which you are using. This is a reason why user jonz does not have correct membership. [sdap_initgr_rfc2307_next_base] (0x0400): Searching for groups with base [dc=gtisoft,dc=com] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0))))][dc=gtisoft,dc=com]. [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! If you want to use the attribute memberOf for groups you need to change ldap schema to rfc2307bis. default value is rfc2307 (man sssd-ldap -> ldap_schema) or you can also fix ldap entries for rfc2307. Put next line to domain section in sssd.conf ldap_schema = rfc2307bis (In reply to Lukas Slebodnik from comment #15) > (In reply to Allen Zhao from comment #14) > > For this try (now that no one works during weekend, the log will be less > > dirty), the logs are corresponding to following session: > > > > [root@strauss models]# id allen > > uid=1004(allen) gid=301(Solver) > > groups=301(Solver),307(RealTime),306(License),305(WebMgr),302(Support), > > 300(GUI) > > [root@strauss models]# id jonz > > uid=8597(jonz) gid=302(Support) groups=302(Support) > > [root@strauss models]# id steven > > uid=8526(steven) gid=302(Support) > > groups=302(Support),311(Accounting),303(Release),310(FRM_DATABASE) > > > > I use allen/steven to tag the before and after of the `id jonz`. > > > > > > > > > [root@strauss models]# id JonZ > > > > id: JonZ: No such user > > > just his one and we are not interested in that output. > > > > May I know why `id JonZ` failure is not important? > In id=1180684#c5, you confirmed that issue is fixed by changing vale of the > option case_sensitive. No, I did not say that, exactly ;) I only confirmed that all output is brought to lower cases with both return the same wrong result, and the file permission issue remains - `id jonz|JonZ` does NOT show him in 'marketing' group. The apparent 'fix' in output does not fix the underlining getuid() or getgid() failure when it comes to directory access for a local user, and I suspect the same for Samba and NFS access. You see my emphasis goes beyond just a command line output success. > > (In reply to Allen Zhao from comment #11) > > From my first comment (ldapsearch result section for user jonz): > > > > memberOf: CN=GUI,CN=Users,DC=gtisoft,DC=com > > memberOf: CN=Support,CN=Users,DC=gtisoft,DC=com > > memberOf: CN=Marketing,CN=Users,DC=gtisoft,DC=com > > memberOf: CN=Solver,CN=Users,DC=gtisoft,DC=com > > > > Does it tell us something? > memberOf is not in rfc2307 schema which you are using. > > This is a reason why user jonz does not have correct membership. > [sdap_initgr_rfc2307_next_base] (0x0400): Searching for groups with base > [dc=gtisoft,dc=com] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(! > (gidNumber=0))))][dc=gtisoft,dc=com]. > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] > [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > > If you want to use the attribute memberOf for groups you need to change ldap > schema to rfc2307bis. default value is rfc2307 (man sssd-ldap -> ldap_schema) > or you can also fix ldap entries for rfc2307. > > Put next line to domain section in sssd.conf > ldap_schema = rfc2307bis I do not recall I used any schema specific mapping in Solaris/RHEL5 integrated with AD using krb5/ldap. Then how do they resolve the group issue? Let's see: On solaris 10, here is the mapping (from `ldapclient list`) NS_LDAP_ATTRIBUTEMAP= group:userpassword=userPassword NS_LDAP_ATTRIBUTEMAP= group:memberuid=memberUid NS_LDAP_ATTRIBUTEMAP= group:gidnumber=gidNumber NS_LDAP_ATTRIBUTEMAP= passwd:gecos=cn NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=gidNumber NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=uidNumber NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=unixHomeDirectory NS_LDAP_ATTRIBUTEMAP= passwd:loginshell=loginShell NS_LDAP_ATTRIBUTEMAP= shadow:shadowflag=shadowFlag NS_LDAP_ATTRIBUTEMAP= shadow:userpassword=userPassword NS_LDAP_OBJECTCLASSMAP= group:posixGroup=group NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=user NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=user So from the mapping, Solaris is using memberUid? But I think I only see memberUid field (when using ADSI Edit) in group entry, not in user entry (see my first comment) For a RHEL5.8 using krb5/ldap to integrated with AD, the ldap.conf contains: pam_filter objectClass=posixAccount nss_base_passwd cn=Users,dc=gtisoft,dc=com?sub nss_base_shadow cn=Users,dc=gtisoft,dc=com?sub nss_base_group cn=Users,dc=gtisoft,dc=com?sub nss_map_objectclass posixAccount user nss_map_objectclass shadowAccount user nss_map_objectclass posixGroup group nss_map_attribute gecos cn nss_map_attribute homeDirectory unixHomeDirectory nss_map_attribute uniqueMember member tls_cacertdir /etc/openldap/cacerts pam_password crypt I do not see it depends on memberOf LDAP field or gives me any hint how it retrieves groups info, and yet both Solaris10/RHEL5.8 all return correct information! So maybe the krb5/ldap are getting group membership info from somewhere else, instead of depending on explicitly a particular LDAP schema? Can sssd does the same (without forcing user to add ldap_schema entry)? Let me ask for it from a different way: We know that both `id` and `getent group` works when I changed JonZ to jonz on AD side (see my comment #4). How does sssd get it correct for the groups info? Now if we turn on the case insensitive on sssd side, (with JonZ still on AD side), can we still do it correct (meaning, having jonz in marketing group)? Upstream ticket: https://fedorahosted.org/sssd/ticket/1872 Sorry about the upstream link, I meant to link a different bugzilla with upstream #1872 (In reply to Allen Zhao from comment #16) > I do not recall I used any schema specific mapping in Solaris/RHEL5 > integrated with AD using krb5/ldap. Then how do they resolve the group issue? I'm quite sure nss_ldap has a built-in mechanism to try both membership by name and membership by DN. See this ticket Nalin filed a while ago: https://fedorahosted.org/sssd/ticket/445 I'm not sure what client implementation Solaris uses, I can't comment on that one. [...] > So maybe the krb5/ldap are getting group membership info from somewhere > else, instead of depending on explicitly a particular LDAP schema? > > Can sssd does the same (without forcing user to add ldap_schema entry)? Right now it can't, you need to pick one and stick to it. We even have a couple of shortcuts and enhancements that are schema-specific, so mixing schemas is not possiblel anyway. > > Let me ask for it from a different way: > > We know that both `id` and `getent group` works when I changed JonZ to jonz > on AD side (see my comment #4). How does sssd get it correct for the groups > info? > > Now if we turn on the case insensitive on sssd side, (with JonZ still on AD > side), can we still do it correct (meaning, having jonz in marketing group)? I see, comment #4 describes working around an issue where the memberUID and user name were only differing in case. I think sssd should support this scenario. LDAP searches should be case-insensitive on the server side anyway. (In reply to Allen Zhao from comment #16) > (In reply to Lukas Slebodnik from comment #15) > > (In reply to Allen Zhao from comment #14) > > > For this try (now that no one works during weekend, the log will be less > > > dirty), the logs are corresponding to following session: > > > > > > [root@strauss models]# id allen > > > uid=1004(allen) gid=301(Solver) > > > groups=301(Solver),307(RealTime),306(License),305(WebMgr),302(Support), > > > 300(GUI) > > > [root@strauss models]# id jonz > > > uid=8597(jonz) gid=302(Support) groups=302(Support) > > > [root@strauss models]# id steven > > > uid=8526(steven) gid=302(Support) > > > groups=302(Support),311(Accounting),303(Release),310(FRM_DATABASE) > > > > > > I use allen/steven to tag the before and after of the `id jonz`. > > > > > > > > > > > > [root@strauss models]# id JonZ > > > > > id: JonZ: No such user > > > > just his one and we are not interested in that output. > > > > > > May I know why `id JonZ` failure is not important? > > In id=1180684#c5, you confirmed that issue is fixed by changing vale of the > > option case_sensitive. > > No, I did not say that, exactly ;) > > I only confirmed that all output is brought to lower cases with both return > the same wrong result, and the file permission issue remains - `id > jonz|JonZ` does NOT show him in 'marketing' group. The apparent 'fix' in > output does not fix the underlining getuid() or getgid() failure when it > comes to directory access for a local user, and I suspect the same for Samba > and NFS access. > > You see my emphasis goes beyond just a command line output success. > > > > > (In reply to Allen Zhao from comment #11) > > > From my first comment (ldapsearch result section for user jonz): > > > > > > memberOf: CN=GUI,CN=Users,DC=gtisoft,DC=com > > > memberOf: CN=Support,CN=Users,DC=gtisoft,DC=com > > > memberOf: CN=Marketing,CN=Users,DC=gtisoft,DC=com > > > memberOf: CN=Solver,CN=Users,DC=gtisoft,DC=com > > > > > > Does it tell us something? > > memberOf is not in rfc2307 schema which you are using. > > > > This is a reason why user jonz does not have correct membership. > > [sdap_initgr_rfc2307_next_base] (0x0400): Searching for groups with base > > [dc=gtisoft,dc=com] > > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > > [(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(! > > (gidNumber=0))))][dc=gtisoft,dc=com]. > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp] > > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged] > > [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > > > > If you want to use the attribute memberOf for groups you need to change ldap > > schema to rfc2307bis. default value is rfc2307 (man sssd-ldap -> ldap_schema) > > or you can also fix ldap entries for rfc2307. > > > > Put next line to domain section in sssd.conf > > ldap_schema = rfc2307bis > > I do not recall I used any schema specific mapping in Solaris/RHEL5 > integrated with AD using krb5/ldap. Then how do they resolve the group issue? > > Let's see: > On solaris 10, here is the mapping (from `ldapclient list`) > NS_LDAP_ATTRIBUTEMAP= group:userpassword=userPassword > NS_LDAP_ATTRIBUTEMAP= group:memberuid=memberUid > NS_LDAP_ATTRIBUTEMAP= group:gidnumber=gidNumber > NS_LDAP_ATTRIBUTEMAP= passwd:gecos=cn > NS_LDAP_ATTRIBUTEMAP= passwd:gidnumber=gidNumber > NS_LDAP_ATTRIBUTEMAP= passwd:uidnumber=uidNumber > NS_LDAP_ATTRIBUTEMAP= passwd:homedirectory=unixHomeDirectory > NS_LDAP_ATTRIBUTEMAP= passwd:loginshell=loginShell > NS_LDAP_ATTRIBUTEMAP= shadow:shadowflag=shadowFlag > NS_LDAP_ATTRIBUTEMAP= shadow:userpassword=userPassword > NS_LDAP_OBJECTCLASSMAP= group:posixGroup=group > NS_LDAP_OBJECTCLASSMAP= passwd:posixAccount=user > NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=user > > So from the mapping, Solaris is using memberUid? But I think I only see > memberUid field (when using ADSI Edit) in group entry, not in user entry > (see my first comment) > > For a RHEL5.8 using krb5/ldap to integrated with AD, the ldap.conf contains: > pam_filter objectClass=posixAccount > nss_base_passwd cn=Users,dc=gtisoft,dc=com?sub > nss_base_shadow cn=Users,dc=gtisoft,dc=com?sub > nss_base_group cn=Users,dc=gtisoft,dc=com?sub > nss_map_objectclass posixAccount user > nss_map_objectclass shadowAccount user > nss_map_objectclass posixGroup group > nss_map_attribute gecos cn > nss_map_attribute homeDirectory unixHomeDirectory > nss_map_attribute uniqueMember member > tls_cacertdir /etc/openldap/cacerts > pam_password crypt > > I do not see it depends on memberOf LDAP field or gives me any hint how it > retrieves groups info, and yet both Solaris10/RHEL5.8 all return correct > information! > > So maybe the krb5/ldap are getting group membership info from somewhere > else, instead of depending on explicitly a particular LDAP schema? > > Can sssd does the same (without forcing user to add ldap_schema entry)? With your current configuration, SSSD uses following equivalent of ldap search to find a group membership of use jonz ldapsearch -h wolfgang -D cn=ldapadmin,cn=Users,dc=gtisoft,dc=com -W -b dc=gtisoft,dc=com "(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)( !(gidNumber=0))))". Could you provide output of this command? I can see in log file that it does not return anything. It is very likely there are some missing attributes which sssd expects. It seems to be a configuration issue and not a bug in sssd. Are you sure the command would work? This is what I got: [root@strauss events-admin]# ldapsearch -h penelope -D "GTISOFT\ldapadmin" cn=ldapadmin,cn=Users,dc=gtisoft,dc=com -W -b dc=gtisoft,dc=com "(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(^C [root@strauss events-admin]# ldapsearch -h penelope -D "GTISOFT\ldapadmin" cn=ldapadmin,cn=Users,dc=gtisoft,dc=com -W -b dc=gtisoft,dc=com "(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0))))" -bash: !: event not found If I removed the last (!(gidNumber=0)), the ldapsearch output is: [root@strauss events-admin]# ldapsearch -h penelope -D "GTISOFT\ldapadmin" cn=ldapadmin,cn=Users,dc=gtisoft,dc=com -W -b dc=gtisoft,dc=com "(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*))" Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=gtisoft,dc=com> with scope subtree # filter: cn=ldapadmin,cn=Users,dc=gtisoft,dc=com # requesting: (&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)) # # search reference ref: ldap://ForestDnsZones.gtisoft.com/DC=ForestDnsZones,DC=gtisoft,DC=com # search reference ref: ldap://DomainDnsZones.gtisoft.com/DC=DomainDnsZones,DC=gtisoft,DC=com # search reference ref: ldap://gtisoft.com/CN=Configuration,DC=gtisoft,DC=com # search result search: 2 result: 0 Success # numResponses: 4 # numReferences: 3 (In reply to Allen Zhao from comment #21) > Are you sure the command would work? > > This is what I got: > > [root@strauss events-admin]# ldapsearch -h penelope -D "GTISOFT\ldapadmin" > cn=ldapadmin,cn=Users,dc=gtisoft,dc=com -W -b dc=gtisoft,dc=com > "(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(^C > [root@strauss events-admin]# ldapsearch -h penelope -D "GTISOFT\ldapadmin" > cn=ldapadmin,cn=Users,dc=gtisoft,dc=com -W -b dc=gtisoft,dc=com > "(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(! > (gidNumber=0))))" > -bash: !: event not found > > > If I removed the last (!(gidNumber=0)), the ldapsearch output is: > [root@strauss events-admin]# ldapsearch -h penelope -D "GTISOFT\ldapadmin" > cn=ldapadmin,cn=Users,dc=gtisoft,dc=com -W -b dc=gtisoft,dc=com > "(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*))" You used less strict filter then sssd. Yhe only difference is that in our filter we would ignore LDAP entries which have attribute gidNumber equal to 0 (root) > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base <dc=gtisoft,dc=com> with scope subtree > # filter: cn=ldapadmin,cn=Users,dc=gtisoft,dc=com > # requesting: > (&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)) > # > > # search reference > ref: ldap://ForestDnsZones.gtisoft.com/DC=ForestDnsZones,DC=gtisoft,DC=com > > # search reference > ref: ldap://DomainDnsZones.gtisoft.com/DC=DomainDnsZones,DC=gtisoft,DC=com > > # search reference > ref: ldap://gtisoft.com/CN=Configuration,DC=gtisoft,DC=com > > # search result > search: 2 > result: 0 Success > > # numResponses: 4 > # numReferences: 3 As you can see ldap search does not return any entries. It just return referrals to other LDAP servers. That's exactly what can I see in sssd log file. SSSD tried to resolve them but it did not any result. So it *IS NOT BUG* in SSSD. You got he same result with ldapsearch Are you sure that LDAP entry for the group "Marketing" contains all following attributes? memberuid=jonz objectClass=group sAMAccountName=* gidNumber=* If you do want to use rfc2307 schema then you should properly configure option ldap_group_* ldap_user_*. You can find details in the maaul page sssd-ldap. Please be aware of fact that you don't use the same software as on Solaris10/RHEL5.8. Therefore you need to use different configuration. In my opinion the easiest way would be to configure sssd with rfc2307bis schema. (In reply to Lukas Slebodnik from comment #22) > If you do want to use rfc2307 schema then you should properly configure > option > ldap_group_* ldap_user_*. You can find details in the maaul page sssd-ldap. > > Please be aware of fact that you don't use the same software as on > Solaris10/RHEL5.8. Therefore you need to use different configuration. > > In my opinion the easiest way would be to configure sssd with rfc2307bis > schema. That's my opinion also. We can help with configuration if you show us an example user and some of his groups, but so far I see no bug, I simply think the schema and/or the attributes are misconfigured. (In reply to Jakub Hrozek from comment #23) > That's my opinion also. We can help with configuration if you show us an > example user and some of his groups, but so far I see no bug, I simply think > the schema and/or the attributes are misconfigured. This is the Win Server 2008 R2 AD schema, as I have described in details in the comment #1 and #2. I am not sure if I can or want to do any such LDAP schema tweaking there. Hi, Lukas, "Are you sure that LDAP entry for the group "Marketing" contains all following attributes? memberuid=jonz objectClass=group sAMAccountName=* gidNumber=*" I just checked the setting (using ADSI Edit): memberUid=jonz (the actually entry: jonz;aaa;bbb;ccc;etc) objectClass=top;group sAMAccountName=Marketing gidNumber=312 I would not agree with the assessment of mis-configuration. Windows AD is such a commercial beast, I would really hate to touch its schema, or blame on it. It is the way it is. I believe the current schema setting goes all the way to Windows 2000 Server era when someone configured the AD initially. The jonz vs JonZ issue probably is left from then, because Windows is case insensitive. (In reply to Allen Zhao from comment #25) > Hi, Lukas, > > "Are you sure that LDAP entry for the group "Marketing" contains all > following attributes? > memberuid=jonz > objectClass=group > sAMAccountName=* > gidNumber=*" > > I just checked the setting (using ADSI Edit): > memberUid=jonz (the actually entry: jonz;aaa;bbb;ccc;etc) > objectClass=top;group > sAMAccountName=Marketing > gidNumber=312 I would prefer to see an output from ldapsearch. Because it is interesting you can see attributes in ADSI Edit and previous ldap search did no return results. If we can see that the utility ldapsearch returned correct result then we can find problem in sssd. It might sound like repeating request, but I would like to see output of few ldapsearch commands ldapsearch -D "GTISOFT\ldapadmin" cn=ldapadmin,cn=Users,dc=gtisoft,dc=com \ -H ldap://server1.gtisoft.com \ -W -b dc=gtisoft,dc=com \ "(&(memberuid=jonz)(objectClass=group)(sAMAccountName=*)(gidNumber=*))" Please try to run twice and change the ldap url to ldap://server2.gtisoft.com (It is a value of ldap uris used by sssd) ldap_uri = ldap://server1.gtisoft.com,ldap://server2.gtisoft.com and I would like to see also the whole LDAP eentry for Marketing group. ldapsearch -D "GTISOFT\ldapadmin" cn=ldapadmin,cn=Users,dc=gtisoft,dc=com \ -H ldap://server1.gtisoft.com \ -W -b CN=Marketing,CN=Users,DC=gtisoft,DC=com Please try to run ldapsearch with both ldap URIs. If the result is the same. You can attach just one. We can mark attchment as private if you cannot do it yourself. I hope it will help us to find problem. It is really suspicious we cannot see any result from server in sssd log files and you can see it in ADSI Edit. > > I would not agree with the assessment of mis-configuration. > > Windows AD is such a commercial beast, I would really hate to touch its > schema, or blame on it. It is the way it is. I would like to appologise for misunderstanding. I did not suggest to change anything on server side. My intention was to configure sssd to try to use different ldap schema. > The jonz vs JonZ issue probably is left from then, because Windows is case > insensitive. Agree. and ldapsearch is case insensitive so it should not do any problems. Thank you very much for reply and patience. Closing for inactivity. We suspect this is not an sssd bug but a schema issue. Whatever, I feel like the team just want to brush thing aside, though every week, I still receive an email to remind me to provide something more to get this bug going. This is the thing: if I tell I am using AD, it probably means that we can not do much about its schema. Any bug in such nature, I will say that is a sssd bug, not AD's, because pointing to AD would not help to resolve the issue. If the team wants to close the bug, fine. It just adds to my negative observation to this whole sssd thing, and its usability. Also, please stop spamming me on this bug or further info-requested email. I am just so amazed that no one in the team actually setup an AD and test this bug in a lab environment first (after I have described it in such a detail), before trying to brush the whole thing aside. I feel it is pointless to continue to provide anything after going through this bug a while back. Because this is an issue to do with Active Directory, I am pretty sure that if I do not cry for its fix, someone else would sometime down the road. Wrong attitude, folks! But whatever the decision is, please spare me another run of info-requested email if you have closed the bug. |