Re: [ldapext] Case sensitivity summary

Andrew Findlay <> Fri, 04 December 2015 16:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E32321A8A3F for <>; Fri, 4 Dec 2015 08:56:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MlbLAVsVyJQe for <>; Fri, 4 Dec 2015 08:56:32 -0800 (PST)
Received: from ( [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 304421A8A3A for <>; Fri, 4 Dec 2015 08:56:32 -0800 (PST)
Received: from ([2001:8b0:8d0:f7e1::94] by with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <>) id 1a4teo-00076C-FH; Fri, 04 Dec 2015 16:56:30 +0000
Received: from andrew by with local (Exim 4.85) (envelope-from <>) id 1a4ten-0002d9-W2; Fri, 04 Dec 2015 16:56:29 +0000
Date: Fri, 4 Dec 2015 16:56:29 +0000
From: Andrew Findlay <>
To: Simo Sorce <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <>
Archived-At: <>
Cc: LDAP Extensions list <>, Michael =?iso-8859-1?Q?Str=F6der?= <>
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 16:56:34 -0000

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     |