Re: [ldapext] DBIS - new IETF drafts

Michael Ströder <michael@stroeder.com> Thu, 09 January 2014 20:36 UTC

Return-Path: <michael@stroeder.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 6CDEA1AE542 for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 12:36:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.839
X-Spam-Level:
X-Spam-Status: No, score=-2.839 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 1-EDwf5SeZbx for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 12:36:29 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 09B7D1AE53A for <ldapext@ietf.org>; Thu, 9 Jan 2014 12:36:29 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 9C06E6078D; Thu, 9 Jan 2014 21:36:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.com
Received: from srv1.stroeder.com ([127.0.0.1]) by localhost (srv1.stroeder.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdbbqafA8mmy; Thu, 9 Jan 2014 21:36:12 +0100 (CET)
Received: from [10.1.0.2] (unknown [10.1.0.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Str??der", Issuer "CA Cert Signing Authority" (verified OK)) by srv1.stroeder.com (Postfix) with ESMTPS id 1208060702; Thu, 9 Jan 2014 20:36:10 +0000 (UTC)
Message-ID: <52CF0838.3060102@stroeder.com>
Date: Thu, 09 Jan 2014 21:36:08 +0100
From: =?UTF-8?B?TWljaGFlbCBTdHLDtmRlcg==?= <michael@stroeder.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 SeaMonkey/2.23
MIME-Version: 1.0
To: Simo <s@ssimo.org>
References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk> <52CEC4D5.1070703@stroeder.com> <1389290636.27654.125.camel@pico.ipa.ssimo.org>
In-Reply-To: <1389290636.27654.125.camel@pico.ipa.ssimo.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050103080802040602040409"
Cc: ldapext@ietf.org
Subject: Re: [ldapext] DBIS - new IETF drafts
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: <http://www.ietf.org/mail-archive/web/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: Thu, 09 Jan 2014 20:36:31 -0000

Simo wrote:
> On Thu, 2014-01-09 at 16:48 +0100, Michael Ströder wrote:
>> Mark R Bannister wrote:
>>> Yes as you'll see from my recent reply to Simo, the case sensitivity issue was
>>> one of the problems I faced at a large installation,
>>
>> This could be easily solved with RFC2307bis. Or not?
>>
>> In my deployments I simply define additional (OpenLDAP) constraints for those
>> attributes (e.g. to enforce lower-case 'uid' values).
>>
>> IMHO only re-defining the matching rules does not fully solve the case problem
>> anyway. Restricting to lower-case attribute values helps better.
> 
> 
> I'd go beyond this, supporting case-sensitive user names is actively
> harmful for various reasons.
> 
> - Assuming users (and admins) should be able to distinguish based on
> case is wrong, we naturally consider the strings 'Admin' and 'admin' to
> be the same thing.
> 
> - Some systems are case-preserving (meaning they'll show you back the
> same case you entered, but are really case-insensitive and if you have
> to interoperate with them you cannot assume Admin and amdin to be
> different users, it could lead to serious security issues.
> 
> - If we are in the legacy game, there are still systems that will simply
> accept only all caps names, like ADMIN. In these cases what do you map
> that to ? Admin ? admin? a third user called ADMIN ?
> 
> And there are many other examples where really being case sensitive
> causes a lot more problem than it resolves.
> Due to these problems what we did in FreeIPA is to always create users
> in lower case and explicitly state we are case-preserving and
> insensitive. It is the only reasonable compromise IMHO.

So basically you're doing the same thing like I described above.

>>> Nested groups are very important especially in large enterprises, and really
>>> do assist with data management.
>>
>> I am always getting told this but I have strong doubts about nested groups.
> 
> Great value at least in IPA, we use them a lot to associate things like
> permissions to roles to groups and ultimately to users (All through
> nesting each of these as groupsofnames). It does really make some
> problems much easier to handle at the end of the process.

Which problems are easier? Personally I'd definitely consider abusing
groupOfNames for permissions bad schema design.

>>>  Yes we'll get more search operations, but I
>>> don't think this will be a problem.  I should be able to prove this will work
>>> in my reference implementation.
>>
>> Resolving nested group membership is a big performance cost. I can see this
>> with a MS Sharepoint installation working with a OpenLDAP server. Sharepoint
>> sends many search requests even though nested groups are not used in this
>> deployment.
> 
> Performance issues with nested groups can easily be solved via caching
> and the deref control though.

But the deref control gives you only one level. Speaking of nested groups in
general people mean more than just two-level group memberships.

Ciao, Michael.