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

"Bannister, Mark" <Mark.Bannister@morganstanley.com> Wed, 02 December 2015 09:19 UTC

Return-Path: <Mark.Bannister@morganstanley.com>
X-Original-To: ldapext@ietfa.amsl.com
Delivered-To: ldapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3151A1B95 for <ldapext@ietfa.amsl.com>; Wed, 2 Dec 2015 01:19:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.4
X-Spam-Level:
X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmLEulN8QdUv for <ldapext@ietfa.amsl.com>; Wed, 2 Dec 2015 01:19:26 -0800 (PST)
Received: from pimtaint03.ms.com (pimtaint03.ms.com [199.89.103.73]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574621A1B49 for <ldapext@ietf.org>; Wed, 2 Dec 2015 01:19:26 -0800 (PST)
Received: from pimtaint03 (localhost.ms.com [127.0.0.1]) by pimtaint03.ms.com (output Postfix) with ESMTP id 68A482B34418 for <ldapext@ietf.org>; Wed, 2 Dec 2015 04:19:25 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=morganstanley.com; s=p20150724; t=1449047965; x=1450257565; bh=xTBjwBeLRcbeWYNW/QyS0QU6BbmhXNIGPxSwuym+f3g=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=RvCT9YWInU4NBYEMbbKPsa8XJaQRUaXo1SigkG7WYUirdCWZXAhSwTEJIEF4w2j0T j4j5FnH7SlXx5/k0ShDF/RVZMN+tid+dtfbeVLVPsgyxmYaNpi07D9tjh/Wkp9lCMf IBtmt4pbBH2NVjhWg4louMN85XkzPDYIcvo8kJHM=
Received: from hzsmmta02.ms.com (hzsmmta02.ms.com [10.195.137.198]) by pimtaint03.ms.com (internal Postfix) with ESMTP id 4CE8C2B3437C; Wed, 2 Dec 2015 04:19:25 -0500 (EST)
Received: from RRWEX2003N2.msad.ms.com (rrwex2003n2.ms.com [10.196.135.17]) by hzsmmta02.ms.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB29JPBR021238; Wed, 2 Dec 2015 09:19:25 GMT
Received: from RRWEX2004N1.msad.ms.com (10.196.141.202) by RRWEX2003N2.msad.ms.com (10.196.135.17) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Dec 2015 04:19:24 -0500
Received: from OYWEX0205N4.msad.ms.com (10.208.118.92) by RRWEX2004N1.msad.ms.com (10.196.141.202) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 2 Dec 2015 04:19:24 -0500
Received: from OZWEX0209N2.msad.ms.com ([10.208.87.95]) by OYWEX0205N4.msad.ms.com ([10.208.118.92]) with mapi id 14.03.0235.001; Wed, 2 Dec 2015 09:19:23 +0000
From: "Bannister, Mark" <Mark.Bannister@morganstanley.com>
To: "'Jordan Brown'" <Jordan.Brown@oracle.com>
Thread-Topic: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary)
Thread-Index: AQHRLIq1SRf4xarC5EmoIP9nuG9pz563ZnJw
Date: Wed, 2 Dec 2015 09:19:22 +0000
Message-ID: <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339@OZWEX0209N2.msad.ms.com>
References: <5655E4F0.7030809@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F618A3@OZWEX0209N1.msad.ms.com> <565CAC30.6010701@oracle.com> <814F4E458AA9FF4E89CF1A9EDA0DE2A932F8EAFD@OZWEX0209N2.msad.ms.com> <565DDE78.5030908@oracle.com> <CAJb3uA4-PE+QQvhzZ45NQzsNiTw=Hg_EuoA8JE3uH+iTLGTrqQ@mail.gmail.com> <565E242A.7080703@oracle.com>
In-Reply-To: <565E242A.7080703@oracle.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mspolicyagent: version=1.0
x-originating-ip: [10.173.249.123]
Content-Type: multipart/alternative; boundary="_000_814F4E458AA9FF4E89CF1A9EDA0DE2A932F8F339OZWEX0209N2msad_"
MIME-Version: 1.0
X-EXCLAIMER-MD-CONFIG: be3bdf5c-71de-49fb-a1b7-ad6a6a1df5e2
X-EXCLAIMER-MD-CONFIG: f2a46809-d95e-4647-8996-91897c738879
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Status: not scanned, disabled by settings
X-KLMS-AntiPhishing: not scanned, disabled by settings
X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.705, bases: 2015/12/02 02:53:00 #6726429; khse: 2014-03-12 13:55:01
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/m7eTXyJmmyXCcdkqtI-XefIe6vg>
Cc: "ldapext@ietf.org" <ldapext@ietf.org>
Subject: Re: [ldapext] Case sensitivity of user/group names (was Re: DBIS commentary)
X-BeenThere: ldapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <ldapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ldapext>, <mailto:ldapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ldapext/>
List-Post: <mailto:ldapext@ietf.org>
List-Help: <mailto:ldapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ldapext>, <mailto:ldapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2015 09:19:31 -0000

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.