Azure - Add an Azure virtual machine to an Active Directory domain that exists on-prem

The following information was inspired by another post by one of my colleagues, Diego Viso.  A few months ago, Diego put up a great post called Creating a site to site (S2S) VPN to Azure with RRAS, one physical NIC and a NAT gateway

In that post, Diego provided a great example of using the Routing and Remote Access Service (RRAS) that is built into Windows Server 2012 R2 to setup a site to site (S2S) VPN to an Azure subscription.  In regards to Azure, the benefit of a S2S VPN is that it allows you to extend your on-prem network to a virtual network hosted in your Azure subscription.  By extending your network, you can extend your data center and build machines in your Azure environment and integrate those machines directly with your on-prem environment.  RRAS is a supported mechanism for setting up a S2S VPN, but it has requirements that can prove difficult for small lab environments, like requiring multiple public IP addresses.  This caused RRAS to be less than ideal in lab type scenarios, especially home labs.  I found Diego's solution to the issues posed by these requirements to be very helpful as it allowed me to setup a VPN connection using NAT IP's from my on-prem environment up to the virtual machines I have running in my Azure subscription.  This is really the first requirement that had to be met in order to add Azure machines to my on-prem hosted domain, because in order to be members of the domain, a network connection tying my on-prem environment to the machines hosted in my Azure subscription had to exist.  I had put this off for a while, as I didn't want to invest in a new piece of hardware to enable the VPN, and while running a VM with the RRAS role was supported, I did not want to invest in purchasing multiple static IP's from my ISP.  Upon finding Diego's example I had everything I needed to proceed with S2S VPN testing using RRAS in my home lab.

While the solution Diego explained would not be appropriate for a production environment, it should more than fit the need for most small lab environments, and it did everything I needed to get things up and running in my home lab.

Continuing from the end of Diego's post, the next steps I had to complete involved configuring a static route for machines in my on-prem network, to tell them to use the NIC labeled "Internal" on my RRAS server as the gateway to reach machines that were being hosted in my Azure subscription.  Following Diego's post, the VPN connection had been established between my on-prem environment and my Azure subscription, but I was only able to communicate to and from my Azure VM's with my RRAS server.  It was not until I configured the static route on my core router in my on-prem environment that I could reach all of my on-prem resources from my Azure VM, most importantly being my on-prem domain controllers.

Additionally, I configured my Azure network with the IP of my on-prem DNS server so that when machines were created in Azure that were part of my virtual network, they would automatically get my on-prem DNS server as a DNS server in their network configuration.  This is important so that when I try to add a machine to my on-prem hosted domain, the server in Azure that is being added to the domain has the ability to resolve the domain name properly.

With these steps completed, I was able to successfully join one of my machines hosted in Azure to my domain hosted solely on-prem, and begin managing that machine just as I would any other server in my on-prem environment.  For me, the biggest hurdle I had to overcome was the static route configuration, so if you are looking to get this setup I hope this information can be useful to you!