Hi Brian, thanks for the insight. On Fri, 5 Apr 2013, Brian May wrote:
http://mirror.linux.org.au/linux.conf.au/2013/ogv/Samba_4.0.ogv
Thanks, that was really helpful.
In short, AD has a number of requirements on the LDAP server that have never been implemented in openldap or 389, and it seems that they are unlikely to be implemented any time soon (e.g. transaction support among other things). Such features may require major code redesign (if I understand correctly) and upstream weren't at all enthusiastic. So the Samba team had no choice but to implement their own LDAP server.
It is possible to do a single once off import from an existing LDAP server, however running from an existing server is out of the question. As of LCA2013 there were no plans to change this (I doubt this situation has changed).
The Samba 4 team do acknowledge that being able to run against any LDAP server was a feature of previous Samba releases, and the fact this is no longer supported may be a problem for some people.
LDAP is a central directory service in many locations. Here, e.g. I like to use LDAP for Windows AD, a Zimbra mail server, an inhouse web application etc. All of them need schema extentions. Can I maintain them with the Samba server? According to the talk, it does, if I understand it correctly.
Also note that if you can upgrade to Samba 4 without enabling AD, and everything will continue to work as is. I assume this means it will continue to work with your existing LDAP servers until you enable AD support.
I wonder whether there is any certainty for the future..and, of course, it does not allow group policies:-( I understand that Samba 4 is new. There were major changes just few weeks before 4.0, and it creates some uncertainty. Well, it's new, so be it. I hope the dust settles.. What I do not understand is the monolithic design that makes it so hard to understand Samba. That takes the task of copying Microsoft too seriously;-) Samba is at least - a file server - a DNS server - a LDAP server - a NT domain server - a Kerberos server And runs in many roles.. and that's all hidden in one binary? If they would be split, and the communication documented, it would be easier to combine and replace them in a proper "Unix" way, according to needs. At the moment it is more a black box, difficult to understand, that works "somehow" in environments the Samba team can think of. The risk here is to trust Samba, after migration of other LDAP sources that are not the focus of the Samba team. Regards Peter