Hi all, I just play around with Samba 4. At the moment, there is no official support for external LDAP (e.g. OpenLDAP). My original understanding was: We want Samba 4 "out" as fast as possible so we concentrate on "core functionality" (e.g. using internal LDAP, DNS etc.), and look at issues related to external sources later. Yesterday I found this: ---- http://us.generation-nt.com/re-samba-windows-8-pro-no-domain-logon-possible-... (20th Sep 2012) We spent considerable effort over a period of years in attempting to make this possible. It is not. Even if it was, it would not involve 'simply' reading the companies LDAP server, it would be a very intrusive change no more acceptable than using our own built-in LDAP server. Andrew Bartlett ---- I wonder whether it means: Samba will not use external LDAP at all (that would rule it out for me here) "Very intrusive changes".. to Samba or LDAP? Does anybody has insight of the "roadmap", especially about the future of external LDAP sources? I know that you can make it work, somehow, now. But if it does not have support by the Samba team it will be fiddly and fragile and you have to worry about future releases all the time. I am not really keen on that. Regards Peter
On 5 April 2013 08:51, Peter <Petros.Listig@fdrive.com.au> wrote:
I wonder whether it means: Samba will not use external LDAP at all (that would rule it out for me here)
"Very intrusive changes".. to Samba or LDAP?
Does anybody has insight of the "roadmap", especially about the future of external LDAP sources?
I know that you can make it work, somehow, now. But if it does not have support by the Samba team it will be fiddly and fragile and you have to worry about future releases all the time. I am not really keen on that.
I guess you missed Andrew Bartlett's talk on Samba 4 at LUV. While he did give a talk at LCA2013, he addressed your questions more in the LUV talk (going from memory here). http://mirror.linux.org.au/linux.conf.au/2013/ogv/Samba_4.0.ogv 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. 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. This is from my recollection of the LUV talk. -- Brian May <brian@microcomaustralia.com.au>
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
/* Mea culpa, catching up on almost 1,000 unread emails on luv-main */ On Fri, 5 Apr 2013 09:16:23 AM Brian May wrote:
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.
Here are Andrew Bartlett's own words on this in a response to a query on LWN after Samba 4's release: https://lwn.net/Articles/529321/ # 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. it's worth reading the full comment for more on the background. All the best, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC This email may come with a PGP signature as a file. Do not panic. For more info see: http://en.wikipedia.org/wiki/OpenPGP
participants (3)
-
Brian May -
Chris Samuel -
Peter