Re: [ldapext] Case sensitivity summary

"Bannister, Mark" <> Fri, 04 December 2015 22:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5E5331A92E3 for <>; Fri, 4 Dec 2015 14:01:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c77bWLTsX60J for <>; Fri, 4 Dec 2015 14:01:06 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D482E1A92E2 for <>; Fri, 4 Dec 2015 14:01:05 -0800 (PST)
Received: from pimtaint01 ( []) by (output Postfix) with ESMTP id A6A023042BB; Fri, 4 Dec 2015 17:01:04 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=p20150724; t=1449266464; x=1450476064; bh=B0iRtrp4xcKrOR60RIMd/8gQ3mERoxdaepVxx85O5n8=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=cYmL+tqibSr+Hzvc6Lps+tPrzrUTw9HLCpdPNeiHVSyURihLvtau9/B6jOvsUvvFY V9uWmUElUs6dnxVWoHI+nAagMB4MQu5uiOqJcIz/1NWzIdLPyNMRbOLiA8nCAyq38w En2q+46QEz/fX6/ERznttH186yBT1+mxZNd2aM+o=
Received: from ( []) by (internal Postfix) with ESMTP id 8866E3041BD; Fri, 4 Dec 2015 17:01:04 -0500 (EST)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id tB4M14hZ029374; Fri, 4 Dec 2015 22:01:04 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 4 Dec 2015 17:01:03 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 4 Dec 2015 17:01:03 -0500
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Fri, 4 Dec 2015 22:00:28 +0000
From: "Bannister, Mark" <>
To: 'Andrew Findlay' <>, Simo Sorce <>
Thread-Topic: [ldapext] Case sensitivity summary
Thread-Index: AQHRLpFcuE2cjQOlg0y8pThx01wW4Z662zMAgAAbyACAABVSgIAAUJHA
Date: Fri, 04 Dec 2015 22:00:27 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-mspolicyagent: version=1.0
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
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, bases: 2015/12/04 11:54:00 #6669674; khse: 2014-03-12 13:55:01
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <>
Cc: LDAP Extensions list <>, Michael Ströder <>
Subject: Re: [ldapext] Case sensitivity summary
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: LDAP Extension Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 04 Dec 2015 22:01:08 -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.


-----Original Message-----
From: Ldapext [] 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

On Fri, Dec 04, 2015 at 10:40:10AM -0500, Simo Sorce wrote:

> There are odd things in the wild, so you need to be at least 
> 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

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.

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

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.

|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|                +44 1628 782565     |

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