Re: [ldapext] RFC2307, netgroups, DBIS

Mark R Bannister <> Wed, 11 February 2015 12:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2372F1A06FD for <>; Wed, 11 Feb 2015 04:11:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.101
X-Spam-Level: *
X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HJoirOC5V2Xd for <>; Wed, 11 Feb 2015 04:11:18 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A31E51A0181 for <>; Wed, 11 Feb 2015 04:11:17 -0800 (PST)
Received: from ([] helo=[]) by with esmtpa (Exim 4.71) (envelope-from <>) id 1YLW8S-0006gA-57; Wed, 11 Feb 2015 12:11:16 +0000
Message-ID: <>
Date: Wed, 11 Feb 2015 12:11:12 +0000
From: Mark R Bannister <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: =?windows-1252?Q?Michael_Str=F6der?= <>
References: <etPan.54c553b0.19e21bb2.1f2@lpm.local> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------010008040507020809090906"
X-Mailcore-Auth: 12040446
X-Mailcore-Domain: 1286164
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:11:21 -0000

On 04/02/2015 23:18, Michael Ströder wrote:
> Mark R Bannister wrote:
>> wrote:
>>> Mark R Bannister wrote:
>>>> On 28/01/2015 14:14, Simo wrote:
>>>>> It hurts me to curb enthusiasm, but I think your drafts are not a step
>>>>> forward, at most a step sideways, and ignore what's out there right now.
>>>> Given that they were written to fix specific deficiencies in RFC2307bis
>>>> that were causing pain in a number of very large enterprises I have worked
>>>> for, I don't see how they could be considered a step sideways.
>>> Maybe I did not look closely enough. Could you please point me to some text
>>> describing the specific deficiencies you solved in more detail?
>> Have at look at the abstract on page 2 of
>>  One of the first
>> biggest requirements was reintroducing case sensitivity in a way that would be
>> fully compatible with NIS, see the description of the en (4.2) and rn (4.3)
>> attributes in particular.
> Yes, case-sensitive matching is an issue and I already saw that text in your
> drafts. I've simply added additional local constraints to the config limiting
> e.g. attribute 'uid' to lower-case values. So it was not that important to me.

"Not that important to me" suggests, once again, that you are coming up 
with a point solution,
and not a solution that could be widely adopted.  I have designed a 
replacement for an RFC
that can be very widely adopted.  Your approach to the 'uid' attribute 
precludes any other
use of this attribute within the same directory server by other 
applications and is not

>> Also, another requirement was to fix the schema so
>> that duplicate alias names could be easily detected and prevented (1.2).
> Are you talking about this text?
> Frankly I don't get it (besides the SHALL for LDAP client configuration).

As in

>> Legacy unices ... depends how old we're talking.  I currently have something
>> that works on RHEL4.8 and newer, and the large organisations I have spent most
>> of my time with over the past 5 years are at a point where RHEL4.8 is their
>> oldest legacy now.
> That's pretty old right now.

Indeed it is, and DBIS will run on them.  So I am supporting legacy unices.

>> Strange appliances - not unless I can get the vendor to add support for DBIS.
> And that is exactly the point.

That is no different with any new technology.  As uptake spreads, and 
customer demands increase, vendors
add support for the new stuff.  As DBIS works with the old 
RFC2307/RFC2307bis schema as well, customers
can begin to use DBIS right away on the unices that they have control 
over, while the appliances can
continue to use the same data the old way.  Then the pressure increases 
on those vendors and over time
they move to the new way too.  Change has to start somewhere.

>> However, even the appliances I've worked with support local class & attribute
>> remapping rules,
> Unfortunately there are counter examples where you cannot configure local
> class & attribute remapping rules.

Fine, then in those cases you use the RFC2307 schema and the new DBIS 
clients you install can be
configured to use it with no trouble:

>>> My approach is to lower the configuration level the client has to support by
>>> filtering what's delivered to the client at the LDAP server.
>> By filtering, you mean just removing entries from maps?
> Yes, making users, user groups and sudoers entries invisible if the client is
> not authorized to see them.

You could do that with DBIS too, if you wanted.  You could either use 
netgroup constraints 
<> (client-side),
and if you really want server-side restrictions in place, split the maps 
up into separate places in the DIT
and use ACLs to restrict which hosts can see them.  Don't forget that 
DBIS can join entries from many
different places in a DIT into a single coherent map, and it uses 
netgroups to determine which hosts
should get which pieces of the map.

Best regards,