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
- 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.
- Traditional AD
- 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
- Not the
How
do I authenticate / authorize the remote
locations
- Add
remote Linux DC at remote location (seems like overkill for one remote
client) - Somehow connect to the VPN prior to logging in to
Windows (is this even possible?) - 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
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.
Comments
Post a Comment