Domain Controller on Azure

How to deploy a Domain Controller on Microsoft Azure

Active Directory is the heart of your network. The domain controller of your active directory domain is responsible for a lot of on-premises connectivity (LDAP, DNS, …) and is probably extended to the cloud (Azure AD connect). It’s clear that this domain controller is the single point of failure. That’s why you always should have 2 or more domain controllers in an active directory domain (preferably on different hardware).

Deploying an extra domain controller on Microsoft Azure is an easy way to make your active directory domain High Available and avoid many problems.

This article focuses on deploying a domain controller on Azure. For guidelines on how to create an entire architecture as recommended by Microsoft you should check the Azure Architecture Center.

Requirements

  • An Azure AD tenant with an active subscription.
  • A Virtual Network in Azure that doesn’t overlap with your on-premises network.
  • A continuous line of sight between your on-premises domain controller and Microsoft Azure (Azure VPN Gateway, ExpressRoute or an NVA).

Test Your On-Premises Domain Controller

Before deploying an extra domain controller it’s wise to test the health of the current situation. Below are some checks you can do (don’t forget about DNS!). Existing problems must be fixed before continuing.

  • Analyse your Active Directory and DNS Logs.
  • Test your domain controller health with dcdiag /s:dcName
  • Test DNS with dcdiag /s:dcName /test:dns

Deploy A Virtual Machine

  1. Navigate to https://portal.azure.com and sign-in with a user that has sufficient permissions.
  2. Create a new Windows Server resource. I Recommened using Windows Server 2019.
  3. Enter al basic information and don’t forget about the availability options. Don’t use a spot VM to save costs – a domain controller should be always online.

When deploying multiple domain controllers in Azure, each of them should be in a different availability zone or in the same availability set.

By default, allow selected ports is enabled to alow RDP (3389). For safety reasons, you should set this option to none. If required, a network security group can be attached to the subnet or vm afterwards to block certain ports. I Recommend attaching NSG’s to subnets.

  1. Click Next to configure vm disks.

A Single VM without premium SSD’s has an SLA of 99.95%. A Single VM with premium SSD’s (all disks) has an SLA of 99.99%. I Recommend using premium disks for your domain controller.

Add a second (premium ssd) disk with host caching set to none. This disk will contain the database, logs and sysvol folders. A Disk with a size of 8GB is sufficient.

  1. Click Next to configure networking. Attach the VM to your existing vNet that’s connected with your on-premises domain. Don’t assign a public IP address to your virtual machine as recommended by Microsoft – use a VPN or Azure Bastion to connect to the machine. Again, I’ll apply NSG’s to my subnet if required.
  1. Finish all steps to create the virtual machine. Don’t enable ‘Login with AAD credentialsor ‘Auto-shutdown’.

Configure IP Settings

The virtual machine must have a static IP address and the primary DNS server must point to the on-premises domain controller.

Static IP Address

  1. Click on the network interface of your new virtual machine.
  1. Select IP configurations and click on the IP config to change the IP settings.
  1. Select Static and configure the IP address. Don’t forget to click save – a reboot may be required. You should never configure the static IP address on the VM itself as you do on-premises.
  1. Test if you can ping the VM from your on-premises domain controller and the other way around. If this isn’t working you can try the Network Watcher for troubleshooting.

DNS Servers

DNS servers can be configured on the virtual network or on the virtual machine itself. If configured on the vNet, everything that’s connected to this network will inherit these settings (you probably want this).

  1. Click on your virtual network to edit it’s settings.
  2. Select DNS and confire a custom DNS server (your on-premises domain controller).
  3. Don’t forget to click save and reboot the virtual machine.

After adding AD DC roles to the new VM we’ll come back to this page to change the DNS settings once more.

Active Directory Sites & Services

It’s important to create a new site with a corresponding subnet that whill contain your new domain controller. Clients will try to contact the domain controller in their subnet first so a misconfiguration can cause slow logons or other problems. If your on-premises subnet isn’t visible here you should create this one too!

  1. Open Active Directory Sites & Services on your on-premises domain controller.
  2. Right click Sites and select New Site.
  1. Name your new site and link it to the DEFAULTIPSITELINK. Click OK to complete.
  1. Right click Subnets and select New Subnet.
  2. Enter to correct prefix (your azure subnet that contains your virtual machine) and link it to the new site.
  1. Click OK to complete. You should end up with two (or more) subnets and two (or more) sites.

Install Active Directory Domain Services

  1. Start Add Roles and Features on the Azure VM.
  2. Add the Active Directory Domain Services role and all necessary features.
  3. Promote this server to a domain controller.
  4. Select Add a domain controller to an existing domain.
  1. Enter your domain name and click Select. Provide credentials with sufficient permissions. If you get an error that the wizard can’t find your domain, your DNS settings are probably incorrect.
  2. Select the correct site name and enter a DSRM password.
  1. Replicate from any domain controller.
  2. Change all paths to the 8GB partition (without caching).
  1. Leave all other options default or configure as required.
  2. Reboot the virtual machine.

Validate DNS Settings

DC on Azure

When the virtual machine is back online, it probably has static DNS servers configured – this happened because of the AD DC roles. Change this back to Obtain DNS server address automatically. Do this for both IPv4 and IPv6. you probably loose connection to the virtual machine.

DC on-premises

The preferred DNS server of your on-premises domain controller should be the domain controller on Azure. The alternate DNS server should point to itself. All other on-premises servers or clients should have the on-premises dc as preferred DNS server.

Virtual Network DNS Settings

The first DNS server should be the DC on Azure and the second DNS server should be the DC on-premises.

DNS Settings DC on Azure

The first DNS server should be the on-premises DC and the second DNS server should be the DC on Azure. Reboot your VM after changing this.

Validate this change on the VM itself by using ipconfig /all.

Azure AD Connect

Don’t forget to deploy a second pass-through authentication if you are using this. When using hash synchronization think about migrating your Azure AD Connect to the VM on Azure because it probably will have a greater uptime/SLA than your on-premises environment.


That’s all! Validate the replication by using repadmin & the event logs to be sure everything is working as expected. Don’t forget to backup the VM!

32 comments

  1. Thank you for the awesome explanation! This is the most thorough and straight forward tutorial I have seen on the subject! Thank you this was extremely helpful.

      1. Just to add one thing that I noticed when deploying the DC’s in an availability set is that I wasn’t able to control the primary DNS server on both servers even when setting custom DNS on the NIC. It seems that the same primary DNS server has to be used for both DC’s when using an availability set which is undesirable because both need the other DC as their primary. I have now deployed Availability zones to get around this but could be helpful to someone else as I had to delete the VM’s to remove them from the set which has cost me some time.

  2. Hi there, thanks for instructions. I am trying to implement this for my home lab on prem DC.

    I see that you set DNS Servers of the Azure DC VM to the IP of your local DC but I am not sure how that local IP e.g. 192.168.0.4 is visible to your Azure DC?

    I have P2S connection, established from my on prem DC.

    My on prem DC IP address is 192.168.20.20
    When I establish P2S VPN from on prem DC, The DC gets another IP from the VPN gateway subnet e.g. 172.16.0.5

    Now, my Azure vnet (where the azure AD is living has the following config)

    Address space: 10.1.0.0/16
    Subnets: default: 10.1.0.0/24
    Subnets: Gateway subnet: 10.1.1.0/24

    DNS Server: 192.168.20.20 – I set it this way according to this article but this IP is not reachable from the cloud. What am I missing please?

    1. Hi! When configuring a S2S Connection, you can configure your local networks in the ‘Local Network Gateway’. However, with a P2S connection the routes to the vNet (on Azure) are configured automatically – and it should work out of the box. Be sure you don’t have overlapping vNets (both in Azure, on-premises and the client address pool).

      Good luck!

  3. Great KB on how to deploy DC on Azure. Thank you. Just wondering, what ports would one need to open between on-prem and azure in order to allow successful AD replication?

  4. What if or local domain is one that we don’t own can I still set up a Azure domain controler. We own Multifeeder.com but they used mft.com to set up the local domain.

  5. Hi,

    Nice article, has anyone done anything with NTP? Do you change NTP on Azure domain controllers to an external time source or do people stick with the default which is the time from the Azure host (Microsoft’s default). The more I think about this the more I want to leave it at the default but I’m still not 100% convinced.

  6. Awesome explanation. However, I have one question can we create DC and AD UC services on AZURE itself without having any on premises DC. Because Azure AD seems to be expensive if you need MFA.

  7. Hi Jente,
    That’s an Amazing Document. Could you please elaborate on DNS configuration part? Why should I switch the DNS IP configurations on On-prem DC NIC properties and Azure NIC properties pointing on each other’s IP addresses ?

    Is it a mandatory configuration or this configuration is done just for DNS high availability ? What if I am replicating the Azure DC’s with more than 10 servers in my on-prem data center DC’s via my default AD site. Should I change the primary and Secondary DNS server IPs on all DC’s on the on-prem servers ?

  8. Hi, great article for deployment. Have any of you come into the scenario of implementing DHCP services on the DC, in Azure. We ideally want the DC to control address lease/ assignment. We across a GitHub article to implement a loopback adaptor local to the DC, pointing to Azure subnet. Any feedback would be appreciated.

  9. Hi,

    Am about to embark on setting this up to extend our on-prem AD into Azure.

    If we have an Azure private DNS zone, how can we add this to the domain controllers to allow resolution of the Azure private DNS zones from both on-prem and azure resources?

    Thanks

    Colin

  10. Hello Jente, I am following your instructions. I have gone through the step below after promoting my vm to a DC, When I have changed the DNS settings back to obtain DNS address automatically. I do lose connectivity. I am unable to get back on to the DC and restart it. Is there away of getting back onto the DC so I can reboot it without shutting down from Azure and reallocating the disk and then losing DC functionality?

    DC on Azure
    When the virtual machine is back online, it probably has static DNS servers configured – this happened because of the AD DC roles. Change this back to Obtain DNS server address automatically. Do this for both IPv4 and IPv6. you probably loose connection to the virtual machine.

    1. Hi David,

      Normally, if you change the DNS settings of a VM, you won’t lose connectivity. Maybe you changed the IP of the VM itself?
      When the static DNS is configured, you must change it to dynamic – to avoid conflicts.

      1. Hi Jente,
        Thank you for responding. here is the high level overview of the steps I have gone through when prompting Azure VM to Domain controller.
        VNet DNS settings pointing to on prem Domain Controller.
        VM (domain controller) static IP address set in Azure DNS settings not set.

        1. Promoted VM to DC server reboots as part of the promotion process.
        2. Once server is back up check DC NIC confirm IP address set to Dynamic but DNS populated with IP address of AD/DNS servers set in VNET.
        3. Change DNS settings to back to dynamic then lost of RDP session and can no longer reach DC via ping or use Azure serial console.
        Alternative steps 1, taken: everything up to step 2:
        I don’t change the DNS record on OS NIC to dynamic. leave as is change DNS settings on Azure VM nic to itself as DNS and alternative to DC on prem. Reboot Domain controller. Again unable to connect via RDP or ping or use serial console.
        Alternative steps 2, taken: everything up to step 2:
        I don’t change the DNS record on OS NIC to dynamic. leave as is change DNS settings on Azure VM I leave the VM nic as is so it picks up DNS settings from the VNet. Reboot Domain controller. Again unable to connect via RDP or ping or use serial console.

        Thanks
        David

    1. that’s what i’m also looking for, maybe with multi subscription and vnet sharing 😀

    1. As that is how you should set them on Azure VM. A bit different practice as for on-premise.
      One of the reason is to not lost the connection to VMs.

  11. Good to find a good article on this why I agree with after reading MS documents in length. It follows MS best practicies.

    Just out of interest. What are people doing for HA? Are more people doing Availability set or Availabuility zone? I think the latter is safer and a better option. Howver, I am seeing an awful lot of articles online make mention of availability sets only. I think is the case because availability zones have been available in Azure a lot lnger? Zones are safer because it protects you in the event a data center goes down. AS protects you in the event a rack is down.

    Is it one or the other? I just don’t get why you would use Availability Zones if it offers less protection. Even in this article it states use one or the other.

  12. Availability set or zone or both? I dont understand why anyone would use availability sets. Seems a tad obselecte now with availability zones which offer less proection. Do you agree? I see an awful lot of dics still talk about availability sets. This is protection if a rack goes down only. Availability zone prtects you in the event f a data cenmter in same region going down. Sure this is the better option. Can you use both?

Leave a Reply

Your email address will not be published.