Endi's Bug 7530 patches (LDAP backend)

[Andrew Bartlett]

On Mon, 2010-06-28 at 20:41 -0400, Endi Sukma Dewata wrote:
> Hi Andrew,
> 
> ----- "Andrew Bartlett" <abartlet at samba.org> wrote:
> 
> > >     s4/dsdb: Fixed partition_search() not to pass special DN's to
> > LDAP backend.
> > >     s4/auth: Fixed authsam_expand_nested_groups() to find entry SID
> > if not available in the DN.
> 
> > I'm sorry, but both these patches are totally wrong.  Endi's patches are
> > usually very good, but these are based on incorrect starting assumptions. 
> 
> These were meant to be a conversation starter. ;) I didn't expect it to be
> accepted as is.

OK, well it certainly started a conversation :-)

> > The partitions patch will, as I read it, totally break replication, as
> > it will remove the search for @REPLCHANGED from being propagated down to
> > each backend database. (so we know if a particular database needs
> > replication)
> 
> Is this currently working with OpenLDAP? So far I found that this is only
> used by the repl_meta_data module which is only used with the default LDB
> backend. Should repl_meta_data be used with other LDAP backends as well, or
> should Samba rely on the replication feature of each LDAP server?

At the current time, it is assumed that the only replication on LDAP
will be that provided by the LDAP server. 

> If the @REPLCHANGED entry is supposed to be written into LDAP backend, does
> it mean each backend has to map it to a regular LDAP entry (with a regular
> LDAP DN)? Why not just use a regular LDAP entry in the first place and
> define the schema for it?

The @REPLCHANGED is samba-specific (indeed, specific to repl_meta_data
based local ldb), and should not be shown to windows clients.  Indeed,
it should not be searched for against the LDAP backend either (as it is
meaningless there), but the fix was to common code, not to an
ldap-backend specific module.  I think we need to rework this a little
(or handle the errors properly), because we keep breaking this. 

> > The expand_nested_groups patch will work, but I do not wish us to take
> > this approach.  The LDAP backend needs to provide, one way or another,
> > this information - if we start to have fallbacks in the code, we will
> > duplicate the whole extended DN infrastructure in each caller.  The
> > OpenLDAP backend provides this by a server-side module, and either
> > Fedora DS must do the same, or fake it up in a Samba module at the
> > bottom of the stack. 
> 
> Could you point me to the OpenLDAP module that handles this? Thanks!

Yeah, I should have mentioned it, it is the deref module.

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100629/6cf45b6c/attachment.pgp>