There are a few things that we need to do within sssd to handle case-sensitive names, and we probably also need to have an "force lower case names" option.

About sssd:
There are 3 things to keep in mind when dealing with user/group names.

1) At the moments we use an attribute called "name" to store the user's name.
This attribute is marked CASE-INSENSTIVE in the sysdb schema (see sysdb_private.h).
So we need code that is able to change the @ATTRIBITES attribute in the ldb file if we switch between case sensitive/case insensitive names and reindexes the db.
Alternatively we can also just clear the cache if the option changes (hopefully people will not change it while offline :)

2) When reading from the remote server we need to decide how to deal with the incoming data.
a) we trust the server, so we accept that data as is whatever the capitalization of the names and trust the server to be consistent internally (for example user names in the memberUid attribute of groups are case-correct wrt the user's object attribute holding the user name).
b) We do not trust the server to have consistent capitalization for names.
In this case the only way to have something sane is to use "force lower case names". We always lower case all names before storing them. We need to have a way to make sure we handle the case where the server have 2 users/groups with the same name differing only for the name. We probably need to store the original user name attribute, and do extra checks if, for some reason the data we get back from the server does not match.

3) When serving user requests we need to deal with case mismatches.
If we change the ldb attribute to turn "name" into a case sensitive attribute, then this is easy as queries will simply fail if the case does not match. Although we may need to have additional interfaces in future if we want to allow some non-posix interface to be able to not care about case.
If we don't change the ldb attribute to case sensitive then we may have to check that the requested user/group name case matches what we found. Or also immediately return with error if the requested name has a capital letter and the "force lower case names" is set.

Changing the ldb attribute "name" to be case-sensitive, and setting "force lower case name" to be on by default is probably the best default configuration from a posix-compliance point of view.

milestone: SSSD Deferred => SSSD 1.0
owner: simo => sgallagh

Fields changed

status: new => assigned

Moving this to 1.0.0rc, as it is a functionality change that should be complete before feature-complete state.

milestone: SSSD 1.0 => SSSD 1.0 RC

I've been wracking my brain for two days now trying to figure out what you think we're doing wrong here right now. Let me try to put my thoughts in order.

Premise:
Most LDAP servers are case-insensitive. This means that they may not be internally consistent, because user sgallagh might potentially be listed elsewhere as memberuid=Sgallagh (for example).
POSIX users should be case-sensitive (meaning that it should be possible to have distinct users "sgallagh" and "Sgallagh" on a system)
Currently, the SSSD enforces a case-insensitive system where name fields (used for both users and group names) are treated as case-insensitive.

So in essence, what SSSD is doing is behaving in a way identical to the majority of LDAP servers out there, and just adding an additional restriction on POSIX.

Thus, I can only see one possible configuration that would be considered potentially harmful in our current situation:
Some user has an LDAP server that is configured to use case-sensitive users or groups AND is not internally consistent (either they've actually got two users with names differing only by case or they're inconsistent with their group memberships). I'm inclined to consider this to be a deployment bug, rather than a situation to address in the SSSD. I think the proper response to a support issue of this type would be "Fix your entries to be consistent."

I'd like someone to explain to me why we should perform complicated comparisons on the SSSD side, rather than have them fix their deployment.

I think the problem is reverse. Per recent discussion about MPG the posixName attribute that will be used by IPA to store the real names for user and groups will be case sensitive for the first time fixing the broken LDAP schemas that for quite a while ignored the fact that the user and group names must be case sensitive. This makes the situation of SSSD even worse. It should in some way be capable of working with back ends that do it right in the case sensitive way and do it wrong in the case insensitive way. May be SSSD should query the back end for some attribute in the rootDSE that indicates if the source is case sensitive or not. By default it would assume it is case insensitive. Only IPA will have it attribute (yet another value of IPA) so far and will do it right. For the sources that do it wrong I think SSSD should have a configurable mode : trust the source is correct vs. convert everything to one case.

Dmitri, while it would be possible to make IPA behave this way, we need to solve the general case.

Simo and I had a long discussion this morning on IRC, where we came up with the following main points:

1. We need to make the 'name' attribute case-sensitive in the sysdb/cache
2. We need to offer a force_lowercase_names option for deployments that do not have consistent capitalization.
3. We need to check all of the comparisons in the code to ensure that they are correctly case-aware.

Yes. This is what I was talking about. I agree 100%.

I was just suggesting that may be (in addition to what you said) it makes sense to query the actual back end to see if it has case sensitive schema or not and have the "force" configuration option only for the providers that do not support case sensitive schema. But I guess it is a very minor optimisation.
Other than that we are on the same page.

Fields changed

tests: 0 => 1

Fixed in e5d8e5e

We've decided to make the cache case-sensitive but not support the force_lowercase_names feature in 1.0. It will require more thought.

fixedin: => 1.0.0rc

Fields changed

resolution: => fixed
status: assigned => closed

Fields changed

tests: 1 => 0
testsupdated: 0 => 1

Fields changed

rhbz: => 0

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1288

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.