We certainly appreciate the bind that the LDAP server situation puts our administrators in. We went to great lengths to try and avoid this, but were unable to make it work, while also supporting features such as DRS replication, and many of the finer points of AD's LDAP server. As I've said elsewhere, the biggest killer for the feature was the need for runtime schema translation, or for the administrator to load the AD schema and layout on their external LDAP server (which rather defeats the purpose).
The there are three ways out of this difficult situation
- continue to use Samba as a 'classic' domain controller as-is using smbd/nmbd (this code remains and remains supported).
- Add schema extensions to our LDAP server (disabled by default, but supported), and cope with the AD-specified layout restrictions.
- Somehow sync Samba with an existing LDAP server.
I'm not a fan of synchronisation of directories - just that I prefer a single canonical store rather than the complexity of synchronisation, but it certainly may be an option in some situations.
I certainly agree that it appears quite rude, on the face of it, to step up from being an equal partner in the unix-LDAP ecosystem supporting a number of different directory servers to demanding that everyone else use only our internal server. I do wish it didn't have to be this way, and I've left in (with tests) as much of the code we used for the LDAP backend experiment as is possible, in case somehow someone builds a workable use case in the future.