Re: [ldapext] Case sensitivity summary
Andrew Findlay <andrew.findlay@skills-1st.co.uk> Fri, 04 December 2015 16:56 UTC
Return-Path: <andrew.findlay@skills-1st.co.uk>
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 E32321A8A3F for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 08:56:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MlbLAVsVyJQe for <ldapext@ietfa.amsl.com>; Fri, 4 Dec 2015 08:56:32 -0800 (PST)
Received: from kea.ourshack.com (kea.ourshack.com [IPv6:2001:470:1f15:20::201]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304421A8A3A for <ldapext@ietf.org>; Fri, 4 Dec 2015 08:56:32 -0800 (PST)
Received: from 4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.e.7.f.0.d.8.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:8d0:f7e1::94] helo=slab.skills-1st.co.uk) by kea.ourshack.com with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1a4teo-00076C-FH; Fri, 04 Dec 2015 16:56:30 +0000
Received: from andrew by slab.skills-1st.co.uk with local (Exim 4.85) (envelope-from <andrew.findlay@skills-1st.co.uk>) id 1a4ten-0002d9-W2; Fri, 04 Dec 2015 16:56:29 +0000
Date: Fri, 04 Dec 2015 16:56:29 +0000
From: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
To: Simo Sorce <simo@redhat.com>
Message-ID: <20151204165629.GJ3643@slab.skills-1st.co.uk>
References: <20151204123810.GA8983@slab.skills-1st.co.uk> <56619C8C.1010805@stroeder.com> <1449243610.3445.58.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1449243610.3445.58.camel@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Andrew Findlay <andrew.findlay@skills-1st.co.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ldapext/y8joNdJ5eLay5W6MdhmS7iNdhzk>
Cc: LDAP Extensions list <ldapext@ietf.org>, Michael Ströder <michael@stroeder.com>
Subject: Re: [ldapext] Case sensitivity summary
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: 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 side-issue: 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. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] DBIS commentary Steven Legg
- Re: [ldapext] DBIS commentary Simo Sorce
- Re: [ldapext] DBIS commentary Charlie
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] DBIS commentary Ludovic Poitou
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] DBIS commentary Charlie
- Re: [ldapext] DBIS commentary Jordan Brown
- [ldapext] Case sensitivity of user/group names (w… Jordan Brown
- Re: [ldapext] DBIS commentary Simo Sorce
- Re: [ldapext] DBIS commentary Simo Sorce
- [ldapext] Using groupOfNames (or similar) for UNI… Jordan Brown
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] Case sensitivity of user/group name… Bannister, Mark
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] Using groupOfNames (or similar) for… Simo Sorce
- Re: [ldapext] Using groupOfNames (or similar) for… Jordan Brown
- Re: [ldapext] Using groupOfNames (or similar) for… Simo Sorce
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] DBIS commentary Bannister, Mark
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] DBIS commentary Jordan Brown
- Re: [ldapext] Case sensitivity of user/group name… Charlie
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] Case sensitivity of user/group name… Charlie
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] Case sensitivity of user/group name… Oza, Dhairesh
- [ldapext] Case sensitivity summary Andrew Findlay
- Re: [ldapext] Case sensitivity summary Michael Ströder
- [ldapext] draft-masarati-ldap-deref as ldapext wo… Michael Ströder
- Re: [ldapext] Case sensitivity summary Simo Sorce
- Re: [ldapext] draft-masarati-ldap-deref as ldapex… Howard Chu
- Re: [ldapext] draft-masarati-ldap-deref as ldapex… Simo Sorce
- Re: [ldapext] Case sensitivity summary Andrew Findlay
- Re: [ldapext] Case sensitivity summary Michael Ströder
- Re: [ldapext] Using groupOfNames (or similar) for… Andrew Findlay
- Re: [ldapext] Case sensitivity of user/group name… Jordan Brown
- Re: [ldapext] Case sensitivity summary Bannister, Mark
- Re: [ldapext] Case sensitivity summary Andrew Findlay
- Re: [ldapext] Case sensitivity summary Bannister, Mark