Over the past few weeks, I have been testing OpenLDAP as a backend for
I've been working with the OpenLDAP team on my requirements, and there
has been some really good outcomes - the memberOf module has been
improved, as has the refint module.
However, I seem to have hit a brick wall, in the form of (internal)
transaction support. I need an LDAP backend to support internal
transactions - that is, when for example a 'member' modification is
made, all the memberOf attributes must be updated before the call
returns. Similarly, if a user or group moves, all the member/memberOf
attributes that link the user to their groups must also move, before the
The Samba4 test ldap.js tests this behaviour extensively, because I want
to be sure it works.
As understand the discussion I've had with the OpenLDAP team, OpenLDAP
does not support this, and will not support it for perhaps some time.
Similarly, from discussions with the Fedora DS team at the CIFS
developer days, I understand that it is similarly very unlikely that
Fedora DS will support internal transactions. (It also does not support
subtree renames, which we also need).
The fact that LDAP does not expose a transaction API was always going to
be a difficult part of having Samba4 use an LDAP backend, but I always
assumed that if we pushed the really hard bit - updating linked
attributes - into the LDAP server that we could at least always have a
consistent DB. (It turns out this is one of the primary uses of
But without that consistency, and without knowing as a caller if all the
updates succeed, I'm worried about how we can safely move forward.
This is especially disappointing because I was hoping that these free,
replicating LDAP servers might solve the backed replication problem for
me, without needing to use AD replication.
Does anybody have any ideas or suggestions on how I could get around
Should we drop the LDAP backend as a nice idea, but not going to work,
and focus on DRS or some other form of replication?
Can someone imagine a sane way to reconstruct the DN links, including
subtree renames, without the help of the LDAP backend? Could we ban
subtree renames (as Fedora DS does), and try to handle this ourselves
(with pre/post checks and a good deal of prayer)?
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.