| |||||||||||||
Samba 4.0 releasedSamba 4.0 releasedPosted Dec 16, 2012 7:42 UTC (Sun) by aristedes (guest, #35729)Parent article: Samba 4.0 released
I've spent some time with this release already and it is very very nice. One caveat is the way that LDAP is now integrated within Samba and there is no support for using an external LDAP service instead.
I understand this was probably done for good technical reasons, but it creates a wall between Samba and the rest of a well behaved Unix eco-system. It may be possible, I've not yet found a way to integrate the Samba user directory with other LDAP extensions (such as what you might use for netatalk).
Part of the problem here might be that I understand LDAP very well and don't have my head wrapped around Active Directory. It does appear that Samba 3 tried to bring a Unix sensibility to configuration and integration; now Samba 4 has much better integration with Microsoft tools, but seems more foreign to the Unix side of things.
(Log in to post comments)
Samba 4.0 released Posted Dec 16, 2012 15:41 UTC (Sun) by anselm (subscriber, #2796) [Link] The Univention company has a tool that will apparently do bi-directional sync between OpenLDAP and Samba 4's LDAP (or indeed Microsoft AD). I haven't actually tried it myself but it is one of the more touted components of their Univention Corporate Server (UCS) product so it probably works. The code is available under the AGPL from http://forge.univention.org/websvn. It isn't exactly documented very well but considering that Univention would rather have you buy UCS that's probably understandable in a way.
Samba 4.0 and LDAP Backends Posted Dec 17, 2012 0:39 UTC (Mon) by abartlet (✭ supporter ✭, #3928) [Link]
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
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.
Andrew Bartlett
|
|||||||||||||