Re: [ldapext] RFC2307, netgroups, DBIS

[Michael Ströder <[e-mail]>]

Mark R Bannister wrote:
> On 04/02/2015 23:18, Michael Ströder wrote:
>> Mark R Bannister wrote:
>>> [e-mail] 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
>>> http://www.ietf.org/id/draft-bannister-dbis-mapping-06.txt.  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.

Not right. I simply have other priorities leading to another compromise.

> I have designed a replacement for an RFC that can be very widely adopted.

As already pointed out:
Your approach is not backward compatible to PAM/NSS clients making hard-coded
use of RFC 2307 schema.  I have some doubts that it will be widely used.

> Your approach to the 'uid' attribute precludes any other use of this
> attribute within the same directory server by other applications and is
> not standards-compliant.

Could you please elaborate why defining local constraints is "not
standards-compliant".  I'm really eager to learn more about standards. ;-)

Since you tend to solve things at the client side you could easily configure
PAM/NSS clients to use an extensible LDAP filter using case-sensitive matching
rule for searching users and groups by their name.

>>> 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?
>>
>> https://tools.ietf.org/html/draft-bannister-dbis-mapping-00#section-1.2
>>
>> Frankly I don't get it (besides the SHALL for LDAP client configuration).
> 
> As in http://sourceforge.net/p/dbis/wiki/Aliases.

I know what LDAP alias entries are but I avoid using them.  I suspect that you
try to cure a problem caused by using a specific search base in your PAM/NSS
client configuration.  The approach is simply wrong.

Instead I'd say fix your data and keep client config simple. ;-)

>>> 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.

Good luck.

>> 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 <http://sourceforge.net/p/dbis/wiki/Netgroup%20Constraints/>
> (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.

Your schema is not suitable to let *static* LDAP server ACLs work their way
through the data.

Ciao, Michael.