Re: RFC2307, netgroups, DBIS

Michael Ströder <[email protected]> Thu, 05 Feb 2015 00:18:55 +0100
Newsgroups gmane.ietf.ldapext
Message-ID <[email protected]>
Mark R Bannister wrote:
> [email protected] 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.

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

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

> Strange appliances - not unless I can get the vendor to add support for DBIS.

And that is exactly the point.

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

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

> But you still have an old schema to support

What the client sees is fully compatible to RFC2307(bis) and sudo-ldap schema.

> that wasn't fully NIS compatible to begin with ...

I don't care about full NIS feature set. I've replaced it with something
different. ;-)

Ciao, Michael.

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext
smime.p7s (application/pkcs7-signature, 4.2 KB) - not displayed