Re: Case sensitivity of user/group names (was Re: DBIS commentary)
"Bannister, Mark" <[email protected]> Wed, 2 Dec 2015 09:19:22 +0000
| Newsgroups | gmane.ietf.ldapext |
|---|---|
| Message-ID | <[email protected]> |
--===============4437020559714203919==
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339OZWEX0209N2msad_"
--_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339OZWEX0209N2msad_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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, i=
t seems like
> there's an unbreakable chain of connections between them. Either the att=
ribute is
> case-sensitive, in which case the natively-case-insensitive OS will be co=
nfused, or
> the attribute is case-insensitive, in which case the natively-case-sensit=
ive 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... an=
d 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 nex=
t 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 hav=
e 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 direc=
tories.
A directory is a server, the clue is in the name, it *serves* clients. Dif=
ferent clients have
different needs. It would be wrong to mandate big changes on the client-si=
de 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 attribut=
e that's
> case-sensitive and another that's case-insensitive (presumably from diffe=
rent auxiliary
> classes), and technically that'd be possible, but seems like an administr=
ative nightmare...
> a very high cost to pay for the 0.1% of names where case-sensitivity is i=
mportant.
Ok here's an idea. What if we could define case sensitive entries in a dir=
ectory that
were only available to case sensitive clients. All the case insensitive en=
tries were available
to all. Then, in 99% of cases where we don't care and UNIX/Windows share a=
ttributes
they can interoperate. In the 1% of cases where we need UNIX-specific entr=
ies that
are case sensitive, we don't want the Windows hosts to see these entries be=
cause 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 use=
r names as an example
here), it will see:
mark
jordan
michael
charlie
CHARLIE
(where CHARLIE is actually a service account that our customer wants specif=
ically in uppercase
for whatever reason, we don't care about the reason here remember, we're ju=
st 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 runnin=
g 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=3Drfc2307,o=
=3Dinfra) and one
using the DBIS schema (e.g. ou=3Ddbis,o=3Dinfra). A UNIX client will obtai=
n passwd entries
from both locations, and the case sensitive users are configured under ou=
=3Ddbis,o=3Dinfra.
Windows clients only know about ou=3Drfc2307,o=3Dinfra and therefore only g=
et to see
the case insensitive entries.
Mark.
(p.s. sorry Charlie couldn't include you directly in this reply as our corp=
orate security
policy prevents me from mailing a gmail account, but hopefully you'll get i=
t via
the mailing list).
________________________________
NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion=
s 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 Refo=
rm 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. Mistransmi=
ssion is not intended to waive confidentiality or privilege. Morgan Stanley=
reserves the right, to the extent permitted under applicable law, to monit=
or 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 foreg=
oing.
--_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339OZWEX0209N2msad_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
<HTML xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<HEAD><!-- Template generated by Exclaimer Template Editor on 04:19:24 Wedn=
esday, 2 December 2015 -->
<STYLE type=3Dtext/css>P.c982f757-1516-4855-94c6-b30e24238799 {
MARGIN: 0cm 0cm 0pt
}
LI.c982f757-1516-4855-94c6-b30e24238799 {
MARGIN: 0cm 0cm 0pt
}
DIV.c982f757-1516-4855-94c6-b30e24238799 {
MARGIN: 0cm 0cm 0pt
}
TABLE.c982f757-1516-4855-94c6-b30e24238799Table {
MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
page: Section1
}
</STYLE>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
/>
<meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)" />
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
color:black;}
p.MsoNoSpacing, li.MsoNoSpacing, div.MsoNoSpacing
{mso-style-priority:1;
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Calibri","sans-serif";
color:black;}
span.Code
{mso-style-name:Code;
mso-style-priority:1;
font-family:"Courier New";}
span.EmailStyle19
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri","sans-serif";
color:black;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</HEAD>
<BODY lang=3D"EN-GB" link=3D"blue" vlink=3D"purple">
<P>
<div class=3D"WordSection1">
<p class=3D"MsoPlainText">Jordan Brown wrote:<o:p></o:p></p>
<p class=3D"MsoPlainText">> > On 12/1/2015 2:06 PM, Charlie wrote: <o=
:p></o:p></p>
<p class=3D"MsoPlainText">> > <o:p></o:p></p>
<p class=3D"MsoPlainText">> > A directory backend that is intended to=
serve multiple existing
<o:p></o:p></p>
<p class=3D"MsoPlainText">> > operating systems probably shouldn't be=
telling any of those operating
<o:p></o:p></p>
<p class=3D"MsoPlainText">> > systems whether or not they should be c=
ase-sensitive. It's out of
<o:p></o:p></p>
<p class=3D"MsoPlainText">> > scope for the project and causes argume=
nts. <o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> Well, but... if the various OSes are sharing=
the same naming attribute, it seems like<o:p></o:p></p>
<p class=3D"MsoPlainText">> there's an unbreakable chain of connections =
between them. Either the attribute is<o:p></o:p></p>
<p class=3D"MsoPlainText">> case-sensitive, in which case the natively-c=
ase-insensitive OS will be confused, or<o:p></o:p></p>
<p class=3D"MsoPlainText">> the attribute is case-insensitive, in which =
case the natively-case-sensitive OS will be confused.
<o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> The way that I look at it is not that the di=
rectory is serving the OSes, but that the<o:p></o:p></p>
<p class=3D"MsoPlainText">> directory is defining a world that the OSes =
are choosing to play in... and when they<o:p></o:p></p>
<p class=3D"MsoPlainText">> choose to play in the directory's world, the=
y have to live by its rules.
<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">Hang on. In the old days, directories were =
giant yellow books that sat next to the<o:p></o:p></p>
<p class=3D"MsoPlainText">telephone. There were no rules of engagemen=
t. You want a telephone number,<o:p></o:p></p>
<p class=3D"MsoPlainText">you open the book and find it. If the book =
was upside down, you didn’t have to stand<o:p></o:p></p>
<p class=3D"MsoPlainText">on your head to read it, you could turn the book =
round.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">I think it would be a mistake to try to make the =
world revolve around directories.<o:p></o:p></p>
<p class=3D"MsoPlainText">A directory is a server, the clue is in the name,=
it *serves* clients. Different clients have<o:p></o:p></p>
<p class=3D"MsoPlainText">different needs. It would be wrong to manda=
te big changes on the client-side just<o:p></o:p></p>
<p class=3D"MsoPlainText">to interoperate, but this is exactly what you are=
suggesting. Remember not everyone<o:p></o:p></p>
<p class=3D"MsoPlainText">cares about having their UNIX and Windows entries=
co-exist anyway and never will.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">> > That being said, options are great to h=
ave. If you can support
<o:p></o:p></p>
<p class=3D"MsoPlainText">> > existing systems while also giving peop=
le the ability to do whatever
<o:p></o:p></p>
<p class=3D"MsoPlainText">> > you happen to think is better, you'll a=
utomatically win any such
<o:p></o:p></p>
<p class=3D"MsoPlainText">> > arguments. <o:p></o:p></p>
<p class=3D"MsoPlainText">> <o:p></o:p></p>
<p class=3D"MsoPlainText">> It's tempting to suggest that a single entry=
could have one name attribute that's<o:p></o:p></p>
<p class=3D"MsoPlainText">> case-sensitive and another that's case-insen=
sitive (presumably from different auxiliary<o:p></o:p></p>
<p class=3D"MsoPlainText">> classes), and technically that'd be possible=
, but seems like an administrative nightmare...<o:p></o:p></p>
<p class=3D"MsoPlainText">> a very high cost to pay for the 0.1% of name=
s where case-sensitivity is important.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">Ok here’s an idea. What if we could d=
efine case sensitive entries in a directory that<o:p></o:p></p>
<p class=3D"MsoPlainText">were only available to case sensitive clients.&nb=
sp; All the case insensitive entries were available<o:p></o:p></p>
<p class=3D"MsoPlainText">to all. Then, in 99% of cases where we don&=
#8217;t care and UNIX/Windows share attributes<o:p></o:p></p>
<p class=3D"MsoPlainText">they can interoperate. In the 1% of cases w=
here we need UNIX-specific entries that<o:p></o:p></p>
<p class=3D"MsoPlainText">are case sensitive, we don’t want the Windo=
ws hosts to see these entries because they<o:p></o:p></p>
<p class=3D"MsoPlainText">would get confused, we can define them too.<o:p><=
/o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">Then the DUA on a UNIX host can advertise itself =
as case sensitive when it binds to the DSA,<o:p></o:p></p>
<p class=3D"MsoPlainText">when it searches for a list of user names (or wha=
tever data, just using user names as an example<o:p></o:p></p>
<p class=3D"MsoPlainText">here), it will see:<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">mark<o:p></o:p></p>
<p class=3D"MsoPlainText">jordan<o:p></o:p></p>
<p class=3D"MsoPlainText">michael<o:p></o:p></p>
<p class=3D"MsoPlainText">charlie<o:p></o:p></p>
<p class=3D"MsoPlainText">CHARLIE<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">(where CHARLIE is actually a service account that=
our customer wants specifically in uppercase<o:p></o:p></p>
<p class=3D"MsoPlainText">for whatever reason, we don’t care about th=
e reason here remember, we’re just providing<o:p></o:p></p>
<p class=3D"MsoPlainText">options).<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">A Windows client does not advertise itself as cas=
e sensitive when it binds to the DSA, and when<o:p></o:p></p>
<p class=3D"MsoPlainText">it performs the same LDAP search it will see:<o:p=
></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">mark<o:p></o:p></p>
<p class=3D"MsoPlainText">jordan<o:p></o:p></p>
<p class=3D"MsoPlainText">michael<o:p></o:p></p>
<p class=3D"MsoPlainText">charlie<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">... and that’s ok, because CHARLIE is a ser=
vice account intended for running a UNIX app.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">You can actually do this today using DBIS, by set=
ting up two configuration map entries<o:p></o:p></p>
<p class=3D"MsoPlainText">for the passwd database, one using the RFC2307 sc=
hema (e.g. ou=3Drfc2307,o=3Dinfra) and one<o:p></o:p></p>
<p class=3D"MsoPlainText">using the DBIS schema (e.g. ou=3Ddbis,o=3Dinfra).=
A UNIX client will obtain passwd entries<o:p></o:p></p>
<p class=3D"MsoPlainText">from both locations, and the case sensitive users=
are configured under ou=3Ddbis,o=3Dinfra.<o:p></o:p></p>
<p class=3D"MsoPlainText">Windows clients only know about ou=3Drfc2307,o=3D=
infra and therefore only get to see<o:p></o:p></p>
<p class=3D"MsoPlainText">the case insensitive entries.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">Mark.<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
<p class=3D"MsoPlainText">(p.s. sorry Charlie couldn’t include you di=
rectly in this reply as our corporate security<o:p></o:p></p>
<p class=3D"MsoPlainText">policy prevents me from mailing a gmail account, =
but hopefully you’ll get it via<o:p></o:p></p>
<p class=3D"MsoPlainText">the mailing list).<o:p></o:p></p>
<p class=3D"MsoPlainText"><o:p> </o:p></p>
</div>
<BR /><BR />
<HR id=3DHR1 />
<BR /><SPAN style=3D"FONT-FAMILY: Arial; COLOR: #808080; FONT-SIZE: 7.5pt">=
NOTICE:=20
Morgan Stanley is not acting as a municipal advisor and the opinions or vie=
ws=20
contained herein are not intended to be, and do not constitute, advice with=
in=20
the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consume=
r=20
Protection Act. If you have received this communication in error, please de=
stroy=20
all electronic and paper copies; do not disclose, use or act upon the=20
information; and notify the sender immediately. Mistransmission is not inte=
nded=20
to waive confidentiality or privilege. Morgan Stanley reserves the right, t=
o the=20
extent permitted under applicable law, to monitor electronic communications=
.=20
This message is subject to terms available at the following link: <A style=
=3D"FONT-FAMILY: Arial; COLOR: #808080; FONT-SIZE: 7.5pt" href=3D"http://ww=
w.morganstanley.com/disclaimers">http://www.morganstanley.com/disclaimers</=
A>=20
If you cannot access these links, please notify us by reply message and we =
will=20
send the contents to you. By messaging with Morgan Stanley you consent to t=
he=20
foregoing.</SPAN><BR />
<P></P>
<P></P>
<P></P></P></BODY>
</HTML>
--_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339OZWEX0209N2msad_--
--===============4437020559714203919==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext
--===============4437020559714203919==--