A domain controller is the first server most organizations deploy in IaaS as they move workloads to Azure.

Why Configure a DC in Azure IaaS? 

1. A DC builds the necessary foundation to bring other servers into IaaS.
2. Your authentication to Office 365 may depend on it.

In a Microsoft Entra ID (formerly known as Azure AD) Passthrough Authentication scenario, the on premises Domain controller is a single point of failure for each O365 authentication request. So is the Microsoft Entra ID (formerly known as Azure AD) Connect server. If either service is DOA, users won’t be able to sign in to Microsoft Entra ID (formerly known as Azure AD) or Office 365.

Passthrough authentication’s flow goes from Azure AD > Internet > Azure AD Connect Pass-through Auth Agent > AD Domain Controller, then backwards.  Any one of those components can be a single point of failure, but all can be setup for resiliency with high availability and/or DR.

To guard against an outage of the entire data center or its Internet connection, put a Domain Controller in Azure.  This way if anything happened on-premises, the Azure and Office 365 environments would still be fully functional (assuming users have Internet access).

Choose carefully between AAD Password Sync, Passthrough, and ADFS. See an excellent primer on identity and Microsoft Entra ID (formerly known as Azure AD) architecture from my colleague Andy Nelson. When using Microsoft Entra ID (formerly known as Azure AD) with Password Sync, there is less reliance in real-time on the authentication sequence on the domain controller. In that case, the source of authority is Microsoft Entra ID (formerly known as Azure AD). The on-premises environment is simply responsible for syncing the password and attributes of objects. If the entire on-premises environment goes down (AD, AADC, etc) users will still be able to authenticate to Microsoft Entra ID (formerly known as Azure AD) with their most recently synced password as long as they have Internet access.  If AD and AADC are down, Microsoft Entra ID (formerly known as Azure AD) simply won’t receive any attribute or password updates until back online. 

How much will it cost?

These rough numbers are provided to understanding some of the fixed and variable costs of running VMs in Azure.

Fixed Costs:

1. Virtual Machine for the Domain Controller. For budgetary purposes, a low end A2_V2 series VM w/2vCPUs, 4 GB RAM is about $100/mo. The cost is estimated here https://azure.microsoft.com/en-us/pricing/details/cloud-services/
2. 2 standard 128GB SSD managed disks for the VM, 10,000 transactions/mo  ~$22/mo
3. Azure VPN gateway– $29.78 for 730 hours (~ 1 month). The alternative is to use a third party service provided by your VPN appliance manufacturer of choice. This will cost more than the Azure VPN gateway.

 Variable costs:

99. A second VM to run in a (high) “availability set.” It should be noted that two domain controllers should in fact be deployed, in an availability set. It’s in that architecture that MSFT will promise 99.9% reliability. See why a single VM has no SLA. A second VM would add a second ~$100 / mo plus the managed disks ($22) to make the “set.” Alternatively, a single instance virtual machine running on premium disks gives a 99.9% SLA.  Read more about VM SLAs.
100. The Windows Server OS license. If you have a spare on premises that you can leverage, it can lower that VM cost by ~40% on that component if so, using Hybrid Use Rights.
101. Firewall. Enabling doesn’t often configure firewalls for DCs like we do for public facing apps like web services. The simple/free alternative is Network Security Groups (NSGs). Like ACLs, NSGs permit/prohibit traffic from certain IPs, networks, and/or TCP ports. MSFT’s is ~$900/mo, and available magic quadrant leaders cost similar https://azure.microsoft.com/en-us/solutions/network-appliances/
102. Public IPs – usually not applicable for DCs, but for future info https://azure.microsoft.com/en-us/pricing/details/ip-addresses/ .

No cost:

Virtual network https://azure.microsoft.com/en-us/pricing/details/virtual-network/

In summary, that’s how you can approximate ~$300/mo for the low end A2_V2 series VM with 2vCPUs, 4 GB RAM, with two managed disks, vnet, and vnet gateway for site-to-site VPN running full time.

How do the Domain Controllers Connect? 

Communication between domain controllers on premises and in Azure IaaS use Active Directory Replication, over the VPN mentioned earlier. Replication uses Remote Procedure Call (RPC) over IP for replication within a site, typically called IP Site Links.  You can use SMTP as well, but that is much less common.  There are other means of communication, but as long as each DC has the latest replication they can act fully independent of other DCs and sites.

Then, if the DCs on premises at HQ or at the data center are unavailable, users can still log in using an Azure AD Passthrough scenario.

How to Avoid Ransomware Taking over all Domain Controllers

 If you haven’t read Wired’s cover story of how the NotPetya ransomware infected all Domain Controllers at global shipping company Maersk, it’s a great read. It explains how all DCs were locked in rapid succession, and because Maersk relied on replication as their only failover between sites, they were completely out of business until they rehydrated their AD.

A recommended way to prevent what happened to Maersk with today’s technologies would have been using Azure Site Recovery (ASR) with Azure Backup as a fail-safe. ASR would have given them a minimum 24-hour window (72 with standard disks with VMWare) to recover. Azure Backup would have itself been a backup to ASR if that window wasn’t met. There are other options as well, such as virtual cloning and keeping that copy offline, but the options in Azure can deliver a reliable, fast RTO.

Microsoft’s got a great blog outlining how to get started, and you can contact eGroup | Enabling’s engineers.