Samba 4.0 Released: the First Free Software Active Directory Compatible Server 343
Jeremy Allison - Sam writes "We released Samba 4.0 today, containing the first compatible Free Software implementation of Microsoft's Active Directory protocols. 'Samba 4.0 comprises an LDAP directory server, Heimdal Kerberos authentication server, a secure Dynamic DNS server, and implementations of all necessary remote procedure calls for Active Directory. Samba 4.0 provides everything needed to serve as an Active Directory Compatible Domain Controller for all versions of Microsoft Windows clients currently supported by Microsoft, including the recently released Windows 8. The Samba 4.0 Active Directory Compatible Server provides support for features such as Group Policy, Roaming Profiles, Windows Administration tools and integrates with Microsoft Exchange and Free Software compatible services such as OpenChange.'"
Full release notes are available, and you grab the files from the download page.
Re:If only it were samba-ng (Score:3, Informative)
Gates is forked.
This will be embeddable on ARM appliances, and baked into VM management software, etc.
It only took 12 years... :-)
Re:What's new? (Score:5, Informative)
Re:How does Microsoft feel about this? (Score:5, Informative)
Microsoft provided them with documentation and helped them with interoperability testing. From TFA:
The Samba 4.0 Active Directory Compatible Server was created with help from the official protocol documentation published by Microsoft Corporation and the Samba Team would like acknowledge the documentation help and interoperability testing by Microsoft engineers that made our implementation interoperable.
"Active Directory is a mainstay of enterprise IT environments, and Microsoft is committed to support for interoperability across platforms," said Thomas Pfenning, director of development, Windows Server. "We are pleased that the documentation and interoperability labs that Microsoft has provided have been key in the development of the Samba 4.0 Active Directory functionality."
Re:How does Microsoft feel about this? (Score:5, Informative)
Ahem. Microsoft provided a positive quote for the press release, and were involved in bug fixing to ensure interoperability.
So no, I don't think they hate it :-).
Jeremy.
Microsoft helped (Score:5, Informative)
The EU is still a bit angry at Microsoft (remember when they had to release all of the documentation on their implementation of the SMB protocol?) and they don't need to be stoking that flame.
Re:Administrative UI (Score:5, Informative)
Yes :-). That's why you can use the Windows tools to administer Samba4.0 AD server :-).
Jeremy.
Re:No more licensing fees :) (Score:5, Informative)
Re:No more licensing fees :) (Score:5, Informative)
Spoken like someone who has NEVER done SQL development. SQL most definitely is not SQL, it's a world full of vendor specific dialects of SQL, each varying in subtle and incompatible ways. Not to mention each requires a different method of connection, protocol, authentication and integration.
Re:How does Microsoft feel about this? (Score:5, Informative)
Of course what you failed to mention is that Microsoft only did this because the European Commission forced them to [samba.org]:
Re:How does Microsoft feel about this? (Score:4, Informative)
Wasn't Microsoft *required* by a court judgement or two to provide documentation and interoperability for several of their protocols? I don't think this was entirely out of the goodness of their hearts
See the heading "February 2008 fine" here: http://en.wikipedia.org/wiki/Microsoft_litigation [wikipedia.org]
Re:No more licensing fees :) (Score:5, Informative)
ODBC? JDBC?
Neither of these normalize vendor specific dialects. Both of these require vendor specific drivers to implement vendor protocols. All of this leads to costly subtleties.
The grandparent is correct, both in its assertions about SQL and of you.
Re:How does Microsoft feel about this? (Score:5, Informative)
The SAMBA team said they received a lot of insight and understanding from their time with the MS engineers and were impressed and excited.
I'm not sure Microsoft is too concerned about SAMBA 4 being released.
Re:How does Microsoft feel about this? (Score:5, Informative)
From the Groklaw article, the documentation for active directory was sold to the Samba project. The Samba project then went about using the documentation as a reference. Microsoft did not want to sell this documentation to the Samba project and were required to do so under court order. So no. They weren't all that willing to help out.
And if Microsoft starts playing "undocumented features" games again to break compatibility, they will find themselves in court again.
Re:I wouldn't jump the gun just yet (Score:5, Informative)
Samba 3+OpenLDAP+Heimdal Kerberos created what were often termed "Open Directory Services" by the Apple Crowd. They were mutant NT 4.0 Domains that had broken a bunch of the limitations of NT4, (such as multiple PDCs and levels of trusts.) provided LDAP and Kerberos, but to Windows, they were still just NT Domains to Windows. Not true ADs. XP and 2000 would disable Kerberos because it thought it was talking to NT4. Windows 7 dropped support for NT4 EXCEPT there was a special mode just for Samba 3 to work, and you had to edit the registry to get it working.
Re:How does Microsoft feel about this? (Score:5, Informative)
There isn't a court-ordered requirement for them to test it. There's a market enforced requirement :-).
Go into Frys (or local Geek store). Look at all the NAS boxes on the shelf. That's all Samba. Every one.
Now imagine you're Microsoft. A new version of Windows comes out and it doesn't work against all the "home NAS media servers" people have. Ooops :-(.
They test against Samba *all the time*, as it's good for their business to do so.
They also go a little above and beyond by helping test the AD server part of Samba (which isn't in wide production use yet) - they do that in their interop labs up in Redmond.
They provide free food for the engineers working late up there. It's not as good as the free Google food (but then again, hey - what is ? :-) :-).
Jeremy.
Re:GPLv3 (Score:5, Informative)
Yes, I'm Jeremy Allison - the original poster. I created Samba along with tridge (he was there first, and is much smarter than me though :-). I thought that was obvious, sorry :-).
Jeremy.
Re:No more licensing fees :) (Score:5, Informative)
MySQL is utter crap. It's not a replacement for MS SQL, it's not a replacement for any decent SQL server. It took those bozos YEARS to finally get MySQL to not recognize Feb 31st as a valid date.
PostgreSQL is a potential replacement, but certainly not a drop-in replacement. Lots and lots of work would need to be done to convert between the different lingo's they speak and way features are implemented.
Re:No more licensing fees :) (Score:5, Informative)
Just as long as you don't have to create a table, add any sort of triggers, or do anything interesting like automatic time stamping on modification/creation, choosing a random n entries out of the matches without shipping the entire huge set over a slow network, etc., then yes. As soon as you have to do something even slightly nontrivial, the difference between SQL dialects becomes the tenth circle of hell.
Existing OpenLDAP setups (Score:5, Informative)
I agree, existing OpenLDAP sites using Samba 3.x in cooperation with a host of other packages, using the traditional LDAP directory structure deployed on many Linux oriented sites are not going to migrate to Samba 4.0 as an AD DC any time soon. The change is just as big as the change to migrate to Microsoft's Active Directory, except that we provide a tested upgrade tool to handle the Samba-essential parts.
We want this to be easier, and the tools can certainly be extended to cover other schema items, and integration of these services can improve, because many of these can work well against a Microsoft Windows AD. However, we know this is a big leap, so we continue to support existing configurations (with the existing features. (For want of a better term, we call it a 'classic' domain).
The issue isn't as much being unable to use an LDAP server as a data store (but this became more difficult as we became more like AD), as that unless we were to implement on the fly schema translation, most of the same issues would remain (assumptions about AD or traditional schema and layout between Samba and the other tools on the LDAP backend), and so the result would not have be useful anyway!
As such, the LDAP backend has been put aside as an interesting technical modal that didn't work out. If a plausible use case ever comes up, then interested developers might revive some of it (the code and some tests remain where they are not impeding development), but for now there are no plans for support of anything other than local LDB files and native replication with other AD servers.
Andrew Bartlett
Samba Team
Re:No more licensing fees :) (Score:5, Informative)
My anecdote: 5 years ago we were a 95% Windows shop with only 15 Linux servers. Today we are a 90% Linux shop with near 1000 Linux servers. We went from 5 Windows Admins and 1 Linux admin to 6 Linux admins and 3 Windows Admins. Yet we are unlikely to convert AD to this for the exact same reasons. It's not just AD it's the plugins to AD the monitoring and the fact that, while it rarely breaks anyway, if something does break the amount of repair tools and articles on how to fix it are numerous. As that original 1 Linux admin I would like to see this as an option. But it's not very likely.
Samba 4.0 vs 'classic' NT4 like domains on LDAP (Score:4, Informative)
Indeed, it was seeing the limitations of the NT4 modal that held back these domains that was one of the major reasons I started on the AD DC effort for Samba. I deployed (and indeed was involved in the creation of) a mixed Heimdal/Samba/LDAP domain, and saw how the lack of Group Policy caused real issues for a large network of Windows PCs. In my specialist area of Authentication, I also saw how NTLM authentication did and did not work, particularly in the load it put on the DCs. Kerberos is a much better authentication prototcol than NTLM, and I'm glad that Samba now not only can accept Kerberos authentication, but as the Domain Controller, it can now be the KDC too!
In the same way, I saw the writing on the wall for NT4 support for a long time, and I'm just very glad that the interoperability environment changed enough in time that we were able to get changes made to Samba and Windows to allow Samba NT4-like 'classic' domains to continue, long past when NT4 DCs became not only unsupported, but deliberately broken (in the name of increased security). As you mention it still requires a registry patch however, and so with the release of Samba 4.0 as an AD DC I look forward to Samba administrators being able to deploy a 'just works' solution again, even for the latest windows versions.
Andrew Bartlett
Samba Team
Re:If only it were samba-tng (Score:5, Informative)
The AD DC is actually is a bunch of core libraries and services. To make things easiest for our users, the services are linked into and started up by one binary, but internally each different task ends up in a forked process (if appropriate). But we do one better, and allow this to be controlled at runtime, so with '-M single' it essentially becomes a giant state machine, and can be handled with a single gdb. Inter-process communication is via a unix domain socket based messaging system or full DCE/RPC pipes.
External processes can register specific named pipes (when, as we do by default, we use smbd as the file server, this is actually a key part of the design), or DCE/RPC server modules can be loaded (the OpenChange project provides such a module).
We could discuss if more or less of Samba's internal communication should use one design pattern or another, but what is more interesting is that without fanfare or bother, some of those ideas, implemented pragmatically rather than dogmatically, have become an essential part of how Samba is implemented. That pragmatism has then brought us the AD DC that we are so proud to announce today.
I also love that the shared libraries that we now use internally make Samba much smaller as well, reducing the disk space overhead.
Finally, a surprising amount of the code is actually in modules on ldb, our ldap-like database at the core of the system.
I know you were hoping to troll with what has been a long-running design philosophy, but when you spend the time building the system, you find the pragmatism rules the day, and we use a variety of tools to get the job done, and to get it done is a way that is most seamless to our users.
Andrew Bartlett
Samba Team