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