Re: OpenLDAP memberof plugin and Samba4

[Pierangelo Masarati <ando@sys-net.it>]

Andrew Bartlett wrote:
> I've been working with current CVS OpenLDAP and the memberof plugin, for
> Samba4 integration. 
> 
> Following your suggestion, I'm trying to load multiple memberof
> instances, but the syntax doesn't seem to work for me.  Attached is how
> I'm currently configuring the overlay.   It causes this when loading:
> 
> overlay_config(): overlay "memberof" already in list
> overlay_config(): overlay "memberof" already in list

That's harmless; It's like that because in principle there might be
overlays that can only be instantiated once, but this now has to be
declared by setting an appropriate flag, which is tested for right after
that message.  So I'm conditioning the message only in case a once-only
overlay is being instantiated multiple times.

> ...
> 
> It also only appears to work for the first entry (happily that is
> member/memberof, and this seems to have worked). 

AFAIR, it should work for all.  However, with the combination of
parameters you specified I've spotted an error: it seems to only work
when __modifying__ a group, not when creating it with an already
existing member.  I'm looking at it, and I'll file an ITS as soon as I
can single out what's the critical combination of parameters.

> 
> Is the syntax I'm using correct, or does the module need to be reworked
> for this operation?

Probably, the module should be reworked in many directions, but not for
what you're trying to do (except fixing the bug I mentioned above).

> Finally, I'm wondering if the error returns can be adjusted:  
> 
> When I add invalid member to a group, OpenLDAP returns
> LDAP_CONSTRAINT_VIOLATION <adding non-existing object as group member>,
> but AD returns error 32, LDAP_NO_SUCH_OBJECT for this situation.  Would
> it be reasonable to change this, or could it be made configurable.
> Having the LDAP server give me the error the client expects would avoid
> the need for a translation layer.  (it might be nobody ever looks at
> this, but I don't like to make that assumption). 

LDAP_CONSTRAINT_VIOLATION was chosen since it correctly expresses what
is the real error: the overlay was configured to be picky on checking
referential integrity, which, to me, is a constraint; LDAP would
otherwise be happy to have broken referential integrity, since that's
the responsibility of the application layer (the overlay in our case).
Returning LDAP_NO_SUCH_OBJECT for an operation (add, modify) whose
object (the request DN) is that of the group, and it exists, would be
rather misleading.  Of course, as the slapo-memberof is an aplication
layer, I don't see a strong objection to making this error configurable,
but I strongly recommend to use LDAP_CONSTRAINT_VIOLATION as default.

p.



Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Email:   pierangelo.masarati@sys-net.it
---------------------------------------