Re: [ldapext] DBIS - new IETF drafts

Michael Ströder <michael@stroeder.com> Thu, 09 January 2014 15:56 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 8D9CD1AE42A for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 07:56:17 -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 3Y-AF2JMviUS for <ldapext@ietfa.amsl.com>; Thu, 9 Jan 2014 07:56:11 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id A666F1AE417 for <ldapext@ietf.org>; Thu, 9 Jan 2014 07:56:10 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id AEEC16076E; Thu, 9 Jan 2014 16:56:00 +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 iyHrN2CXsWv1; Thu, 9 Jan 2014 16:55:52 +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 A58726076D; Thu, 9 Jan 2014 15:55:44 +0000 (UTC)
Message-ID: <52CEC4D5.1070703@stroeder.com>
Date: Thu, 09 Jan 2014 16:48:37 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <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: Mark R Bannister <dbis@proseconsulting.co.uk>, ldapext@ietf.org
References: <1389133522.4574.30.camel@sorbet.thuis.net> <52CDBFD2.10905@proseconsulting.co.uk>
In-Reply-To: <52CDBFD2.10905@proseconsulting.co.uk>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040401000806020808020206"
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 15:56:17 -0000

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.

> It seemed quite strange to me that
> RFC2307 should have differed like this from NIS in the first place.

We all agree that RFC 2307 - even though widely deployed - has serious issues.

> Yes this was another aspect I wanted to simplify.  RFC2307bis does not make it
> easy to express group membership.

What does "express group membership" mean exactly?

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

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

Also nested groups are a pain if you want to report all effective user rights
to auditors (which is something banks have to do at least once per year). In
this context even maintaining the group membership does not look that simple
anymore.

Ciao, Michael.