Should we keep the Samba4 LDAP backend?

Andrew Bartlett abartlet at samba.org
Fri Apr 1 03:19:24 MDT 2011


On Fri, 2011-04-01 at 12:55 +0400, Gennady G. Marchenko wrote:
> Andrew!
> 
>     I think  ldap backend in Samba4 must be kept. There are many a 
> priceless features that supported by openldap and users can use it 
> transparently (many type of TRANSPARENT replication, integration of many 
> services (company's internal too) in one LDAP entry and more and more) 
> without changing code of high level application (such as samba4).
> 
> I planned to move all deployed application from smb3->smb4 and I will 
> fail that at all (!) if you remove ldap backend from samba4 :( I don't 
> think I am here alone.

I should be clear, because I think there is some confusion.  There are
some important facts here:
 - The Samba4 LDAP backend never worked.  It looked like it might work,
but there were always problems, things that could not be easily
supported.
 - The Samba4 LDAP backend was unsafe.  Samba4 relies on having
transaction support in it's backend database.  The LDAP backend just
bluffed and ignored that.
 - The Samba4 LDAP backend never used the same schema as Samba3 or
typical LDAP installations, so a direct migration has never been
possible (it uses the AD schema).  Attempts to write mapping backends
between samba3 and Samba4/AD failed (Red Hat made a serious attempt). 
 - Samba4 will always provide it's own LDAP server, as is required to be
an AD server, and will provide that on port 389 as normal.  The LDAP
backend was never directly able to be accessed by clients, so no plan to
use or not use Samba4 should be impacted by this. 

I know OpenLDAP and Fedora DS/389 are great LDAP servers, but they are
not well suited to being AD-like LDAP servers in the modal Samba4 uses
because they don't support key features like AD-interoperable
replication.  

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.



More information about the samba-technical mailing list