Re: [ldapext] DBIS - new IETF drafts

Michael Ströder <michael@stroeder.com> Fri, 10 January 2014 19:32 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 B326C1AE0F3 for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 11:32:51 -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 qCfhacRn15tt for <ldapext@ietfa.amsl.com>; Fri, 10 Jan 2014 11:32:49 -0800 (PST)
Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3191AE058 for <ldapext@ietf.org>; Fri, 10 Jan 2014 11:32:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by srv1.stroeder.com (Postfix) with ESMTP id 61A3760818; Fri, 10 Jan 2014 20:32:38 +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 XSjlTDUlyvmH; Fri, 10 Jan 2014 20:32:32 +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 681D86075E; Fri, 10 Jan 2014 19:32:28 +0000 (UTC)
Message-ID: <52D04AC6.4030507@stroeder.com>
Date: Fri, 10 Jan 2014 20:32:22 +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: <52C9BED5.2080900@proseconsulting.co.uk> <52CAEA7D.5030002@highlandsun.com> <1389033674.27654.32.camel@pico.ipa.ssimo.org> <52CB2030.3010403@proseconsulting.co.uk> <52CDA099.9070300@stroeder.com> <1389219912.27654.113.camel@pico.ipa.ssimo.org> <52CEE58C.7060304@stroeder.com> <1389299653.27654.130.camel@pico.ipa.ssimo.org> <52CF0A5C.5090002@stroeder.com> <1389302200.27654.136.camel@pico.ipa.ssimo.org>
In-Reply-To: <1389302200.27654.136.camel@pico.ipa.ssimo.org>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080608080404050907050101"
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: Fri, 10 Jan 2014 19:32:52 -0000

Simo wrote:
> On Thu, 2014-01-09 at 21:45 +0100, Michael Ströder wrote:
>> Simo wrote:
>>> On Thu, 2014-01-09 at 19:08 +0100, Michael Ströder wrote:
>>>> Simo wrote:
>>>>> The full schema definitions can be found here:
>>>>> https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60basev2.ldif
>>>>
>>>> Looked at the schema:
>>>>
>>>> I'm a bit confused by some object classes directly referencing MAY memberOf.
>>>> 'memberOf' is normally an operational attribute also in 389 DS isn't it?
>>>
>>> It is a generated by the memberof plugin, it's semantics are different
>>> from other solutions (like AD), all descendants are resolved at modify
>>> time.
>>
>> Really different semantics?
>>
>> AFAIK memberOf should be a simple back-link from the member's entry to the
>> group entry. When the attribute value is actually created (on modify or on
>> read) is not relevant for memberOf semantics. Or did I get you wrong?
> 
> It is not a backlink in FreeIPA.
> 
> If you have:
> groupA:
>    member: GroupB
> 
> groupB:
>    member: userC
> 
> then userC's memberof is:
> 
> userC:
>   memberOf: groupA
>   memberOf: groupB
> 
> This makes initgroups a lot more efficient as it is a single dereference
> search to get all groups a user directly or indirectly belongs to.

(Sigh!) You took the attribute type NAME and OID from MS AD:

( 1.2.840.113556.1.2.102
  NAME 'memberOf'
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
  NO-USER-MODIFICATION )

But you've changed the semantics. In AD 'memberOf' does not(!) include nested
group membership.

That's really bad practice and makes client developers live really miserable!

Ciao, Michael.