I suggest you read our HOWTO when the server recovers, because you will see that our samba-tool domain provision command does exactly that, and the HOWTO covers things from top to bottom. Samba Administrators have been deploying Samba as an AD DC for a number of years now, and they consistently point to these two things as why they find it so easy to do so.

Andrew Bartlett
Samba Team

OpenChange, mentioned in the summary, handles the Exchange protocols. We are very proud of the close way we work with the OpenChange team.

Andrew Bartlett
Samba Team

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

The bind9_dlz backend uses the same database as the rest of Samba, and so suffers the same features and limitations as the overall DC.

As I said in the other post, while we are concerned about this area, so far this does not appear to pose an issue in practice.

Andrew Bartlett
Samba Team

You are correct that if things were as bad as that particular paragraph sounds, then we would have a serious issue. That particular note (which I wrote) is over-cautious, and represents where we were at a few months ago. The situation is that when administrators manually attempt to replicate the DNS partition onto another DC, it is difficult to configure everything so that as well as the initial replication, updates are correctly propagated.

The good news is that now, when we are setting Samba up as a second DC, we now do this correctly at join time. From all reports, this seems to work fine, but the warning is there because I want administrators who are having issues in this area to know that some challenges may remain.

Overall, while we have great faith in our DRS replication code, and a large number of users have deployed multiple Samba DCs, we are promoting the single DC case first and foremost. Other limitations include that we cannot replicate the files in the sysvol share (where group policies reside) using native protocols (many of our production sites use an rsync script instead). We are well aware of these limitations, and try to describe them to our users.

You may feel we should have waited even longer to release, but I'm quite happy with what we have achieved, and how our production sites find it in the real world. There is always one more feature, one more bug, but I'm incredibly proud of what we have achieved with Samba 4.0

Andrew Bartlett
Samba Team

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

I do have to say, the AD interop labs were some of the most fun I've had in IT. And yes, it was great having the food brought in as we worked late into the night, night after night.

The best bits were being able to work side-by-side with their engineers solving some of the trickiest parts of the puzzle, or working over the results of running their testsuite. These things made Samba much better, and I'm happy to say how much we appreciate these opportunities.

Andrew Bartlett
Samba Team

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

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