Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Software Microsoft Networking Windows Linux

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.
This discussion has been archived. No new comments can be posted.

Samba 4.0 Released: the First Free Software Active Directory Compatible Server

Comments Filter:
  • by somersault ( 912633 ) on Tuesday December 11, 2012 @04:10PM (#42253617) Homepage Journal

    Oh hell yes

  • by gstoddart ( 321705 ) on Tuesday December 11, 2012 @04:21PM (#42253703) Homepage

    I'm assuming if Microsoft could legally stop this, they would.

    Likely the interfaces aren't copyrightable and this is probably a clean implementation -- but I'm sure if Microsoft could trot out a patent or something else to stop people they would.

    I can't imagine they want implementations of their stuff out there. (Granted, they mostly started out by implementing other people's stuff, so there may not be much they can do about it.)

  • by somersault ( 912633 ) on Tuesday December 11, 2012 @04:41PM (#42253871) Homepage Journal

    I already have loads of client licenses, but this means no more server licensing, so it will be significantly cheaper for small businesses to build a small network with full redundancy, and massively cheaper to build out large networks. Get this onto Ubuntu Server with a friendly interface, and MS will be close to dead in the water as far as servers go.

  • by Xtifr ( 1323 ) on Tuesday December 11, 2012 @04:44PM (#42253897) Homepage

    Really? I was about to post a snarky reply when I noticed the name and the low-enough-to-be-convincing slashdot ID, so I'll make it more of a simple question.:Given that Microsoft was required to publish the documentation by the EU, and the fact that this basically proves they did comply with the courts orders, can you really be sure they don't hate it? Sure, it gets them off the hook, which is reason enough for them to have helped with the effort, but they can still hate it.

  • by Jeremy Allison - Sam ( 8157 ) on Tuesday December 11, 2012 @04:52PM (#42253975) Homepage

    Possibly their marketing and senior exec's hate it (although I doubt that - Thomas Pfenning is at director level in the Windows org and he think's it's pretty cool.

    But I know their engineers think it's cool :-).

    Jeremy.

  • by aquarajustin ( 1070708 ) on Tuesday December 11, 2012 @05:30PM (#42254319)
    This is why I don't work for a PHB. In fact, he's balding a bit. I have the best boss ever. He just gave me the green light to be early adopters and run this in production (once it passes a few sanity checks). We've been running the alphas and betas with much success. Samba team ftw!! Thanks guys! I've been waiting for this for so long.
  • by Bill Dimm ( 463823 ) on Tuesday December 11, 2012 @05:35PM (#42254373) Homepage

    Why would you be adding/dropping fields outside of installation/upgrading?

    I'm not sure whether you intend "you" in the above to mean the person who wrote the "accounts software" referenced at the beginning of this thread, or me personally. My personal experience was with writing document clustering software (groups related documents together based on analysis of the content) that could analyze the text stored in virtually any SQL database with an ODBC driver and export the cluster results back into the database as a set of additional columns. It would add a Cluster ID column (rows with the same ID would be in the same cluster), a column indicating whether the document was the representative document (i.e. approximately the center) for the cluster, and a few other columns. If the user ran multiple calculations on the same database and wanted to replace some old results instead of adding new columns, the old columns would be dropped and replacement columns would be added -- this was done because sizes needed for the columns may vary between different calculations, so simply overwriting the old ones wouldn't necessarily work. Getting everything to work across all test databases (Oracle, MSSQL, DB2, MySQL, PostgreSQL) was a major pain.

  • The problem is that SQL is all about the query language formalized structure. It says nothing about the procedures or how to control the backing server.

    Think about SWL (structured written language). There are a few standards, one of which is the Roman standard. Using this standard, we can use the same character set to represent many different spoken languages. We can store meaning using the Roman SWL and anyone else who knows the structure can extract it.

    However, the transforms and functions, cliches and linguistic interlinks all exist outside of that structure. As a result, a lexicon is also required in order to put in IItalian and have it usable by someone in the Philippines. The information stores just fine, but updating and making sense of what you've retrieved takes more work.

    Annoyingly (to me anyway), almost every SQL server vendor out there has hard-coded a way of handling this extra meta-data and interfacing it with the data itself. Some of their solutions are similar enough that ODBC and OLE DB can handle basic procedure calls -- but anything written to take advantage specifically of the strengths of a specific SQL-backed service tends to be incompatible.

    So yes, you can connect SQL to SQL in any form, but actually managing the data and preserving context in a way an existing application wants to... that's another kettle of fish altogether.

    Of course, once it's done, it's done -- so someone could easily re-tool a Postgres DB to act enough like a MySql DB *for a specific DB instance* that the samba service should function "mostly" as expected -- and the actual structured data should migrate just fine once the re-tooling and testing is complete.

  • by erroneus ( 253617 ) on Tuesday December 11, 2012 @06:57PM (#42254991) Homepage

    Actually, I have read right here among the commentary that one can still use the Microsoft tools for managing a Samba server. Getting Samba set up initially might require some level of ability, but you know? As much as it pains me to admit it, you have to have at least as much ability to do it with Microsoft. Anyone who thinks they can't learn to do it under Linux is simply limiting themselves needlessly.

  • by Anonymous Coward on Tuesday December 11, 2012 @07:20PM (#42255179)

    Sorry to point this out so bluntly, but I'm sick to death of this argument. that Microsoft is better than open source, because they offer full support to business customers. As a sys admin with 15 years under the belt, I can tell you that I have never gotten anything from Microsoft past a link to a technet support wizard that asks 4 obvious, general questions and always ends with "Sorry we cannot provide a solution to this problem, Do you find this article helpful?"

    NO I FUCKIN' DON'T.

    Microsoft would be the last place I would ever call if there was a critical server failure where downtime is money.

    In the real world, this kind of support is provided by 3rd party Managed Service Companies who are paid separately anyways, so you might as well pay for support on a nix based system, as they are well known to be much more stable (look at your average local nix admin with his feet up knitting or making chainmail, because he's got his systems singing and cron-grepping him hourly reports about how awesome he is and why he deserves a raise, compare this you your best of breed bad ass wizard windows admin, stressed as fuck, up till 4am fixing stupid shit for peanuts)

  • Re:GPLv3 (Score:4, Interesting)

    by Jeremy Allison - Sam ( 8157 ) on Tuesday December 11, 2012 @07:42PM (#42255377) Homepage

    /. is not what it was, but then again it never was :-).

    I miss the .bruce.perens/bruce.perens/bruce.perens./ wars.. and the "information wants to be wiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiide" guy :-). And who could forget sig11's "will the real Bruce Perens please stand up" ?

    But Tim Potter (old Samba Team member) and I loved the trolls :-).

    Jeremy.

  • by Jeremy Allison - Sam ( 8157 ) on Tuesday December 11, 2012 @08:56PM (#42255957) Homepage

    You do realize that many enterprise storage servers made by companies like IBM, Symantec, EMC, Dell etc. are or have been based on Samba code, right ?

    Nah, probably not... :-). After all, you know that only Windows storage servers work with Windows clients don't you :-).

    Jeremy

  • by Anonymous Coward on Tuesday December 11, 2012 @09:39PM (#42256229)

    The bitter tragedy is that Microsoft stole an open source standard like Kerberos, modified it, and used it to lock down corporate networks to prevent the intrusion of open source on their turf successfully during that time.

  • Not Invented Here (Score:5, Interesting)

    by abartlet ( 64597 ) <abartlet@samba.org> on Wednesday December 12, 2012 @12:16AM (#42257107)

    Samba uses Heimdal Kerberos precisely because we did not wish to re-invent Kerberos. We bundle a known-working copy of that in the tree, and launch the KDC inside the samba process so it behaves as a seamless part of the AD DC. We provide plugins for the things that need to be AD-specific (such as PAC handling and reading the AD Database) for the Heimdal codebase to use.

    For LDAP, we took a different approach, and instead wrote our own LDAP-like database on top of tdb. LDAP is in many ways much simpler at the core, and the hard parts are all the schema rules and special cases that are AD-specific anyway, and which we have special modules to handle (on top of LDB, which remains quite lightweight). That isn't to say that this would not have been possible - indeed, Luke Howard's XAD shows it is - but just that we decided to do that part in-house. I'm quite comfortable with that choice.

    Andrew Bartlett
    Samba Team

If all else fails, lower your standards.

Working...