Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary)

["Bannister, Mark" <[e-mail]>]

Jordan Brown wrote:

> > On 12/1/2015 2:06 PM, Charlie wrote:

> >

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

>

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



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

>

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



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




________________________________

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.