How to Extend On-Premises Active Directory to Microsoft Azure
I am seeing an uptick in the number folks asking me about extending local on-premises Active Directory into Azure. As such, I figured I should put together an article that explains the proper way to extend an on-prem Active Directory into Azure.
An Overview
To be honest, getting local AD extended to the cloud is not terribly difficult. However, there IS a special order in which things need to happen in order to make it work properly. The first order of business is the deployment of a virtual network in Azure. Once the virtual network is deployed in Azure and secured with a Network Security Group, a VPN connection needs to be made between the on-prem network and the Azure virtual network. With the VPN connectivity in place, the DNS configuration of the virtual network needs to be configured to point back to the on-prem DNS servers (since they know how to resolve the local Active Directory domain).
After the configuration of the virtual network and VPN in Azure are complete, a virtual machine needs to be provisioned in Azure. Because the virtual network points to the on-prem DNS, the virtual machine will inherit those DNS servers when it comes up. The virtual machine should be deployed with no public IP address and it should have a separate 20-40GB data drive with caching turned off. This is a Microsoft-supported configuration and prevents USN Rollbacks.
Once the virtual machine is provisioned, it should be joined to the on-prem Active Directory just like any other member server. After making the virtual machine a member server, Active Directory Domain Services should be installed. The server can then be promoted to a domain controller for the on-prem AD. Active Directory should be stored on the data disk that was provisioned, not the system drive.
At this point, Active Directory Sites and Services should be configured to reflect the new Azure network as a new site. Once this configuration is complete, the on-prem Active Directory is successfully extended to Azure.
Extending On-Prem Active Directory to Azure: Step By Step
Now that you have a high-level view of what has to happen to allow for a successfully extension of on-prem Active Directory to Azure, let’s walk through the individual steps that are required.
Deploy and Secure the Azure Virtual Network
Go into your ARM portal and deploy a virtual network with an address space that does not overlap your on-premises network space. For example, you might deploy an address space of 10.0.0.0/16 in Azure if your on-prem address space is 192.168.0.0/16. While deploying the virtual network in Azure, you will be prompted for a default subnet and address range for it. Do not use the entire address space when creating your subnet. Only use what you need. In this example, you might use 10.0.1.0/24 as your subnet range. Once the virtual network is deployed, be sure to deploy a Network Security Group in Azure that contains an inbound rule that allows RDP traffic only from your network.
Establish VPN Connectivity
Depending on your on-prem VPN device, you might need to deploy a route-based VPN or a policy-based VPN in Azure. If your on-prem VPN device supports IKE2, you will want to deploy a route-based VPN. Otherwise, deploy a policy-based VPN. Most devices that I have encountered to date only support IKE1.
Deploying an Azure VPN requires a few different pieces. It requires a Gateway Subnet on the Azure virtual network, a Virtual Network Gateway with a public IP address, a Local Gateway that represents the on-prem network device, and a Connection.
Start your VPN deployment by provisioning a Gateway Subnet on your virtual network. A Gateway Subnet should consist of a /27 range. To make things easy for yourself, click here to download the Gateway Subnet Calculator. The Gateway Subnet Calculator is a PowerShell script that takes your virtual network address space and uses it to automatically calculate an address range for your Gateway Subnet. It is a pretty handy tool. Just follow the instructions that come with it. If you stick with the examples from earlier in this article, the calculator will produce a Gateway Subnet range of xxx.xxx.xxx.xxx.
Once you have the Gateway Subnet configured, go ahead and deploy a Virtual Network Gateway and specify your Gateway Subnet during deployment. During configuration, specify the address space of your Azure virtual network in the "address spaces" section so your domain controller is accessible over the VPN when it is complete.
The deployment of the Virtual Network Gateway will often take up to 45 minutes to complete once it has been submitted so go find something productive to do while that is happening. Eventually the Virtual Network Gateway deployment will complete and it will show a public IP address. Jot it down because you will need it to provision the VPN shortly.
With the Virtual Network Gateway provisioned, go ahead and provision a Local Network Gateway. Specify the public IP address of your on-prem VPN device when configuring the gateway. Additionally, add any additional underlying address spaces in the "address spaces" section. These address spaces reflect networks that you wish to access over the VPN. Talk to your network admin if you are not sure of what address spaces are in use in your environment.
At this point, you should have your Virtual Network Gateway configured, along with your Local Network Gateway. With both gateways configured, you can deploy the actual connection by clicking the "+" sign in your ARM dashboard and searching for "Connection". You will be prompted for a Virtual Gateway, a Local Gateway, and a shared key. Select the gateways you have provisioned and enter a shared key (your network admin will need to use the same key). Once you do this, the configuration on the Azure side is complete. Go ahead and provide the public IP of your Virtual Network Gateway to your network administrator so he can configure the VPN on his side of the house (the local VPN device). He/she will also need the address space of your virtual network and the shared key you chose so provide that info as well.
Once the local VPN device is configured, the status of the VPN in Azure should switch to Succeeded/Connected.
Deploy the Virtual Machine
Now that the connectivity between Azure and your on-prem network is up and running, you can go ahead and deploy the virtual machine that will eventually become your domain controller in Azure. Unless you are upgrading your AD at the same time (not recommended), be sure that the OS you choose matches your current domain controllers. When deploying the VM, go with a reasonable size. I have found Standard A2_V2 size to be sufficient in most cases for small environments.
While deploying the virtual machine, you will be prompted to assign a public IP. You can go ahead and assign it a public IP for now, but you will eventually need to remove it since you don't want a DC to be accessible publicly. However, assuming your VPN connectivity is good, you should really just forego the assignment of a public IP and configure the VM via RDP from your local network over the VPN using its internal IP address instead. Additionally, choose the option to deploy an Availability Set as well. Doing so will allow you to later add a second domain controller into the set to ensure at least one of the DCs in Azure is always available. Change the assigned internal IP address from dynamic to static. After deploying the virtual machine, provision and attach a data disk and set the Host Cache Preference to None. This data disk will house Active Directory.
Configure the Virtual Machine
Once the new virtual machine comes up, RDP to it and configure it as you normally would. Apply any needed patches, set the time zone, etc. If necessary, go into disk manager on the virtual machine, scan for the data disk that you provisioned earlier, and make sure it is formatted and a volume exists on it.
After configuring the server, reboot if necessary and then join it to the on-prem Active Directory just as you would any other server. You can then go ahead and install Active Directory Domain Services and promote it to a Domain Controller. Make sure you've removed the public IP first. Be sure to specify the data disk that you provisioned as the path for Active Directory. The installation process is going to complain about your VM having a NIC with a DHCP-assigned address. You can ignore this. Yes, your OS sees a DHCP configuration; however, the IP is never going to change because it was set to static in Azure.
Wrapping Up
At this point, you can go back into your ARM portal and reconfigure your virtual network DNS so that it points to the IP address of your newly promoted Azure-based domain controller and reboot the VM so it picks up this new setting. You should also remove the public IP address from the VM in the portal as well if you haven't done so already. Once you do this, you will have to RDP to the VM using its internal IP address from your on-prem network. Test and make sure the server is accessible after removing the public IP. If all is still good, finish up by adding a site to Active Directory Sites and Services that reflects the new Azure subnet.
Congratulations, you just extended your on-prem Active Directory into Azure.