3

I am the 'IT guy' for a company that is rapidly growing and about to reach 100 employees. While my primary job is backend development for our websites and services; I am also tasked with setting up and maintaining PC's for our users.

Currently I am just making local accounts on machines, putting in their outlook settings and pre-installing a handful of applications for users, but managing this is getting out of hand. And I can barely keep up with the expansion, not to mention the background 'churn' of hirings and firings.

The 'simple' solution to this is to set up a Windows Server and start using active directory to manage accounts, the problem is that our employees are scattered across 12 locations. As it is now, I am using logmein to remotely administer machines.

I would like to move towards some kind of domain based login, similar to a traditional active directory setup where I create and configure windows user accounts at a central location, and then end users simply login to any machine with DOMAIN/username.

I've been playing with Windows InTune and it's great for managing machines, and deploying policy, but that's really not what I need.

I've been looking at Azure Identity, but that implies that I still need a local AD controller for every location. Ideally I would like these services to exist 'in the cloud'. I don't know if I feel comfortable with having a server on site at each location, as the locations are rural and I would like to avoid sending specialized, expensive equipment out to be installed by a local contractor.

An 'active directory/sso like' service being cloud hosted seems like it would be a no-brainer, and after reading about the products such as InTune, Azure Identity and Office365 it seems like it can be done... Has anybody managed to successfully deploy a system like this or know of a case study/post-mortem of somebody who did?

  • What's the problem with all 12 locations using the same AD controller? – user1686 Jun 18 '13 at 21:22
  • I did not know that was even possible? I was under the impression that an AD controller had to be on the same local network; or you have to set up a vpn. –  Jun 19 '13 at 16:56
  • That was a requirement for Windows NT 4 domains, which relied heavily on NetBIOS broadcasts, but all protocols that Active Directory uses (DNS, LDAP, Kerberos) work just fine over the Internet. ⫽ On the second thought, a VPN would still be useful – exposing the SMB service [Windows file sharing] to the Internet might not be the best idea... ⫽ Alternatively, you could run Samba 4 which can act as an Active Directory controller without many of the security concerns and with lower resource requirements. – user1686 Jun 19 '13 at 18:34
  • I looked into Samba 4 and watched the demo videos on their site, it was very impressive. It's obvious that I have a lot more research to do but you opened me up to some interesting ideas. –  Jun 21 '13 at 16:26

1 Answers1

2

If this were my environment I'd consider doing the following:

  • Acquire some inexpensive devices that can perform VPN termination in the remote offices-- Ubiquiti EdgeRouter Lite boxes, or some small box that can run OpenWRT Linux.

  • Terminate the VPNs from all of the remote sites at my central location.

  • Install two Windows Server instances, preferably running on distinct physical hardware and preferably located in separate physical locations, for redundancy. If you can, put one at the central location and put another in the most-staffed remote location, housed under lock and key.

  • If you're placing a Domain Controller in a secondary "hub" location configure all your VPN termination devices to terminate a second VPN tunnel directly to the second location (so that traffic from the remote sites to your secondary "hub" doesn't need to travel through the primary hub site).

  • Create an Active Directory Forest and Domain on one of the Windows Server instances, installing DNS along the way.

  • Promote the other Windows Server instance to a Domain Controller (DC) in the newly-created Domain, using the first DC as its DNS server during promotion. Install the DNS role on the second DC and configure both DCs to use themselves as their primary DNS server and the other DC as their secondary DNS server.

  • Configure the second DC as a Global Catalog server.

  • Configure the PCs in the remote offices to use both DCs as their DNS servers.

  • If you're concerned about losing DNS if the VPN fails configure the VPN termination device in each office as a DNS server. Configure that DNS server to conditionally forward requests for your Active Directory domain to the DNS servers hosted by the DCs while sending all other DNS requests directly to the Internet. Configure all the clients in the remote office to use the VPN termination device as their DNS server. If the VPN fails client computers in the remote will still have DNS. (You may have problems with dynamic DNS updates from clients in this configuration.

Assuming the Internet connections in the remote offices aren't awful you should see reasonable logon times when you start joining PCs in the remote offices to the domain. Don't go crazy with Group Policy or you'll start slowing things down. Nice stuff like Roaming User Profiles and Folder Redirection are probably out of the question in this kind of configuration. You may have to modify Group Policy slow link detection thresholds to even get Group Policy to apply properly (depending on how cruddy the remote site Internet connections are).

You would get a lot of manageability with this solution while, at the same time, not exposing your DCs directly to the Internet (which AD was not designed for).

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331