On Mon, 2008-01-14 at 16:59 +0100, Pierangelo Masarati wrote:
Michael Ströder wrote:
Pierangelo Masarati wrote:
Andrew Bartlett wrote:
Samba4's clients are written expecting AD's behaviour, and while I might hope that they would explicitly request the attributes they need, if I can make such mistakes in my test scripts, so can they...
The addition of this feature is (almost) trivial. So the decision should be based on:
- should this "feature" be exposed to all users, or
- should it be exposed only to users using samba4 as proxy?
I think the latter. See, my main scope as a consultant is directory integration/consolidation. So my recommendation is that everything should be avoided which turns an OpenLDAP directory into a special Samba4 LDAP backend which is not usable with other LDAPv3 compliant software anymore.
The fact that we always speak about overlays/modules instead of direct modifications to OpenLDAP should be intended to make sure that OpenLDAP itself does not drift from its route, i.e. becoming as compliant as possible with standard track. In this sense, I believe all modules developed for the sole purpose of downgrading OpenLDAP to behave like AD should clearly carry the indication that they introduce a breach into LDAP specs, and that this breach is intentional for a specific purpose. LDAPv3 client users and developers should be cautioned about relying on those breaches.
How about such an overlay specially treating * based on <who> like defined in ACLs?
I don't think this a viable solution since it appears to require too much effort; moreover, there might not be a practical way to distinguish accesses by samba4 and accesses by other clients.
Indeed - how access control and identity is handled is a matter that will continue to evolve. I would hate to see that made more complected by mixing this into the puzzle.
Or maybe one should recommend in a deployment note to use this overlay with back-ldap?
The deployment note should recommend to avoid using this overlay at all, except for the purpose it was designed. I would recommend to avoid distributing it with OpenLDAP; rather, with samba4 for use with OpenLDAP.
While I don't want to be antagonistic about this, if it becomes a situation where Samba4 has to distribute OpenLDAP overlays (rather than have a reasonable expectation that distributions will pick them up as part of OpenLDAP distributions), I'm worried about the logistics.
How would Samba best go about packaging, maintaining and distributing OpenLDAP overlays? How specific to particular versions of OpenLDAP are overlays, when built as binaries?
Also, how would I as an external package build an overlay against OpenLDAP? Would the normal results of an OpenLDAP installation be enough? (I'm just not familiar with this area).
Fortunately, in this particular case I already handle on the client side (where I prefer to handle most of this). My philosophy is to do as much as possible on the client side, as this will promote interoperability with other directory servers, if and when they want to have Samba4 support as well. But I like to at least ask the question, as the less fiddling I have to do the better.
I also think it could be useful to others in future, as transitions are made from manual to automatic management of some attributes.
Andrew Bartlett