Re: [ldapext] RFC2307, netgroups, DBIS

Michael Ströder <> Wed, 04 February 2015 23:07 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9193F1A0016 for <>; Wed, 4 Feb 2015 15:07:09 -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 k4rKF1pmTdYO for <>; Wed, 4 Feb 2015 15:07:07 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 24E2E1A000D for <>; Wed, 4 Feb 2015 15:07:06 -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 C76901CF77; Thu, 5 Feb 2015 00:07:02 +0100 (CET)
Received: from localhost (localhost []) by srv4.stroeder.local (Postfix) with ESMTP id 74EBA1CE60; Thu, 5 Feb 2015 00:07:00 +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 42iHqsJuhA6A; Thu, 5 Feb 2015 00:06:50 +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 B212B1CE5F; Thu, 5 Feb 2015 00:06:49 +0100 (CET)
Message-ID: <>
Date: Thu, 05 Feb 2015 00:06:48 +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="------------ms090503060706030402070500"
Archived-At: <>
Subject: Re: [ldapext] RFC2307, netgroups, DBIS
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, 04 Feb 2015 23:07:09 -0000

Mark R Bannister wrote:
> wrote:
>> Mark R Bannister wrote:
>>> Agreed, great for access control.  But I don't see how that will work for the
>>> other netgroup use-cases.
>> Which particular netgroup use-cases do you see?
>> One example is sufficient.
> Generically, application roles.  A specific example: sudo, where sudo rules
> are enabled for users based on netgroup membership.  The LDAP server does not
> know the user requesting sudo access, only the client system knows that, so
> server-side ACLs are not going to help.

The server only sees 'sudoRole' entries assigned as visible for its particular
server/host/service group(s). Which particular command a user can execute is
indeed subject to fine-grained control by sudo on the client (based on
attribute 'sudoUser' which with my approach is restricted to only referencing
user groups).

Similar file system permissions/ACLs are evaluated locally, but based on the
limited subset of visible user groups.

> I do need to give a second example, because the first is specific to users. 
> Here is one specific to hosts: NFS, where an NFS server might grant read-only
> access to every host on the network except for those that are members of a
> specific netgroup, which get read-write access.  The NFS server needs to know
> when a client request comes in whether this host is a member of the netgroup
> that grants read-write access or not, and this cannot be implemented by
> server-side ACLs, because only the NFS server knows the identity of the client
> requesting access to the fileshare.

In my model such a NFS client host would be also simply an authenticated
(system) user and member of user groups. The NFS server only sees user groups
assigned as visible for its particular server/host/service group. And
furthermore it only sees the members of those user groups (NFS clients in this

Yes, of course: No IP-based authentication!

> In the deployments I see, typically every user can login to every host, and
> any application could run anywhere, therefore any compromised machine will of
> course yield all NSS data.

Yes. But not with my approach.

> However, the NSS data isn't particularly sensitive anyway,

I disagree.

> and quite often the LDAP directories are open for anyone with a network 
> device to query over port 389 anyway,

Yes in general, but not with my approach. ;-}

> so I haven't worked in an organisation yet where applying server-side ACLs
> to NSS maps would actually be of any practical use.

Well, this system is in production use.  :-)

> What was the use-case you saw for it?

Role separation with separate credentials (especially passwords for sudo
access), and paranoid protection of information I consider sensitive because
it could be used to plan next steps (e.g. social engineering).

And furthermore you can keep the client configuration and map evaluation very
simple because the visibility of users and user groups is constrained by
access control based on server/host/service group membership of the NSS client.

Ciao, Michael.