Re: [ldapext] LDAP work at IETF...

Michael Ströder <> Wed, 28 January 2015 17:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AEA961A6EF9 for <>; Wed, 28 Jan 2015 09:51:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.312
X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qtLo4VP4KQUY for <>; Wed, 28 Jan 2015 09:51:56 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB1E01A6EE6 for <>; Wed, 28 Jan 2015 09:51:55 -0800 (PST)
Received: from srv4.stroeder.local (srv4.stroeder.local []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer " Server CA no. 2009-07" (not verified)) by (Postfix) with ESMTPS id 0D8681CF98; Wed, 28 Jan 2015 18:51:51 +0100 (CET)
Received: from localhost (localhost []) by srv4.stroeder.local (Postfix) with ESMTP id 2D6BB1DFA9; Wed, 28 Jan 2015 18:51:50 +0100 (CET)
X-Virus-Scanned: amavisd-new at stroeder.local
Received: from srv4.stroeder.local ([]) by localhost (srv4.stroeder.local []) (amavisd-new, port 10024) with ESMTP id 64h3vqYkEvRS; Wed, 28 Jan 2015 18:51:41 +0100 (CET)
Received: from nb2.stroeder.local (nb2.stroeder.local []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by srv4.stroeder.local (Postfix) with ESMTPS id 1A6AC1DE04; Wed, 28 Jan 2015 18:51:40 +0100 (CET)
Message-ID: <>
Date: Wed, 28 Jan 2015 18:51:39 +0100
From: =?UTF-8?Q?Michael_Str=c3=b6der?= <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:35.0) Gecko/20100101 SeaMonkey/2.32
MIME-Version: 1.0
To: Mark R Bannister <>,
References: <etPan.54c553b0.19e21bb2.1f2@lpm.local> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050509060105030005050407"
Archived-At: <>
Subject: Re: [ldapext] LDAP work at IETF...
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: Wed, 28 Jan 2015 17:51:58 -0000

Mark R Bannister wrote:
> On 27/01/2015 22:14, Michael Ströder wrote:
>>> I think if people
>>> started looking deeper into the DBIS internet drafts,
>> I've looked into your drafts. But it differs very much from what I'm after. We
>> had this discussion before: IMO netgroups must die, die, die...
> This contradicts your earlier assertion that clients are hard-coded.  In the
> same vein, clients are hard-coded to use netgroups, ergo netgroups cannot
> "die, die, die".

No contradiction, since IMO one can easily avoid using netgroups completely.

With my approach the ACLs on the LDAP server sort out what clients can
actually see. Therefore you get the flexible access control without the client
having to enforce e.g. login access control locally based on netgroups.

> Rather than attempting to kill off something that is used extensively, and has
> actually proved to be very useful in large UNIX/Linux estates (if a bit
> clunky), I've embraced them, rationalised them, defined them in a neater and
> queryable format, and complemented them with netservices.

I'd avoid them and convert access control rules based on netgroups into
another schema and let the LDAP server's ACL work through the data.

> Apart from netgroups, which you are not a fan of, how else does DBIS differ
> from what you're after?

My main objective is that not the client system evaluates all the stuff. The
client system should not see data not usable on the system. The client system
acts as a dumb RFC2307(bis) and sudo-ldap client. Of course the client system
still enforces file access permissions etc. locally.

Ciao, Michael.