Re: [ldapext] Case sensitivity summary

[Simo Sorce <[e-mail]>]

On Fri, 2015-12-04 at 15:00 +0100, Michael Ströder wrote:
> Andrew Findlay wrote:
> > We are not going to define a standard that forces everyone to do everything
> > 'right' while providing interworking of differing systems. It is simply
> > not possible.
> 
> That perfectly summarizes this topic.
> Thanks Andrew, for this clear statement.
> 
> Let's keep the scope right.
> 
> > Overall I think we are heading for something like this:
> > 
> > 1)	Usernames and groupnames should have caseIgnoreMatch syntax
> > 
> > 2)	Usernames and groupnames should preferably be stored in lower-case in
> > 	cultures where that has meaning. Remember that LDAP is case-preserving
> > 	even for case-insensitive attributes.
> > 
> > 3)	Systems that are internally case-sensitive should take extra care
> > 	when using data from LDAP.
> > 
> > I know this conflicts with Mark's wish to be able to import existing
> > NIS data unchanged to cope with weird existing situations, but I see that 
> > as a special case that may be better handled in another way.
> 
> +1 !!!
> 
> (That's pretty much exactly what I planned to suggest.)
> 
> > Note that the above discussion *only* applies to usernames and groupnames.
> > Unix-specific mappings such as automount maps are a different issue.
> 
> automount maps are maybe a similar topic like generating 'homeDirectory' values
> for $HOME on case-sensitive file-systems based on user names.  For this
> RECOMMENDing that usernames are normalized to lower-case is really helpful.

This is exactly what we did in FreeIPA too, we automatically convert the
user name entered in lower case. We have no issues with "uncertain
rules" about casefolding because we restricted the valid charset to
Unicode and within unicode casfolding *to* lower case is not ambiguous
and part of the standard.
I think we further limit the interface to "Western charset" (read
printable ASCII chars), but that is a restriction we can and will relax
at some point.

> Regarding service names:
> 
> (Personally I never saw any customer LDAP deployment storing a services map.)
> 
> 1. Service names are used in DNS RRs (SRV, DANE, etc.) and those DNS labels are
> definitely supposed to be treated case-insensitive.

There are odd things in the wild, so you need to be at least
case-preserving, both for user names and services.

> 2. Jordan pointed out RFC 6335.
> 
> => I concur with Jordan: Service names MUST be treated case-insensitive.
> Probably recommending in an implementation note to normalize values to
> lower-case seems also to be a good idea.
> 
> => People actually using case-sensitive service names to address *different*
> services MUST clean up their local mess. But they likely have to do that anyway.

ACK, maintaining broken systems may seem the only way for some
organizations due to the daunting task and inter-dependencies that makes
a clean up really hard. I have personally witnessed herculean efforts to
migrate several hundreds diverged NIS domains into a single directory,
and it ain't pretty. Especially if you have terabytes of data and
numerous files with permissions to deal with. But the problem has always
mostly been on uidNumber and gidNumber consolidation, usually
name-mismatches have been mush easier to deal with because it is easy to
remap usernames locally.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York