Endi's Bug 7530 patches (LDAP backend)

[Endi Sukma Dewata]

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.

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

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

--
Endi S. Dewata