Friday, August 22, 2014

Considerations for Deploying Active Directory Domain Controllers in Microsoft Azure

Azure is the new hotness. It seems like there are new features being lit up each week in the platform and it's gaining quite a bit of momentum. One thing that many organizations are starting to consider is extending their on-premises Active Directory Domain Services infrastructure out to Azure IaaS. Note that this is not the same as Azure Active Directory, which is an authentication solution for Office 365 and other cloud-based services.

One place where this is starting to gain momentum is with AD FS in support of Office 365. Organizations are starting to say "Hey, we've moved out messaging and collaboration to the cloud, why is our authentication infrastructure for those services still on-prem?" It's a fair question to ask, and I am starting to find that deploying AD FS in Azure in support of Office 365 is a great way for admins and engineers to get their feet wet in the platform.

This post is going to focus on deploying AD Domain Controllers to Azure. I may do a post on deploying AD FS to Azure as well, but step one is extending directory services to the cloud. The reason for this is twofold:
  1. There is no point to deploying AD FS in the Azure without DCs there as well. If the site-to-site VPN between Azure and your datacenter fails, authentication fails. This defeats the purpose of putting AD FS in Azure in the first place.
  2. Azure bills for egress network traffic. In very busy environments with thousands of authentication attempts per minute, this can add up to a pretty penny. Keeping all authentication "self-contained" in Azure will greatly reduce this cost.
Once you have provisioned your VNet, assigned address space to various subnets, and spun up your VMs, you need to do a few things to prepare for DC promotion.