Remote branches and domain controller

Question

I have a very small, but distributed network. In the central office, there's a Windows Server 2008 R2 VM with a few Linux VMs running on the same box. There are two client PCs running Windows7. In a remote location, there is a single client PC, currently connecting into the central office with OpenVPN via one of the Linux servers.

I would like to move from Workgroup to Administrative Domain for better group policy control. I will not be able to justify additional server hardware or Microsoft licenses (those things are ridiculous) but can easily add more VMs to the existing server.

The way I see it I have a few decisions to make, each with a few options.

Which server runs the domain

1. Windows Server 2008
   • Traditional AD solution
   • Can't add a backup controller without another license
   • Windows server is also running FTP and AS functions; AD servers typically just host AD.
2. One of the Linux boxes with Samba)
   • Not the traditional AD solution (am I giving up any features?)
   • Can easily (read: cheaply) add a backup controller
   • If necessary (not ideal), can add a DC at remote location

How do I authenticate / authorize the remote locations

1. Add remote Linux DC at remote location (seems like overkill for one remote client)
2. Somehow connect to the VPN prior to logging in to Windows (is this even possible?)
3. Expose my AD to the internet without VPN. (seems like a terrible idea)

Are there any options I'm missing? This has to be a pretty common situation for small businesses, I can't imagine these IT-less companies are buying multiple WinServer boxes to setup the traditional solution of a standalone AD, a standalone backup AD, and then another box to host everything else....

I'm a Linux guy and have no problem getting my hands dirty, but don't have a wealth of IT experience.

Answer 1

The ideal solution would be to setup a site-to-site VPN tunnel and handle all the authentication against the DCs at the main site. (This would of course, depend on your network gear or any gateway servers you can set up at each site.)

If you put a second DC at the remote site, you'll have the same issues with connecting the two sites so the DCs can talk to each other. And, yeah exposing AD to the public net is all kinds of worst-idea-ever. And, let me add that using Linux as your secondary DC strikes me as a very not good idea too. I bet it can be done, but I wouldn't want to be around when the Windows DC fails and you have to try restoring your only Windows DC. Might be "good enough" but, well, like I said, I wouldn't trust it, and if I can't trust it, why bother having it around in the first place?

If you can't do a site-to-site VPN, depending on the exact VPN software you're using, it's actually possible to connect a remote client VPN without user context (before logging into Windows), yes, though I'd suggest that an easier idea would be to allow caching of the domain credentials and/or a non-domain limited user account. Caching the domain credentials for a client that only has VPN access can be a bit of a headache when the password needs changed though, so heads up on that.

And for what it's worth, the "common" solution to this problem seems to be to stay with workgroups, and/or cheap out on the IT admin they hire, as to ensure they end up with a domain that's effed up in more ways than I can count. So, kudos on taking the initiative to at least try to do it right.