Cloud

di

Configuring Active Directory Domain Services in Azure Cloud

The first question that people might have after looking at the title of this blog post is: “Why would I need to configure AD Services in Azure if it already offers a managed service?” I was thinking the same thing when I ended up configuring AD services on my VMs in Azure. The reason I had to do that rather than using the managed service was that I needed an active directory domain for a small environment I was spinning up for test/dev purposes. I didn’t need the multi-tenancy and other features that Azure AD offered. If you think that you might be in the same boat, then read along and see the step by step instructions on how to configure AD on VMs running on Azure Cloud.

  1. Select the Azure region that you want to use to spin up your instances and then create a new virtual network. In my case, I am using the US Central region and I created a virtual network with the address space of 10.1.0.0/16.
  2. Create a new Availability Set for your AD VMs. This step is optional, but it helps to have an availability set to ensure that the two AD servers that you spin up aren’t going to run on the same underlying hardware. You can keep the default settings for the Failure domains and Update domains when you are creating the availability set.
  3. Create two subnets inside the virtual network that you created. One of the subnets can be a public subnet with access to the internet and the other one can be a private subnet. I used the private subnet to host my AD VMs as I didn’t need those VMs to be accessed from my laptop.
  4. Create and configure network security groups(NSGs) for the two subnets that you created. For the public subnet, I created inbound rules allowing HTTPS and RDP traffic and blocking all the other traffic from the outside world. I added another rule to allow all traffic from the private subnet. Since NSGs are stateful, I didn’t have to create matching outbound rules. For the private subnet, I created a rule to allow all traffic from my public subnet and block all the traffic from anywhere else. NSGs evaluate rules in an ascending order, so make sure to assign a lower numerical value to allow rules as compared to the deny rules. As a best practice, you should leave enough space between these rules, so that you can create additional rules in the future if needed.
  5. Next step will be to deploy virtual machines in the private subnet that we created. In the VM creation wizard, make sure that you select the correct virtual network, subnet, and NSG. Also, make sure that you don’t attach a public IP address to the VM. I used the Windows Server 2016 Datacenter image and chose DS1 v2 as my instance type. You can go for a different image type and size depending on your needs.
  6. Once the VMs are up and running, we need to change the IP settings, so that the AD servers have static IP addresses. You can use the following AzureRM powershell cmdlets:$nic=Get-AzureRmNetworkInterface -Name TestNIC -ResourceGroupName TestRG $nic.IpConfigurations[0].PrivateIpAllocationMethod =”Static” $nic.IpConfigurations[0].PrivateIpAddress =”10.1.1.6″ Set-AzureRmNetworkInterface -NetworkInterface $nic Get-AzureRmNetworkInterface -Name TestNIC -ResourceGroupName Test
  7. Or, you can also use the Azure GUI to set static IPs on the AD VMs. Navigate to the VM, click Network Interfaces, Click on the interface that you want to modify, Click on IP configuration, Click on the IP and then select Static under Assignment and click Save. If you are assigning a different IP than what was already assigned to the virtual machine, you will have to restart the VM for it to get the new IP address.
  8. Now that you have configured static IP addresses for the AD VMs, RDP into the primary AD VM using a jumphost or a bastion host.
  9. Install the Active Directory Domain Services role on the primary AD VM. Once the role is installed, next step is to complete the post configuration where we will create a new forest. This wizard is the same wizard that you use when you create a new forest in your private cloud.
  10. Once the AD role is installed and configured on the primary VM, then the next thing we need to do is to modify the DNS servers that would be used by the VMs in your virtual network. You can do this through the GUI by navigating to the virtual network, and select DNS servers. Change the setting from Default (Azure provided) to Custom, and enter the IP address of the first AD Server that you configured in the previous step.
  11. Once the DNS server is configured, RDP into the second AD VM that you created earlier and install the Active Directory Domain Services role. This time during the post configuration wizard, select “Add a domain controller to an existing domain”. Again this wizard is identical to how you would add a secondary domain controller in your own datacenter.
  12. Once you have configured the second AD VM, go back to the DNS server setting for your virtual network and add an entry for the second AD VM.

That’s it, you are done. Now all the Virtual machines that you spin up in your virtual network will automatically use the AD VMs as the DNS servers and you can join them to the new domain in the same way that you would in the case of your own datacenter. Please use this setup only for test/dev purposes because these VMs won’t offer you the same level of availability as the Azure AD service.