Linux as Domain Controller for small Windows Network.

I know that it's possible, Samaba3 supports NT4 PDC and BDC role. Samba4 will/does support AD role. And in meantime there is other options for LDAP servers.Windows 7 can be put in VM using KVM or Xen to run stuff that requires MSQL server (ACT, Quickbooks).

The question is how does it work out in reality? Has anybody gone down this road and lived with it?

I've been wanting to implement something like this every time Windows Server has some strange an expected behavior/bug. (About every two years on the clock) But I've always shied away from the following fears:

1. 99% syndrome. As is pretty common in linux to have great implementation for everything but 1% that ruins your life.2. Setup time.3. More difficulty with handing off administration to somebody else.

I would really welcome any stories of experience with such a configuration.

I'd recommend not unless you have a bunch of people working there who are willing to support this over the years. It's going to be a fairly non-standard setup. If this is for a business, in theory there should be enough money to pay for Windows Server licenses.

What happens when "Windows 9" comes out and it doesn't work but the boss really wants it on his laptop?

It's not a drop in replacement for AD. It takes work, there are issues and it is not perfect.

The question is how does it work out in reality? Has anybody gone down this road and lived with it?

While it might work today, a better question would be whether or not it will work tomorrow. When Microsoft releases new software, they like to cut the strings on older software.

Another thing to consider is the cost. While a pair of Windows Server licenses will cost ~$1800, you also need to look at other costs, like the cost of actually getting the Linux parts to play well together and with Windows, the cost of maintaining this infrastructure moving forward, and the cost of having all the Windows desktops individually download their patches (WSUS is free, but it only runs on Windows Server - bandwidth costs $).

We've been setting up an LDAP infrastructure under Linux. If we had known up front how long it would take, we would have just bought a pair of Windows Server licenses (or an SBS license and a Server license), and run them as the core infrastructure servers (DNS/DHCP/LDAP/Kerberos/SMTP). It would have saved a few $K.

The question is how does it work out in reality? Has anybody gone down this road and lived with it?

NT4 PDCs suck, so your reality will be sucky at absolute best. Even in the best setups, you lose features compared to Active Directory. Features you almost certainly need in order to manage Windows desktops and servers, like a functioning and sane Group Policy implementation.

we would have just bought a pair of Windows Server licenses (or an SBS license and a Server license), and run them as the core infrastructure servers (DNS/DHCP/LDAP/Kerberos/SMTP).

Y HELO THAR LICENSING VIOLATION! You know what happens when you add another Windows Server to an SBS domain, and promote it to domain controller? edit: be *careful* when doing this not to transfer any FSMO role to the non-SBS server. A hidden service running on the SBS box shuts it down two days later without warning, because you violated the licensing terms for SBS, which state "let there be no other domain controller on this AD, ever, because fuck you that's why."

I'm rude, but I'm not kidding. Yes, there is a hidden service running that will do exactly what I've described. No email, no message on the desktop, no nothing, just "oh hey why did the server shut down?" So you start it up. And you test it. And all is running fine. And you leave... and about an hour later, it shuts itself down again. Eventually, with luck, you grep through the Event Viewer and find a cryptic event message about licensing, you google that, and then you discover what I just told you: you violated your SBS licensing when you promoted another Server to DC transferred an FSMO role away from your SBS, so your SBS said "fuck you" and shut itself down, and it will continue to do so.

(struckthrough lines and corrected after Accs pointed out my error - I misremembered the details.)

(If you're wondering what your upgrade path is from an earlier version of SBS to a newer version... it's "pain, agony, and misery." In-place upgrades only. No, they don't work any better than any OTHER in-place Windows version upgrades... possibly worse. And when you do an SBS install, guess what? The only possible SBS install is an SBS install creating a new AD in which your new install is the only DC. So no, hope you weren't thinking of doing something sane like bringing up a new SBS on the newer version and migrating services and data - NOT SUPPORTED! BECAUSE FUCK YOU!)

Yes, I feel a bit strongly about this.

TL;DR - you want to talk about false economy, SBS (now known as Server Essentials) - at something like $300 less than full Windows Server, and $1000 less than Windows Server Standard + Exchange Standard - is the biggest possible example. (And I haven't even gotten into the nightmarish default policies, stupid wizards, and "monitoring" services that like to make the machine commit hara-kiri.) Avoid like the PLAGUE.

Samaba3 supports NT4 PDC and BDC role [...] Has anybody gone down this road and lived with it?

I have. It worked, but it wasn't particularly pretty. You had to do some kind of ugly kludge-work to set up machine accounts (which is normally handled transparently by the DC with an actual Windows server), and even then, you had... well, an NT4 domain. Which isn't what most people really want. So no, I can't say I recommend this route.

we would have just bought a pair of Windows Server licenses (or an SBS license and a Server license), and run them as the core infrastructure servers (DNS/DHCP/LDAP/Kerberos/SMTP).

You know what happens when you add another Windows Server to an SBS domain, and promote it to domain controller? A hidden service running on the SBS box shuts it down two days later without warning, because you violated the licensing terms for SBS, which state "let there be no other domain controller on this AD, ever, because fuck you that's why." I'm rude, but I'm not kidding.

Yes you are rude, and you may, or may not, be kidding, but you are absolutely WRONG. There are no issues until you try to transfer one of the FSMO roles. I've done this with SBS 2011 (based on Server 2008R2), and it works fine.

There are no issues until you try to transfer one of the FSMO roles. I've done this with SBS 2011 (based on Server 2008R2), and it works fine.

On the other hand, an SBS upgrade is a pain.

Crap, you're right - it IS transferring an FSMO role that's the license violation issue. My bad. (I still feel pretty hateful about it.) And yeah, still doesn't mitigate the issues with upgrading from SBS/SE of one vintage to another.

Been there, done that, learned my lesson (supporting that system is a pain).Linux is great for many things. This is not one of them. Run SBS (Small Business Server).

From my understanding, isn't the SBS offerring going away with Server 2012? The new "Server Essentials" offerring may fit the bill, but last I heard, licencing is capped at 25 users.

Pertaining to the OP's question, I'd agree with most here that trying to use it as a DC is more of a pain than it's worth. My first MSP job attempted to build a business on this very idea. One of my first tasks there as the "Windows" guy was to start migrating our clients to Server 2003.

For the most part, they're just following the post 2010 "it's Tuesday, time to change the name of everything we offer!" standard MS marketing policy. (Quick - what's the CURRENT name of their hosted email service? Are you SURE? Better check! )

Yeah it's capped at 25 users, but I really hope to god anybody with more than 25 users already had enough sense not to be running SBS in the first place. Truly, truly awful product; the $500-$1000 you save on licenses QUICKLY gets eaten up with the additional support hours that go into dealing with the fool thing.

I really hope to god anybody with more than 25 users already had enough sense not to be running SBS in the first place. Truly, truly awful product; the $500-$1000 you save on licenses QUICKLY gets eaten up with the additional support hours that go into dealing with the fool thing.

We're running SBS with 35 users, and it works fine. No extra support required. For the most part, it "just works", which is truely amazing, as it handles email and authentication for Linux and Solaris, as well as Windows.

I'm glad you're having better luck with it than I have. The default policies make zero sense for most of the environments I support, and the "SBS Monitoring Service" is inordinately fond of thrashing the living hell out of CPU and HDD to boot. Then you add in the nightmare of trying to deal with upgrades (hardware or OS), and... ugh.

The default policies make zero sense for most of the environments I support

They're not significantly worse than the default policy set in Server 2008R2. We made several changes there anyway, and the policies should ALWAYS be checked when installing a new domain. This was a one-time investment, and has nothing to do with ongoing time requirements.

Jim Salter wrote:

the "SBS Monitoring Service" is inordinately fond of thrashing the living hell out of CPU and HDD to boot.

I don't believe we're using that service.

Jim Salter wrote:

Then you add in the nightmare of trying to deal with upgrades (hardware or OS), and... ugh.

The OS upgrade of SBS has already been covered. It's a pain, and always has been. To upgrade to a newer version of SBS without MAJOR cost, risk and time invested requires a second Domain server and a temporary email server. If you don't have Technet (or some other way to get the extra software) and some spare systems, you're going to have problems. Fortunately, it's not something we'll be doing any time soon, and even then, it won't be to SBS (we're running SBS 2011, and there will be no future SBS releases).

We've done a few hardware upgrades (added CPU, memory and disk), and encountered no problems, but a Motherboard upgrade would be a problem. Of course, a Motherboard upgrade is a pain with ANY Windows OS, it's just that with SBS there are so many eggs in the basket that it seems worse.

One of the things that has helped us was that we configured it correctly, then we left it alone. We patch it monthly, and that's it. When we think we need to make a change, we look at it VERY carefully, and delay as long as possible (we sometimes find a better path in the meantime). One of the issues is that there's so much stuff on an SBS system that it's "fragile". A seemingly minor change could cause serious problems. The simplest solution is to make as few changes as possible. A more complex solution is to move services off of the SBS system. We've got a second Domain controller (running DHCP and DNS) and a dedicated backup server. We also use Linux/Nagios/Cacti for resource monitoring. The next change on our list is to move SharePoint to a dedicated server.

When SBS is ready to be retired, I want to be in a position where it has a minimum number of services. This will simplify the transition. Also, I want to be sure that we have adequate resources to not get in the way of our growth. Spreading the services out helps that too.

We've done a few hardware upgrades (added CPU, memory and disk), and encountered no problems, but a Motherboard upgrade would be a problem. Of course, a Motherboard upgrade is a pain with ANY Windows OS, it's just that with SBS there are so many eggs in the basket that it seems worse.

What makes an SBS upgrade inordinately worse is that you can't just bring up a new instance of SBS on a new server, add it to the domain, then migrate services - SBS must be the first DC on a new domain when installed, so the answer if you need to bring it up on new hardware is basically "eff you." Even with REGULAR Windows DCs, the proper way to upgrade DCs, whether for OS version or for newer hardware, isn't to try some in-place monstrosity, it's to add a new box, promote it, migrate services to it, then retire the old one. Not possible with SBS. Just not okay.

Virtualization takes some of the sting out of dealing with SBS, since you can upgrade the underlying hardware without SBS itself ever having to know about it (and freak out and refuse to run), but you're still stuck in bizarre no-mans-land of trying to do a fail-tastic in-place upgrade - though you can at least do that on a test VM without screwing with production, since you're virtualized - which is likely to take MANY many frustrating, pointless man-hours dealing with esoterica and also likely to leave you with a screwy, crufty system just like any other in-place major-version Windows OS upgrade will.

SBS is the redheaded stepchild of the Windows Server line, avoid it. It's worth the extra $500 or so for a real Windows Server install for almost any organization.

Though small organizations should strongly consider hosted Active Directory/Exchange. It's just not that much bandwidth for a small number of users, so this usually makes sense. What starts getting very pricey very quickly is hosted/cloud storage.