Re: [ldapext] DBIS - new IETF drafts

Michael Ströder <> Thu, 09 January 2014 15:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 24F8F1AE413 for <>; Thu, 9 Jan 2014 07:56:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.839
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BIwLhPrCYBt8 for <>; Thu, 9 Jan 2014 07:56:09 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0EAB21AE412 for <>; Thu, 9 Jan 2014 07:56:09 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id DAAF360771; Thu, 9 Jan 2014 16:55:58 +0100 (CET)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 60Z-ycNNeuxu; Thu, 9 Jan 2014 16:55:49 +0100 (CET)
Received: from [] (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "Michael Str??der", Issuer "CA Cert Signing Authority" (verified OK)) by (Postfix) with ESMTPS id 9808B60776; Thu, 9 Jan 2014 15:55:42 +0000 (UTC)
Message-ID: <>
Date: Thu, 09 Jan 2014 16:35:56 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <>
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 <>,
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020909030708050209030601"
Subject: Re: [ldapext] DBIS - new IETF drafts
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: Thu, 09 Jan 2014 15:56:11 -0000

Mark R Bannister wrote:
> On 08/01/2014 18:57, Michael Ströder wrote:
>> Arthur de Jong wrote:
>>> I personally like the use of flat names to describe group membership. It
>>> makes the semantics much simpler than dealing with things like the
>>> member or uniqueMember attribute (at least from a client implementation
>>> perspective).
>>> The use of distinguished names may seem more logical from an LDAP
>>> structure point of view, but you will have to dereference any DN to a
>>> user name for building up a group entry resulting in potentially a lot
>>> of search operations to get complete data.
>> Using DNs allows to implement server-side access control. I'm not a friend of
>> letting client-side demons enforce the access control because if a machine got
>> hacked the attacker can find out more about the infrastructure.
> Please will you give me a more solid example of what you are referring to re
> access control?  What is it exactly you think you'd like to do with regards to
> group membership and server-side access control?

If the client system *individually* binds to the LDAP server you can implement
server-side access control in the LDAP server. During the last weeks I defined
a schema and OpenLDAP ACLs for such a deployment. Nothing to publish yet since
this is done for a customer.

Similar to what Simo described for IPA I use server groups (IPA host groups)
with rights assigned to user groups.

In opposite to all other implementations all clients MUST individually bind to
the LDAP server and server-side ACLs limit access to posixAccount, posixGroup,
server group and sudoRole entries.

I have to clarify if I'm allowed to disclose further details about this which
will take a while.

Ciao, Michael.