Active Directory Considerations in Azure Virtual Machines and Virtual Networks – Part 6 – Name Resolution and Geo-distribution

  • Article

imageThis is the end, the end, beautiful friend, this is the end, my only friend, the end. Did you think this series would never come to an end? It has. This is the last post in our blog series on Active Directory considerations for Azure Virtual Machines and Virtual Networks. Cloud and Datacenter Solutions Hub

In the first part of this series on Active Directory considerations in Azure Virtual Machines and Virtual Networks we talked about Hybrid cloud and how you can leverage hybrid cloud to extend you corporate network. In the second part, we went over some Azure Virtual Machines and Virtual Networks basics so that you had a foundation on which you could understand some of the Active Directory issues. In the third part of the series we looked at the question of whether or not it was safe to put domain controllers in Azure Virtual Machines and Virtual Networks and where you should put Active Directory related files. In part 4, we talked about the role of read-only domain controllers. In the fifth post, we talked about the types of domain controllers you might want to put in an Azure Virtual Network and the role of the Global Catalog service in Azure IaaS. If you missed any of these, you can find the one you want to go to from the list below:

In this post, the last of the series, we’ll take a look at name resolution in the Azure IaaS cloud and how you might handle geo-distribution for domain controllers.

Azure Virtual Networks has its own DNS services that it provides you when you put new virtual machines in a Virtual Network. This is very basic name resolution that allows machines on the same virtual network to resolve each other’s names. While this is useful if all your machines and services running on those machines are only dependent on each other, it’s not enough to support an Active Directory environment. If you want to implement Active Directory authentication for the services running on the Azure Virtual Network, you’re going to need more.

The reason for this is that Azure Virtual Networks do not meet the complex name resolution requirements for Active Directory domains, such as dynamic DNS registration and SRV record support, as well as other Active Directory related DNS requirements.

DNS has always been, and continues to remain as a critical configuration item for Active Directory domain controllers and domain joined hosts. Domain controllers and their clients must be capable of registering and resolving resources within their own domains and forest, as well as across trusts. And since static addressing isn’t supported in Azure Virtual Networks, these settings must be configured within the Virtual Network definition.

How do you do this? Consider the following approach:

  • Create an Azure Virtual Network
  • Use DHCP for addressing for any domain controllers you plan to put in a Virtual Network
  • Install and configure Windows Server DNS on the domain controller(s) you’ve placed in Windows Azure
  • Configure the domain controllers and the domain members’ DNS client resolver settings so that
        1. The on premises DNS server is set as the primary DNS preferred DNS server and
        2. An alternate DNS server that is the IP address of a domain controller that is also a DNS server on the Azure Virtual Network

We’ll finish up here with a short discussion on geo-distributed, Azure Virtual Network hosted domain controllers. Azure Virtual Machines and Virtual Networks provides an attractive options for geo-distributing domain controllers, as we’ve talked about a couple of blog post ago. They can provide:

  • Off-site fault tolerance
  • Lower latency for branch offices where you don’t want to house the domain controller on premises

However, keep in mind that virtual networks are isolated from one another. If you want these Virtual Networks to communicate, you’ll need to establish site to site links with each of them and then have them loop back through the corporate network to reach other Azure Virtual Networks. This means that all replication traffic will route through or off on premises domain controllers, which is going to generate some egress traffic. You will want to pilot a configuration to see what your egress numbers look like before a full blow geo-distributed architecture.

Summary

In this final blog post in our series on Active Directory considerations in Azure Virtual Machines and Virtual Networks we took look at DNS considerations and then talked briefly about geo-distribution. I hope you enjoyed this series and learned a couple of things. Keep in mind that Azure is continuously evolving and what is true today might not be true tomorrow, as new and enhanced capabilities are being built into the system. This series was based on pre-release, community preview Azure Virtual Machines and Virtual Networks and I’m sure there will be improvements that I haven’t mentioned here. When general release becomes available, I’ll do a post on these improvements and see how they related to our conversation.

Finally, for more information about Active Directory considerations in Azure Virtual Machines and Virtual Networks, please see Guidelines for Deploying Windows Server Active Directory on Windows Azure Virtual Machines.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, SCD iX Solutions Group
Follow me on Twitter: https://twitter.com/tshinder
Facebook: https://www.facebook.com/tshinder
image

Go Social with Building Clouds! Building Clouds blog Private Cloud Architecture Facebook page Private Cloud Architecture Twitter account Building Clouds Twitter account Private Cloud Architecture LinkedIn Group Cloud TechNet forums TechNet Cloud and Datacenter Solutions Site Cloud and Datacenter Solutions on the TechNet Wiki