Subject: Re: [ldapext] DBIS commentary

From: "Bannister, Mark" <[email-masked]>
Date: Tue, 1 Dec 2015 10:13:28 +0000

Hi Jordan,

> On the case-sensitivity front:  we have a pretty fundamental disagreement.  I believe that UNIX names

> must eventually become case-insensitive, that it is only a matter of time until they do.

Yes, you're right, this is a pretty fundamental disagreement.  As I don't see anyone else entering the

debate supporting case sensitivity, I fear this will fail on a standards track.  I may just keep the

software available as an alternative, and those who want it can use it, but I think any hopes I had

that DBIS might one day be a standard have just been dashed.  I will continue to answer some

of your points anyway, just for completion.  Those who agree with me are either a) not speaking

up or b) not reading this mailing list.

However, I would point out that you will meet resistance (and/or disgruntled customers after the

fact) if you attempt to change UNIX to be case-insensitive.  Btw, what was your plan for case

sensitivity in filesystems?

> UNIX is not the whole world, and the entire rest of the world is clear that MARK, Mark, and mark

> are the same person.

With people, perhaps.  With people vs. service accounts perhaps not.  Perhaps I have a user with

a login name of 'sheila' but I also have a service account called 'SHEILA'.  I suppose next you will

be proposing to redefine the English language by saying that case is unimportant when starting

sentences, or when writing proper nouns vs nouns?  Be careful when you say "the entire rest

of the world", be sure you really know the entire rest of the world.  I don't claim to, but I do have

real examples of problems that DBIS is solving today.

> > If you have an issue with authPassword being in RFC2307bis, now is the

> > time to raise it, as it is on the new LDAPEXT charter and the WG are

> > planning to finalise RFC2307bis in the next 12 months and give it its own RFC number.

> I recommend looking pretty hard at whether a new attribute is needed, given that there

> seem to be three other existing attributes.

> In general, it seems best to discourage making password hashes visible - perhaps even to

> the point of not standardizing them.

You might want to point that out in a separate thread, as I say, RFC2307bis is on the new

LDAPEXT charter but those running with the new charter may not be reading these email

chains in any depth.

> My key point here is that DBIS should specify what attribute should replace it, what attribute

> clients are expected to use to populate the pw_gecos field in struct passwd.

draft-bannister-dbis-passwd provides a suggestion already in 2.1.3.1:

   The posixUserAccount object class is auxiliary and must always be

   associated with another structural class.  One such class is

   inetOrgPerson [RFC2798].  If user accounts were given the

   inetOrgPerson class, then displayName might be an appropriate value

   for the dbisMapGecos attribute.

Given that the gecos field can encode anything in any format, I didn't think I could realistically

do any better than provide a suggestion.

> >> posixGroup / posixGroupAccount

> >> X.521 groupOfNames seems like a more appropriate basis for the definition of a group.

> > But that doesn't allow for GID number.

> A subclass does.

I have people telling me groupOfNames doesn't work well for them because it can be a group

of anything.  Extra LDAP searches are required to figure out what type of object the members

are.  That leads to a rather inefficient system.

> >> nisNetgroup / netgroupObject

> >> Although not a perfect match, groupOfNames seems like it might be a

> >> better basis for grouping computers.

> > netgroups are a specific construct, trying to squeeze them into

> > something else that is not a perfect match would be a suboptimal

> > decision.  LDAP can represent netgroup data better, so let's represent it better.

> Yes, it can... and for most purposes it has, in the form of groupOfNames.  If you have users

> represented in the directory, the natural way to group them is with groupOfNames.  If you

> have hosts represented in the directory, the natural way to group them is with groupOfNames.

> The only thing that there isn't an obvious way to group is "user X on host Y".  Not that I've seen

> a lot of concrete instances of netgroups, but I don't think I've seen one of those yet.

See previous reservations regarding groupOfNames.  Imagine trying to construct a search

operation to find just host members, or just user members.

However, I seem to be a lone voice again in favour of netgroups.  I've seen them used an awful

lot and with a bit of improvement, they'll be a lot more manageable.  I know how painful it will

be for folk to try to move away from them, so in the spirit of making things easy for people

I have been proposing incremental improvements rather than just dumping them and

doing something completely different.  Everyone else commenting on this list seems to hate

them.  Another fundamental difference we have ...

> Having two names that differ only in case lead to different port numbers seems like a

> spectacularly bad idea.  If there's an organization that has somehow found themselves

> in such a mess then I'm very sorry for them

<rant>

Wait.  NIS permitted this.  If folk have done what NIS allowed them to do, and it

fitted their working practice, then you can't blame them for that.  If you don't like it

and want to label it "a mess", that's fine you can do that, but I do not want to leave

people behind.  If you wish to call it a mess, then Sun Microsystems created the mess,

but it's infrastructure and we're stuck with it.  Imagine if the electronics industry in America

started selling devices with only English three-pin plugs<https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiQzfjRs7rJAhUCKiYKHY6eCZoQFggiMAE&url=http%3A%2F%2Fwww.fastcodesign.com%2F3032807%2Fwhy-england-has-the-best-wall-sockets-on-earth&usg=AFQjCNEP4sremkvI56BoTb7D7rJhFaRbgg>, citing that the original was a

“bad design” and anyone who has found themselves in such a mess as to have

incompatible wall sockets, well very sorry for them but that’s just tough luck.

Right.  You’d cause an outcry.  Same thing applies here.  With NIS a particular

working practice was absolutely fine.  Now it isn’t.  And people are left to fix it

themselves.  I think that’s very bad.  (And for those who say “NIS is dead”, that’s

absolutely not true, there are large organisations still using NIS and who haven’t

yet migrated to LDAP, perhaps because the migration to LDAP is too hard for

them in the present climate).

</rant>

Best regards,

Mark.

________________________________

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

---

From: Ludovic Poitou <[email-masked]>
Date: Tue, 1 Dec 2015 03:51:03 -0800

Just a quick note: there is no new LDAPEXT charter, but a Proposal to reform LDAPEXT and a draft charter being discussed.

Regards,

Ludovic.

From: Bannister, Mark <[email-masked]>
Reply: Bannister, Mark <[email-masked]>
Date: 1 December 2015 at 02:13:39
To: Jordan Brown <[email-masked]>
CC: [email-masked] <[email-masked]>
Subject:  Re: [ldapext] DBIS commentary  

-- 
Ludovic Poitou
http://ludopoitou.com

---

From: Jordan Brown <[email-masked]>
Date: Tue, 1 Dec 2015 09:52:56 -0800

> up or b) not reading this mailing list.

Do note again that RFC 4876 mapping would let you redirect the clients to use a 
custom case-sensitive attribute, or attributes from different auxiliary classes.

> fact) if you attempt to change UNIX to be case-insensitive.
>

For the particular case of user names, I'll note that you're the first person I've 
talked to who isn't working directly on Solaris LDAP development who has even 
noticed that LDAP user names are case-insensitive, much less complained.

> Btw, what was your plan for casesensitivity in filesystems?
>

Baby steps :-)

I do think that that's inevitable too, just not as soon as user names.  User names 
have more cross-platform impact, a more direct association to human names, and get 
typed by hand more often in many environments.

Any environment that interoperates with Windows will end up with case-insensitive 
file names, at least in data file systems. Case-insensitivity is already an option 
on ZFS, and a "mixed" mode is the default on our storage appliances.

> real examples of problems that DBIS is solving today.

I'd suggest that having a login name that duplicates a service account name, 
except for case, is asking for trouble.  Even in a relative bastion of UNIX like 
Oracle, we noticed that some of the corporate UIs present user names as all upper 
case.  Case sensitivity is really quite unnatural for humans.  There's no shortage 
of commercial systems that change the case of the left side of e-mail addresses, 
which will really mess you up if you're using the natural username@domain 
construction and your usernames are case-sensitive.  They're wrong, but they're 
common.  (And, importantly, almost nobody *notices* that they are wrong.)

I doubt we'd want to go too far off into the weeds on English semantics, but I'd 
argue that case *is* unimportant when starting sentences.  It helps to mark the 
beginning of the sentence, but does not otherwise affect the meaning of the word.  
When I say "Cars drive on roads" or "The cars are on the road", "Cars" and "cars" 
mean the same thing.  For proper nouns you have a point - Oracle and an oracle are 
two different things.  (Though even there, note the proper noun does not take an 
article.)  However, user names are always proper nouns.  Come to think of it, 
there's something interesting there.  "Mark" and "Bannister" are both proper 
nouns, yet "mark" and "bannister" are common nouns.  The only reason that we 
tolerate using "mark" and "bannister" as user names is that we internally convert 
them into their capitalized forms; treating them as common nouns as standard 
English would have us do wouldn't make any sense.

> do any better than provide a suggestion.

I think you could safely specify displayName as a MAY attribute, and let people 
use RFC 4876 mapping if for some reason they want to use something else.

Having two attribute-mapping mechanisms - RFC 4876 mapping and dbisMapGecos - 
seems bothersome.

> are.  That leads to a rather inefficient system.

There are two problems there:

1)  A group could contain anything, even when you want it to only contain one 
type.  Administrator error could lead to incorrect configurations.  In 
programming-ese, it's not type-safe.  One might hope that you could set up 
metadata limiting the types of objects that could be added to a group, like you 
can set up limits on the types of objects that can be put in a container, but I 
don't know if you can.  One hopes that your administration UIs will help here - if 
you're defining a group of users, the administration UI presumably knows that and 
only lets you add users.  At the same time, this flexibility enables nested 
groups, which can be very useful.
2)  You have to do "extra" searches to get any real information on the member.  
Yes, that's a very big problem.  The particular pain point is that getgrnam and 
getgrgid are defined to return a list of the members of the group, necessitating a 
search for *each* member. That gets pretty painful when a group has thousands of 
members.  I think the truly right answer there is to add new APIs that don't 
retrieve the members, and even to redefine the existing APIs to not retrieve the 
members, because there are almost no cases where it actually makes sense to 
retrieve the list of members of a UNIX group.  The standards provide some help in 
that there are hints in the UNIX standard that the list of members returned may 
not be complete.  Also:  Caching is your friend. Note also that the PADL version 
of nss_ldap has a "nss_getgrent_skipmembers" option that disables returning the 
list of members.

As long as we're talking about flaws in groupOfNames:  there's also the problem 
that "member" is a MUST attribute, and that makes empty groups problematic.  
Active Directory uses the same basic structure, but uses the "group" class instead 
of groupOfNames, and for "group" the "member" attribute is a MAY.  RFC2307bis-02 
replaces groupOfNames with groupOfMembers, again with "member" as a MAY.

(One might have hoped that you could have an attribute with a empty list of 
values, but X.501 does not allow that.)

> operation to find just host members, or just user members.

Do note that the queries that you normally need are "is this host (or user) a 
member of this group" and "what groups is this user a member of".  It's hard to 
find cases where you really want to ask "what are the members of this group".  The 
"is this X a member" and "what groups is this X a member of" queries aren't bad at 
all with groupOfNames - you have to do a lookup on X to get its DN, but then you 
just do a natural (and efficient) search.

> started selling devices with only English three-pin plugs 
> <https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiQzfjRs7rJAhUCKiYKHY6eCZoQFggiMAE&url=http%3A%2F%2Fwww.fastcodesign.com%2F3032807%2Fwhy-england-has-the-best-wall-sockets-on-earth&usg=AFQjCNEP4sremkvI56BoTb7D7rJhFaRbgg>, 
> citing that the original was a
>

Well, kind of.  Yes, you were allowed to do it.  That doesn't necessarily mean 
that it was ever a good idea.

The structure of extension cords and power strips lets you daisy-chain them 
together to any length.  That doesn't mean that it's a good idea to do it, or that 
the fire marshal won't cite you on your next office inspection.

Also, remember that IANA, not NIS, is the authority on the definition of service 
names, and it defines them as case-insensitive.  There's a very good argument that 
NIS treating them in a case-sensitive way is a bug.

---

From: Charlie <[email-masked]>
Date: Tue, 1 Dec 2015 17:06:41 -0500

A directory backend that is intended to serve multiple existing
operating systems probably shouldn't be telling any of those operating
systems whether or not they should be case-sensitive.  It's out of
scope for the project and causes arguments.

That being said, options are great to have.  If you can support
existing systems while also giving people the ability to do whatever
you happen to think is better, you'll automatically win any such
arguments.

--Charlie

---

From: Jordan Brown <[email-masked]>
Date: Tue, 1 Dec 2015 14:49:22 -0800

[ Splitting off a specific subthread as Michael requested ]
[ Resend with correct distribution ]

> scope for the project and causes arguments.

Well, but... if the various OSes are sharing the same naming attribute, it seems 
like there's an unbreakable chain of connections between them.  Either the 
attribute is case-sensitive, in which case the natively-case-insensitive OS will 
be confused, or the attribute is case-insensitive, in which case the 
natively-case-sensitive OS will be confused.

The way that I look at it is not that the directory is serving the OSes, but that 
the directory is defining a world that the OSes are choosing to play in... and 
when they choose to play in the directory's world, they have to live by its rules.

> you happen to think is better, you'll automatically win any such

It's tempting to suggest that a single entry could have one name attribute that's 
case-sensitive and another that's case-insensitive (presumably from different 
auxiliary classes), and technically that'd be possible, but seems like an 
administrative nightmare... a very high cost to pay for the 0.1% of names where 
case-sensitivity is important.

---

From: Jordan Brown <[email-masked]>
Date: Tue, 1 Dec 2015 14:50:18 -0800

[ I just can't win for losing today.  Let's try this *one more time* with the 
right subject. ]
[ Splitting off a specific subthread as Michael requested ]
[ Resend with correct distribution ]

---

From: Simo Sorce <[email-masked]>
Date: Tue, 01 Dec 2015 20:06:09 -0500

On Tue, 2015-12-01 at 10:13 +0000, Bannister, Mark wrote:
> <rant>
> 
> Wait.  NIS permitted this.  If folk have done what NIS allowed them to
> do, and it fitted their working practice, then you can't blame them
> for that.  If you don't like it and want to label it "a mess", that's
> fine you can do that, but I do not want to leave people behind.  If
> you wish to call it a mess, then Sun Microsystems created the mess,
> but it's infrastructure and we're stuck with it.

Bugs happen, even in specifications.

> Imagine if the electronics industry in America
> 
> started selling devices with only English three-pin
> plugs<https://www.google.co.uk/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0ahUKEwiQzfjRs7rJAhUCKiYKHY6eCZoQFggiMAE&url=http%3A%2F%2Fwww.fastcodesign.com%2F3032807%2Fwhy-england-has-the-best-wall-sockets-on-earth&usg=AFQjCNEP4sremkvI56BoTb7D7rJhFaRbgg>, citing that the original was a “bad design” and anyone who has found themselves in such a mess as to have incompatible wall sockets, well very sorry for them but that’s just tough luck.

Funny you bring up this example, because these kind of changes happened
quite a few times in history, just on power plugs:
https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#Obsolete_types

I've used converters from one type to another for many years in Italy
given there we are still supposedly at the end of a multi-decades long
transition from this:
https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#Italy_.28Type_L.29
to this:
https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#CEE_7.2F17_unearthed_plug
or this:
https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#CEE_7.2F3_and_CEE_7.2F4_.28German_.22Schuko.22.3B_Type_F.29
by way of this:
https://en.wikipedia.org/wiki/AC_power_plugs_and_sockets#CEE_7.2F16_.22Europlug.22_.28Type_C.29

> Right.  You’d cause an outcry.

If enough people thought it was the end of the world, yeah, but it
didn't happen, and in most cases it isn't happening in the Unix/Linux
world. Most people are just happy to use case-preserving names (ie
case-insensitive names were the name is preserved in the form entered in
most cases).

>   Same thing applies here.  With NIS a particular working practice was
> absolutely fine.  Now it isn’t.  And people are left to fix it
> themselves.  I think that’s very bad.  (And for those who say “NIS is
> dead”, that’s absolutely not true, there are large organisations still
> using NIS and who haven’t yet migrated to LDAP, perhaps because the
> migration to LDAP is too hard for them in the present climate).

There is always some holdout with every technology, that's not a reason
to stop the evolution of standards in the direction everyone else is
going.

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

---

From: Simo Sorce <[email-masked]>
Date: Tue, 01 Dec 2015 20:21:48 -0500

On Tue, 2015-12-01 at 09:52 -0800, Jordan Brown wrote:
> > I have people telling me groupOfNames doesn't work well for them
> > because it can be a group of anything.
> > Extra LDAP searches are required to figure out what type of object 
> > the members are.  That leads to a rather inefficient system.
> >
> 
> 1)  A group could contain anything, even when you want it to only
> contain one type.  Administrator error could lead to incorrect
> configurations.  In programming-ese, it's not type-safe.  One might
> hope that you could set up metadata limiting the types of objects that
> could be added to a group, like you can set up limits on the types of
> objects that can be put in a container, but I don't know if you can.
> One hopes that your administration UIs will help here - if you're
> defining a group of users, the administration UI presumably knows that
> and only lets you add users.  At the same time, this flexibility
> enables nested groups, which can be very useful.

This is very true and there are products that can cope, there are also
mechanism to more efficiently (at least latency wise) if you use
controls like: https://tools.ietf.org/html/draft-masarati-ldap-deref-00

Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use
it in various clients.

> 2)  You have to do "extra" searches to get any real information on the

The control above helps quite a bit in cases where you really need to
search.

>  Yes, that's a very big problem.  The particular pain point is that
> getgrnam and getgrgid are defined to return a list of the members of
> the group, necessitating a search for *each* member. That gets pretty
> painful when a group has thousands of members.

It is fully broken indeed, based on age old databases that were very
small and always local to the system.

>  I think the truly right answer there is to add new APIs that don't
> retrieve the members, and even to redefine the existing APIs to not
> retrieve the members, because there are almost no cases where it
> actually makes sense to retrieve the list of members of a UNIX group. 

It would be nice to have a new API, although Posix has some wiggle room
which we fully exploit in clients like Windbind and SSSD.

Both clients simply do not return all members in the enumeration cases
(getgrent) but only in the explicit group retrieve case (getgrnam).
This is because Posix allows to omit results in the enumeration case
according to some interpretations. 

>  The standards provide some help in that there are hints in the UNIX
> standard that the list of members returned may not be complete. 

Indeed, some admins complain about this so switches are provided in the
above mentioned clients to behave "the classic way". And surprisingly
very few systems really have a big issue with this. Given that any
application that depends on full group enumeration is already fully
broken and a  performance liability on any enterprise system that has
accounts in the thousands.

>  Also:  Caching is your friend. Note also that the PADL version of
> nss_ldap has a "nss_getgrent_skipmembers" option that disables
> returning the list of members.

Any client that doesn't do caching today is really a bad idea.

> As long as we're talking about flaws in groupOfNames:  there's also
> the problem that "member" is a MUST attribute, and that makes empty
> groups problematic.

This was, in fact, such a big problem that in the FreeIPA product we
decided to break with the standard and changed member to be MAY, never
looked back on this choice.

> Active Directory uses the same basic structure, but uses the "group"
> class instead of groupOfNames, and for "group" the "member" attribute
> is a MAY.  RFC2307bis-02 replaces groupOfNames with groupOfMembers,
> again with "member" as a MAY.
> 
> (One might have hoped that you could have an attribute with a empty
> list of values, but X.501 does not allow that.)
> 
> > See previous reservations regarding groupOfNames.  Imagine trying to
> construct a 
> > search
> Do note that the queries that you normally need are "is this host (or
> user) a member of this group" and "what groups is this user a member
> of".  It's hard to find cases where you really want to ask "what are
> the members of this group".  The "is this X a member" and "what groups
> is this X a member of" queries aren't bad at all with groupOfNames -
> you have to do a lookup on X to get its DN, but then you 

Yes this is generally the case for "system level" clients, but indeed
many poor administrative clients tend to do the former kind of query,
because they think it is a good idea to show all the members, they tend
to have some problems when the members reach the multiple tens of
thousands :-)

Simo.

P.S. I switched to use my "corporate" email address so there is no
confusion on what hat I may be wearing.

---

From: Jordan Brown <[email-masked]>
Date: Tue, 1 Dec 2015 18:21:55 -0800

[ Splitting off a subtopic as Michael requested. ]

On 12/1/2015 5:21 PM, Simo Sorce wrote:
>> contain one type. [...]

That control is indeed very interesting.  I don't immediately see how it helps 
with the type-safety problem, though.  Am I missing something?

> according to some interpretations.

Yes, and I infer that there's corresponding omissions in other parts of the 
standard.  In the getgrent description, the standard describes omitting this 
information on the basis of security restrictions. Omitting the data there would 
not help security at all if you could immediately turn around and request it 
through getgrname and getgrgid.  Meeting the security need would require having 
the restrictions in both places.

> Indeed, some admins complain about this so switches are provided in the above 
> mentioned clients to behave "the classic way". And surprisingly very few systems 
> really have a big issue with this. Given that any application that depends on 
> full group enumeration is already fully broken and a performance liability on 
> any enterprise system that has accounts in the thousands. 

Right.  The old "walk through all of the groups and then through all of their 
members" strategy is doubly wrong:  the number of groups can be very large, and 
the number of members of each group can be very large.

Heck, even with RFC2307 memberUid groups, simply retrieving the group list can 
easily involve moving half a megabyte of data. That's a lot of wasted processing 
when all you really wanted was a gid<->name lookup.

> looked back on this choice.

We could address it through introducing a new object class (and here I include 
just grabbing "group" from AD or "groupOfNames" from RFC2307bis-02, not just 
creating a wholly new one), or by changing the definition.  This is one of those 
cases where I'd say that breaking formal compatibility might well be appropriate.

---

From: "Bannister, Mark" <[email-masked]>
Date: Wed, 2 Dec 2015 08:59:29 +0000

Jordan Brown wrote:
> Do note again that RFC 4876 mapping would let you redirect the clients to use a custom
> case-sensitive attribute, or attributes from different auxiliary classes.

I should really have made it clear that DBIS supersedes RFC 4876, and introduces more
powerful mapping constructs.  With DBIS, you can support an RFC2307 schema (case
insensitive) and the DBIS schema (case sensitive) from the same client if you so choose,
and at several levels.  You could have groups of hosts with case sensitive maps vs. groups
of host with case insensitive maps.  You could have a host where some maps are case
sensitive and some are not.  You can even have parts of a map provided via one schema
and parts from another, i.e. case sensitivity for some entries and insensitivity for others
if that’s really what you wished to do.  If you use DBIS, you certainly have no need to
use RFC 4876.

Charlie wrote:
> That being said, options are great to have.  If you can support existing systems while
> also giving people the ability to do whatever you happen to think is better, you'll
> automatically win any such arguments.

I’m also a firm believer in providing options for working in different ways, rather than
trying to force everyone to fit a single paradigm.  To that end, perhaps we drop the
notion of DBIS “replacing” RFC2307/RFC2307bis and it just becomes another way to
do things.

Jordan Brown wrote:
> Mark Bannister wrote:
> > Btw, what was your plan for case sensitivity in filesystems?
>
> Baby steps :-)
>
> I do think that that's inevitable too, just not as soon as user names

Wow.  Good luck with that.  (Boiling oceans comes to mind).

Jordan Brown wrote:
> For the particular case of user names, I'll note that you're the first person I've talked
> to who isn't working directly on Solaris LDAP development who has even noticed that
> LDAP user names are case-insensitive, much less complained.

It wouldn’t have bothered me until I came across a very large organisation for
which this broke.  More suggestions in the other thread.

> Well, kind of.  Yes, you were allowed to do it.  That doesn't necessarily mean that it was ever a good idea.
>
> The structure of extension cords and power strips lets you daisy-chain them together to any length.  That
> doesn't mean that it's a good idea to do it, or that the fire marshal won't cite you on your next office inspection.

Yes but that is basic electrical safety which is communicated far and wide, we even teach this
to our children.  Plus there are office inspections that pick this up if you’re doing it wrong, so
it’s corrected.  I don’t think it’s a relevant rebuff.  NIS being case sensitive is more akin to
Californians being allowed to turn right on red (as long as they promise not to knock over a
pedestrian).  If you changed the rules of the road tomorrow, people will forget.  But the
rules of our road affect computer software, and software never forgets.  Worse, software
outlives hardware by a long way, it doesn’t fall off like dead wood (old servers being
decommissioned).  Someone has to rewrite it.

Mark.

---

From: "Bannister, Mark" <[email-masked]>
Date: Wed, 2 Dec 2015 09:19:22 +0000

> Well, but... if the various OSes are sharing the same naming attribute, it seems like

> there's an unbreakable chain of connections between them.  Either the attribute is

> case-sensitive, in which case the natively-case-insensitive OS will be confused, or

> the attribute is case-insensitive, in which case the natively-case-sensitive OS will be confused.

> The way that I look at it is not that the directory is serving the OSes, but that the

> directory is defining a world that the OSes are choosing to play in... and when they

> choose to play in the directory's world, they have to live by its rules.

Hang on.  In the old days, directories were giant yellow books that sat next to the

telephone.  There were no rules of engagement.  You want a telephone number,

you open the book and find it.  If the book was upside down, you didn't have to stand

on your head to read it, you could turn the book round.

I think it would be a mistake to try to make the world revolve around directories.

A directory is a server, the clue is in the name, it *serves* clients.  Different clients have

different needs.  It would be wrong to mandate big changes on the client-side just

to interoperate, but this is exactly what you are suggesting.  Remember not everyone

cares about having their UNIX and Windows entries co-exist anyway and never will.

> case-sensitive and another that's case-insensitive (presumably from different auxiliary

> classes), and technically that'd be possible, but seems like an administrative nightmare...

> a very high cost to pay for the 0.1% of names where case-sensitivity is important.

Ok here's an idea.  What if we could define case sensitive entries in a directory that

were only available to case sensitive clients.  All the case insensitive entries were available

to all.  Then, in 99% of cases where we don't care and UNIX/Windows share attributes

they can interoperate.  In the 1% of cases where we need UNIX-specific entries that

are case sensitive, we don't want the Windows hosts to see these entries because they

would get confused, we can define them too.

Then the DUA on a UNIX host can advertise itself as case sensitive when it binds to the DSA,

when it searches for a list of user names (or whatever data, just using user names as an example

here), it will see:

mark

jordan

michael

charlie

CHARLIE

(where CHARLIE is actually a service account that our customer wants specifically in uppercase

for whatever reason, we don't care about the reason here remember, we're just providing

options).

A Windows client does not advertise itself as case sensitive when it binds to the DSA, and when

it performs the same LDAP search it will see:

mark

jordan

michael

charlie

... and that's ok, because CHARLIE is a service account intended for running a UNIX app.

You can actually do this today using DBIS, by setting up two configuration map entries

for the passwd database, one using the RFC2307 schema (e.g. ou=rfc2307,o=infra) and one

using the DBIS schema (e.g. ou=dbis,o=infra).  A UNIX client will obtain passwd entries

from both locations, and the case sensitive users are configured under ou=dbis,o=infra.

Windows clients only know about ou=rfc2307,o=infra and therefore only get to see

the case insensitive entries.

Mark.

(p.s. sorry Charlie couldn't include you directly in this reply as our corporate security

policy prevents me from mailing a gmail account, but hopefully you'll get it via

the mailing list).

---

From: Jordan Brown <[email-masked]>
Date: Wed, 2 Dec 2015 08:39:14 -0800

> if that’s really what you wished to do.  If you use DBIS, you certainly have no 

Ah, indeed.  So if there were case-sensitive and case-insensitive attributes 
available (presumably in different auxiliary classes), you could use those mapping 
constructs to choose the non-default variation.

It doesn't look like you've got 4876 completely covered, though. Attribute mapping 
is only one of the things it does - it also tells the clients which servers to 
connect to and what authentication schemes to use.  If you're replacing 4876, 
there should be a plan for replacing that capability.

> Wow.  Good luck with that.  (Boiling oceans comes to mind).

I work in name services, not file systems, so it's not an active project.  I just 
think it'll happen eventually, that interoperability with Windows will force it.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 02 Dec 2015 12:21:01 -0500

> with the type-safety problem, though.  Am I missing something?

The idea is that you can get all data up at once including objectclass
and then you can simply drop results that do not have the right
objectclass value.
It is a little more wasteful than being able to specify a secondary
filter (that would probably be a great addition to the draft), for the
search done on the attribute of the group entry, but it is still good
enough to efficiently get results as well as easily weed off unwanted
ones.

> the restrictions in both places.

True, but are not doing this for security reasons, we are just taking
the fact that omissions are permissible as a blanket permission to omit
results, and clients should be prepared to deal with that.

After all the texts are vague and you could think that the security
measure expressed here is about not revealing group names.

The fact you can easily scan the whole group ID space is just the
annoying consequence of the fact most systems do not have a randomized
ID assignment policy and have a pretty limited ID space at just 32bit of
size or less. But hey, that's not my fault! :-)

> cases where I'd say that breaking formal compatibility might well be appropriate.

Yes, it would be nice to change the class, because it is forward safe to
do so, if you created objects when the MUST was in place, nothing breaks
if you relax the constraint to MAY, at least from the POV of data
consistency in the directory.

And I never found any software the specifically rely on the fact you
can't delete the last member attribute from a group for something.
Actually usually I saw software that had to use workarounds like adding
the group dn to itself (and concealing the self-reference in the UI)
when an admin wants to remove the last member but not remove the whole
group.

Simo.

---

From: Jordan Brown <[email-masked]>
Date: Wed, 2 Dec 2015 10:08:55 -0800

On 12/2/2015 9:21 AM, Simo Sorce wrote:
>> [draft-masarati-ldap-deref-00] is indeed very interesting. I don't
>> immediately see how it helps with the type-safety problem, though.
>> Am I missing something?

OK, sure.  (Better still would be to have some way to tell the directory to limit 
the types allowed.)
>> information on the basis of security restrictions. Omitting the data there 
>> would not help security at all if you could immediately turn around and request 
>> it through getgrname and getgrgid. Meeting the security need would require 
>> having the restrictions in both places. 

Right, but the standard describes it in terms of security.

> measure expressed here is about not revealing group names.

It explicitly mentions editing the list of members (emphasis added):

http://pubs.opengroup.org/onlinepubs/9699919799/functions/getgrent.html

    An implementation that provides extended security controls may impose further
    implementation-defined restrictions on accessing the group database. In
    particular, the system may deny the existence of some or all of the group
    database entries associated with groups other than those groups associated
    with the caller *and may omit users other than the caller from the list of
    members of groups in database entries that are returned*.

> size or less. But hey, that's not my fault! :-)

That too, but I was thinking about the list-of-members part... if you have a 
security reason for keeping the list of members hidden, it wouldn't do you any 
good to hide it from getgrent when the caller could then immediately retrieve it 
using getgrgid.

> when an admin wants to remove the last member but not remove the whole

The potential problem is a consumer that knows that the "member" attribute MUST be 
present, and freaks out if it isn't.

---

From: Simo Sorce <[email-masked]>
Date: Wed, 02 Dec 2015 13:37:17 -0500

On Wed, 2015-12-02 at 10:08 -0800, Jordan Brown wrote:
> 
> The potential problem is a consumer that knows that the "member"
> attribute MUST be present, and freaks out if it isn't.

I have no evidence of such client existing or being relevant.

Simo.

---

From: "Bannister, Mark" <[email-masked]>
Date: Thu, 3 Dec 2015 10:35:07 +0000

> Ah, indeed.  So if there were case-sensitive and case-insensitive attributes available (presumably in different auxiliary classes), you could use > those mapping constructs to choose the non-default variation.

> It doesn't look like you've got 4876 completely covered, though.  Attribute mapping is only one of the things it does - it also tells the clients which > servers to connect to and what authentication schemes to use.  If you're replacing 4876, there should be a plan for replacing that capability.

Yes I’ve not quite understood that.  You need to configure the client to talk to an LDAP server, in order

to obtain a profile that tells it to talk to a different LDAP server instead.  Why would you not just

configure the client to talk to the correct LDAP server in the first place?  Please explain the use-case.

> I work in name services, not file systems, so it's not an active project.  I just think it'll happen eventually, that

> interoperability with Windows will force it.

I found an interesting discussion on this very subject:

https://news.ycombinator.com/item?id=8876722

Mark.

---

From: "Bannister, Mark" <[email-masked]>
Date: Thu, 3 Dec 2015 10:42:53 +0000

> Mark.

... and let’s not also forget:

http://pubs.opengroup.org/onlinepubs/000095399/xrat/xbd_chap04.html#tag_01_04_06

I think some of the locale considerations given in these two links can be applied to the discussion

of case insensitivity in LDAP attributes too.

Mark.

---

From: Jordan Brown <[email-masked]>
Date: Thu, 3 Dec 2015 09:00:24 -0800

On 12/3/2015 2:35 AM, Bannister, Mark wrote:
>
>> It doesn't look like you've got 4876 completely covered, though.  Attribute 
>> mapping is only one of the things it does - it also tells the clients which 
>> servers to connect to and what authentication schemes to use.  If you're 
>> replacing 4876, there should be a plan for replacing that capability.
>

Centralized reconfiguration.  Your initial configuration is a bootstrap; after 
that, changes in the profile can direct you to use new sets of servers as existing 
servers are replaced.  Similarly, if you've got PKI or Kerberos infrastructure in 
place, the profile can tell you to start using it.

---

From: Jordan Brown <[email-masked]>
Date: Thu, 3 Dec 2015 09:17:26 -0800

[ Trying to keep case sensitivity discussions on their own thread ]

> of case insensitivity in LDAP attributes too.

If we were starting from NIS and /etc/passwd, yes.
If we were not concerned with directory interoperability between different 
platforms, yes.
If we were not concerned with consistency with names as used in the rest of the 
industry and in normal human practice, yes.

But none of those things are true.

---

From: Charlie <[email-masked]>
Date: Thu, 3 Dec 2015 17:45:20 -0500

Well, in a cleanly integrated environment, I'd expect to see most
users' Microsoft SamAccountName and POSIX uid be identical lower-cased
strings less than 20 characters long.  I believe all currently
shipping LDAP directory implementations support the necessary schema.
Certainly AD and OpenLDAP both do.

SamAccountName should be case-insensitive, uid should be
case-sensitive.  If you use each one appropriately in the environment
for which it is intended, you can let POSIX sysadmins and Windows
sysadmins retain whatever preferences, whims or bigotries they
treasure.  End users will be able to use all their systems as the
documentation directs them, and programmers will be able to rely on
their man pages &etc.

I just don't see any significant advantages to using a single naming
attribute shared with other systems.   Why bother?   It's all pain, no
gain.  Keeping case-sensitive and case-insensitive versions of user
identifiers is easier and gives better results.  All software on the
local node will perform as expected, and no OS documentation needs to
be rewritten.

--Charlie

---

From: Jordan Brown <[email-masked]>
Date: Thu, 3 Dec 2015 15:02:05 -0800

On 12/3/2015 2:45 PM, Charlie wrote:
> case-sensitive.

If sAMAccountName and uid are identical, and sAMAccountName is case-insensitive, 
doesn't that mean that you can't have two users whose 'uid' differs only in case?

It would seem that the only visible effect of such a configuration is that an 
attempt to look up a wrong-case name on UNIX would fail, which is compatible in 
some sense but doesn't seem to really add any value over case-insensitivity.

---

From: Charlie <[email-masked]>
Date: Thu, 3 Dec 2015 18:24:30 -0500

On Thu, Dec 3, 2015 at 6:02 PM, Jordan Brown <[email-masked]> wrote:
> If sAMAccountName and uid are identical, and sAMAccountName is
> case-insensitive, doesn't that mean that you can't have two users whose
> 'uid' differs only in case?

I think you missed the word "most"?   Normal user accounts being
created today would be unlikely to differ from each other only in
case.  Just old stuff and unique hacks.

> It would seem that the only visible effect of such a configuration is that
> an attempt to look up a wrong-case name on UNIX would fail, which is
> compatible in some sense but doesn't seem to really add any value over
> case-insensitivity.

I see compatibility with published standards and system documentation
as being vastly more valuable than catering to typing mistakes, but
obviously that's just my opinion.

More importantly, *nix tools and system utilities are going to make
case-sensitive comparisons of usernames internally, so if your name
service daemons aren't case-sensitive as well, *nix-based systems are
likely to be subtly broken.  Comparisons aren't restricted to the LDAP
service host, they happen on the local OS too - including in
site-developed code that was built to documented standards.

--Charlie

---

From: Jordan Brown <[email-masked]>
Date: Thu, 3 Dec 2015 16:51:34 -0800

I'm sorry, I just realized that this is a religious rathole that I can't afford to 
dive into.

---

From: "Oza, Dhairesh" <[email-masked]>
Date: Fri, 4 Dec 2015 07:05:57 +0000

> 
> > It would seem that the only visible effect of such a configuration is
> > that an attempt to look up a wrong-case name on UNIX would fail, which
> > is compatible in some sense but doesn't seem to really add any value
> > over case-insensitivity.
> 
> I see compatibility with published standards and system documentation as
> being vastly more valuable than catering to typing mistakes, but obviously
> that's just my opinion.
> 
> More importantly, *nix tools and system utilities are going to make case-
> sensitive comparisons of usernames internally, so if your name service
> daemons aren't case-sensitive as well, *nix-based systems are likely to be
> subtly broken.  Comparisons aren't restricted to the LDAP service host, they
> happen on the local OS too - including in site-developed code that was built to
> documented standards.
 
They shouldn't be comparing names but uids/gids. Most tools and file systems do this. As long as the source for look-up is always LDAP for both the client and server and it handles the cases consistently, there should not be any problem. When specifying usernames in configs (like owner on files), it would be nice if case didn't matter.

So I agree with earlier comments that changing usernames that differ only in cases is a onetime pain that can be borne during the transition to LDAP from NIS.

Rgds
Dhairesh

> --Charlie
> 
> _______________________________________________
> Ldapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ldapext

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 4 Dec 2015 12:38:10 +0000

The more I look at this problem the more complex it gets, so time for a summary.

Mark Bannister points out that case is a hard problem. In fact if we consider
all the locales and cultures that a standard must serve it is *impossible* to
do case-folding 'right' for everyone at once.

> http://pubs.opengroup.org/onlinepubs/000095399/xrat/xbd_chap04.html#tag_01_04_06

On the other hand, most computer users in Western cultures have become
used to a large degree of case-insensitivity and this has been rolled
into a lot of standards. There are several reasons for this, for example:

1)	History: until about 1985 there were a lot of I/O devices that
	could not handle lower case at all, so when lower-case became
	available it had to be used in a backwards-compatible way.
	Indeed, some banking systems still seem to be upper-case only.

2)	In some cultures there are no hard-and-fast rules for how certain
	name forms should be capitalised, so searches have to allow for
	this common ambiguity.

3)	Laziness. This might be considered a virtue.

Like it or not, all of the computing systems we are working with started
life with a very strong Western cultural bias. In fact most of them have
a bias towards the English language as used in North America.

This means that Western non-technical users expect case-insensitive behaviour
wherever that is possible. They have to be reminded that passwords are
(sometimes) case sensitive and that the Caps Lock key is a hazard.

The case-sensitive/insensitive problem is not just Unix vs Windows.
For most end-users the ever-growing range of web-based apps is far more
important. Many of those use e-mail addresses as usernames, and
assume that such things are always case-insensitive. The standards allow
case-sensitive names to the left of the '@' but in practice no mail admin
in their right mind would implement case sensitive addresses. At least
in this case we have a limited character set where case rules are well
defined!

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.

What we might aspire to is a standard that is general enough to be useful,
which is internally self-consistent, and which comes with some guidelines
to help people change their systems to work with it without breaking too
many things.

Charlie said:

> strings less than 20 characters long.

... and later:

> Normal user accounts being

That seems like a very sensible target for systems serving predominantly
Western user-bases. To make it really safe you have to disallow all
non-ASCII characters, but that can be relaxed if the name form is carefully
controlled at account-creation time and the users are told to always
enter it exactly as defined.

> local node will perform as expected, and no OS documentation needs to

If we were just trying to serve Unix and Windows that might be true,
but the problem is wider. A unified account namespace for all systems
is a worthwhile target for any organisation, but every system added to
the mix brings its own quirks and limitations. Catering for those is
more in the realm of best-practice advice than standards definition.

> site-developed code that was built to documented standards.

While true, the amount of trouble caused by this can be considerably
reduced by following a strict username allocation policy such as the one
proposed above.

Dhairesh said:

> So I agree with earlier comments that changing usernames that differ
> only in cases is a onetime pain that can be borne during the transition
> to LDAP from NIS.

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.

Note that the above discussion *only* applies to usernames and groupnames.
Unix-specific mappings such as automount maps are a different issue.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

---

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 15:00:44 +0100

> 'right' while providing interworking of differing systems. It is simply

That perfectly summarizes this topic.
Thanks Andrew, for this clear statement.

Let's keep the scope right.

> as a special case that may be better handled in another way.

+1 !!!

(That's pretty much exactly what I planned to suggest.)

> 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.

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.

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.

Ciao, Michael.

---

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 15:51:47 +0100

> Both OpenLDAP and 389ds (for FreeIPA) implement this control and we use

I also consider this control to be very useful and therefore I've added support
for it in python-ldap a couple of weeks ago.  And since there are already two
independent server implementations it should be easy to bring this I-D to a
ldapext RFC.

Not sure whether the original authors are still motivated to work on it.

Ciao, Michael.

---

From: Simo Sorce <[email-masked]>
Date: Fri, 04 Dec 2015 10:40:10 -0500

> 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.

> 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.

> 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.

---

From: Howard Chu <[email-masked]>
Date: Fri, 4 Dec 2015 16:04:17 +0000

> Not sure whether the original authors are still motivated to work on it.

I proposed this control to satisfy a need in supporting SAMBA / 
AD-compatibility in OpenLDAP. Symas is still actively engaged in implementing 
ActiveDirectory functionality in OpenLDAP, so yes, we are still committed to 
this particular item.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

---

From: Simo Sorce <[email-masked]>
Date: Fri, 04 Dec 2015 11:06:29 -0500

> ActiveDirectory functionality in OpenLDAP, so yes, we are still committed to 

At this point we are dependent on this control in FreeIPA (as well as
our Samba work) so I will gladly volunteer to work on it if needed.

Simo.

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 4 Dec 2015 16:56:29 +0000

> case-preserving, both for user names and services.

One idea that I did not put in the summary as it is a bit of a
side-issue:

Client systems that care about case-sensitivity might be given a config
option to use extensible matching:

ldapsearch -x '(&objectclass=posixAccount)(uid:caseExactMatch:=BABS))'
ldapsearch -x '(&objectclass=posixAccount)(uid:caseExactMatch:=babs))'

It would then be possible to have two entries where the uid differs only
in case provided uid is not used as the RDN attribute. This SHOULD
prevent either user from logging in on systems that are not using the
search shown above, as the result of a normal search on uid would be
ambiguous. Data management would require great care.

> name-mismatches have been mush easier to deal with because it is easy to

People are often tempted to build complex technical solutions because
that is within their control and ability. It is almost always better in
the long run to fix the organisational issues and migrate to a clean(er)
set of data using a simpler technical setup.

Anyone can make an existing system more complex. It takes effort and
clear vision to make it simpler.

Andrew

---

From: Michael Ströder <[email-masked]>
Date: Fri, 4 Dec 2015 17:59:05 +0100

> case-preserving, both for user names and services.

I concur with case-preserving.  But EQUALITY matching rule (which also enforces
uniqueness) should be case-insensitive.

> name-mismatches have been mush easier to deal with because it is easy to

In those cases I tend to recommend to simply keep different LDAP server deployments.

Ciao, Michael.

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 4 Dec 2015 18:39:52 +0000

> > >> actually makes sense to retrieve the list of members of a UNIX group.

+1 (at least!)

> measure expressed here is about not revealing group names.

I think this is a very valuable insight. Any program that expects to
enumerate the whole password or group database is a liability and this
has been the case since Unix escaped from Bell Labs.

In the 1980s there was a machine called Pyramid: it had a hashed database
for /etc/hosts but it searched /etc/group and /etc/passwd linearly. We
had one at the university for undergrad use so both files were quite
large by the standards of the day (5000 entries - seems trivial now!)
The result was very slow logins for people near the end of the file.
This took a while to notice as all the computing staff were at the front...

Following the POSIX stuff a bit further, getgrnam() refers to grp.h:

	http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/grp.h.html

Donning a definition-lawyer's pedantic wig I find this:

------------------------------------------------------------------------
The <grp.h> header shall declare the group structure, which shall include the following members:

char   *gr_name The name of the group. 
gid_t   gr_gid  Numerical group ID. 
char  **gr_mem  Pointer to a null-terminated array of character 
                pointers to member names. 
------------------------------------------------------------------------

That last field is interesting. There are pointers to member names, but
it does *not* say that *all* members will be listed. Taken with the 'extended
security controls' applicable to getgrent() I take this as approval to
return only the data that an application would reasonably need.

Certainly a new API would be better, but I think a config option to
'do the efficient thing' would be very reasonable.

Andrew

---

From: Jordan Brown <[email-masked]>
Date: Fri, 4 Dec 2015 11:03:48 -0800

On 12/3/2015 11:05 PM, Oza, Dhairesh wrote:
> They shouldn't be comparing names but uids/gids.

Unfortunately, it's not always that simple.

An e-mail program may have a configuration file with alias entries... are they 
case sensitive?
Any program might keep per-user files somewhere, named after the user... is the 
file system case sensitive?

In general, any configuration file might have user names in it (because they're 
the appropriate human interface), and might compare names because that's the 
obvious way to do it.

People who say that case-insensitive user names may cause subtle problems are 
absolutely correct.  But that doesn't mean that we shouldn't head that way.

---

From: "Bannister, Mark" <[email-masked]>
Date: Fri, 4 Dec 2015 22:00:27 +0000

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.

Yes it *is* possible.  You take the POSIX approach and do not attempt to interpret case.  You do
byte-by-byte comparisons.  I store data in LDAP, when I retrieve it I expect to find it only if
I send an identical sequence of bytes, and when it is returned it is unchanged.  Anything else
is making the system more complex than it needs to be.

> Anyone can make an existing system more complex. It takes effort and clear vision to make it simpler.

Isn't that what I just said?  I'm glad you agree with me ;-)  So, 65 goes in, 65 is what I need to find
it and 65 is what comes out the other end.  If I send 97, I should quite rightly not find my data.
That's my simple, clear vision.  As for users who don't know how to use their CAPS LOCK key,
send them on a training course, one that teaches them how to interact successfully with
computer systems.  Remind them it is a computer, not a human.  We are already having to
display pop-ups in password fields along the lines of "you have your CAPS LOCK key turned
on, are you sure you meant to do that?" ... we could do the same with login name fields.
It is easier to educate humans to interact with computers, than the other way around.

> Like it or not, all of the computing systems we are working with started life with a very strong
> Western cultural bias. In fact most of them have a bias towards the English language as used
> in North America.

It shouldn't matter that computers grew out of Western culture, that should have to change, as
the world is bigger now, standards ought to move on to reflect that.  Embrace diversity through
simplicity.  Trying to maintain rules for case insensitive matching that make sense in 2015, that
work for every locale, seems like a foolish never-ending pastime with practically zero benefit.

Mark.

-----Original Message-----
From: Ldapext [mailto:[email-masked]] On Behalf Of Andrew Findlay
Sent: 04 December 2015 16:56
To: Simo Sorce
Cc: LDAP Extensions list; Michael Ströder
Subject: Re: [ldapext] Case sensitivity summary

Client systems that care about case-sensitivity might be given a config option to use extensible matching:

It would then be possible to have two entries where the uid differs only in case provided uid is not used as the RDN attribute. This SHOULD prevent either user from logging in on systems that are not using the search shown above, as the result of a normal search on uid would be ambiguous. Data management would require great care.

> 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.

People are often tempted to build complex technical solutions because that is within their control and ability. It is almost always better in the long run to fix the organisational issues and migrate to a clean(er) set of data using a simpler technical setup.

Anyone can make an existing system more complex. It takes effort and clear vision to make it simpler.

Andrew

--------------------------------------------------------------------------------

NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies; do not disclose, use or act upon the information; and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

---

From: Andrew Findlay <[email-masked]>
Date: Fri, 4 Dec 2015 22:49:49 +0000

On Fri, Dec 04, 2015 at 10:00:27PM +0000, Bannister, Mark wrote:

> byte-by-byte comparisons.

Yes that works perfectly. IFF you are only considering Unix-like
systems. Most LDAP deployments at least aspire to be useful for a wider
range of client systems.

[ IFF == If and only if ]

Andrew

---

From: "Bannister, Mark" <[email-masked]>
Date: Fri, 4 Dec 2015 22:58:17 +0000

> > > 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.
> > 
> > Yes it *is* possible.  You take the POSIX approach and do not attempt 
> > to interpret case.  You do byte-by-byte comparisons.
> 
> Yes that works perfectly. IFF you are only considering Unix-like systems. Most LDAP
> deployments at least aspire to be useful for a wider range of client systems.
> 

Not true.  If all you're trying to do is protect Windows users from accidental use
of the CAPS LOCK key, you can fix that in Windows before you even talk to the
directory server.

Mark.