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.