Re: [ldapext] RFC2307, netgroups, DBIS

Michael Ströder <> Wed, 11 February 2015 12:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 312AB1A8856 for <>; Wed, 11 Feb 2015 04:35:44 -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 6r03mnp99gMr for <>; Wed, 11 Feb 2015 04:35:41 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E60211A885E for <>; Wed, 11 Feb 2015 04:35:40 -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 00E9A1CF9B; Wed, 11 Feb 2015 12:35:37 +0000 (UTC)
Received: from localhost (localhost []) by srv4.stroeder.local (Postfix) with ESMTP id 93FF41D2A1; Wed, 11 Feb 2015 12:35:35 +0000 (UTC)
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 t6miwqBE0oZR; Wed, 11 Feb 2015 12:35:22 +0000 (UTC)
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 BB65B1CFB5; Wed, 11 Feb 2015 12:35:21 +0000 (UTC)
Message-ID: <>
Date: Wed, 11 Feb 2015 13:35:20 +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.1
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="------------ms010401070401070008080102"
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, 11 Feb 2015 12:35:44 -0000

Mark R Bannister wrote:
> On 04/02/2015 23:06, Michael Ströder wrote:
>> 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).
> So you've come up with a point solution for 'sudo' that would replace the
> need for sudo to use netgroups,

No, it's generally applicable.

> to have its own authenticated user account is not practical in an
> enterprise environment with 80,000 user accounts already and 60,000 hosts.

It is indeed practical. BTW: This is basically what's already done when adding
servers and workstations in MS AD with Kerberos used as authc mech.

> NFSv4 has already solved the NFS authentication problem, and that requires 
> nothing more than the user who attempts to access the files having a valid
> Kerberos ticket.

AFAICS it also requires the servers to have a Kerberos keytab with their
service principal's key(s).  Others with more in-depth Kerberos knowledge
might elaborate on that.  So this model fits my approach quite nicely. :-)

>>> 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.
> Why not?  If everyone can login everywhere, your approach solves nothing? 
> [..]
>>> However, the NSS data isn't particularly sensitive anyway,
>> I disagree.
> If everyone can login everywhere, what NSS data is sensitive?

Your assumption that "everyone can login everywhere" is wrong.

>>> 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).
> So what if I login one of your hosts and type 'getent passwd'.  What will I
> see?  Enough data to do some social engineering?

If you are root on a system you will see this partial directory data to do
social engineering:

1. getent group: the user groups assigned as visible for this server group

2. getent passwd: all member users of the visible user groups (see 1.).

3. sudo -l: You can discover who can use which sudoers rules visible for this
server group

Admins with access to very sensitive systems are adviced to have separate
accounts (role separation).

>> 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.
> At the cost of added complexity,

But the complexity is implemented *centrally* at the LDAP server's side.
Furthermore the server-side visibility rules are even then enforced when a NSS
client got hacked and re-configured by an attacker.

Which both is a huge gain over having to tweak *all* PAM/NSS clients to do the
right thing.

Note that only LDAP entries are added/modified.  The ACLs working their way
through the references are *static* configuration.

> a false sense of security unless you are very careful how you design who
> can login to which hosts, and at best you've just shifted the target point 
> for hackers to the LDAP servers instead.

Yes, similar like DBIS this is a frame-work.  The responsible system admins
have to be sufficiently eager to make use of the authorization mechanisms
provided.  The admins have to carefully craft an access control policy by
defining server groups and their relationship to user groups and sudo rules, etc.

Admins who just want an easy one-size-fits-it-all security policy are
definitely not the target audience of any serious access control scheme (and
IMHO should be kicked out of business in the long run).

Ciao, Michael.