...building hybrid clouds that can support any device from anywhere
Are we at part 4 already? Wow! Not sure how many more parts there are going to be, but I’m hoping it will end up being less than 10. As of now, we have three parts in the can – the first part was about hybrid IT and what hybrid IT brings to the plate. The second part was about the basics of Azure Virtual Machines and Virtual Networks. Part 3 then started talking about issues related to whether or not it was safe to virtualize domain controllers and where you should put Active Directory related file on Azure.
If you missed one or more of the articles, refer to the list below:
This article and the next will be the most challenging of those done so far, as there are a lot of Active Directory considerations that we make on premises that might work differently in the cloud. Hopefully, I’ll be able to do some justice to this subject.
To begin the conversation, let’s think about why we would want to put Active Directory into the Azure cloud. While by no means a comprehensive list, here are some of the reasons why you would want to do so:
There are surely more reasons, but these are a few to get your started.
There are also several options available to you when you think about putting Active Directory in the Azure Virtual Machines and Virtual Networks cloud:
We will talk more about each of these options from a security in the next installment of this series, but now let’s focus on read-only domain controllers.
In a hybrid IT environment, you might think about the Azure Virtual Machines and Virtual Networks component as being similar to a branch office, or off premises hosted datacenter. If so, it would make sense to take advantage of read-only domain controllers. Read-only domain controllers have several features that make them a preferred solution in a hybrid IT environment:
Drawbacks to consider with read-only domain controllers in Azure Virtual Machines and Virtual Networks:
For more information on attribute filtering and credential caching, please see RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC
When putting domain services in the cloud, you need to think about how to correctly define and connect Active Directory subnets and sites – as these considerations will influence the cost of the overall solution.
Sites, site-links and subnets affect who authenticates where and also the domain controller replication topology. A refresher on these issues:
When creating replication policies, consider the following:
One option available to you is to define the Azure network ID that you’re using as a subnet in Active Directory and then machines on that subnet will use the local domain controller for authentication (assuming that they are available). This avoids services in Azure Virtual Machines and Virtual Networks from having to reach on premises for authentication services. This also reduces cost, since if the service in Azure Virtual Machines and Virtual Networks had to authenticate using on premises domain controllers that would generate outbound traffic, which you need to pay for. For more information on Active Directory sites, please see Active Directory Sites.
You want to make sure that you set costs on the links such as it’s clear that Azure Virtual Machines and Virtual Networks is a much higher cost link. You want to make sure that when the issue of “next closest site” falls into play that the Azure Virtual Machines and Virtual Networks domain controllers are not considered to be the next closest (unless that’s what you want to intend, such as in the case of remote offices using a domain controller in Azure Virtual Machines and Virtual Networks as a backup). For more information on this issue, please see Enabling Clients to Locate the Next Closest Domain Controller.
Active Directory replication also supports compression. The more compressed the data are, the lower the network costs are going to be. For more information on Active Directory compression, please see Active Directory Replication Traffic.
Finally, consider putting together your replication schedule based on anticipated latency issues. Remember that domain controllers replicate only the last state of a value, so slowing down replication saves cost if there's sufficient churn in your environment.
In this article we took a look at what options you have for putting domain controllers in the Azure Virtual Machines and Virtual Networks, with a specific focus on the advantages of using read-only domain controllers in a hybrid IT scenario. Then we talked about some issues regarding subnets, sites, site-links and replication policies and issues to consider when putting Active Directory services in Azure Virtual Machines and Virtual Networks. In the next part of the series, we’ll talk about issues related to global catalog and also consider some of the security considerations for different Active Directory deployment scenarios in Azure Virtual Machines and Virtual Networks. See you then!
Tom Shinder firstname.lastname@example.org Principal Knowledge Engineer, SCD iX Solutions Group Follow me on Twitter: http://twitter.com/tshinder Facebook: http://www.facebook.com/tshinder
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
I'm wondering if you have a typo. In the section about RODC's you say:
"They do not replicate outbound, which is good since outbound traffic is what you pay for"
Then you say:
"They do not support inbound replication, which is what you pay for"
Surely this second statement is incorrect? RODC's do support inbound replication, and if located in Azure, you do not pay for inbound replication?
Indeed a typo! Thank! I'll fix.
Awesome article as always Tom!
Great article. I wondered if you would consider expanding on this to talk about deploying ADFS and the ADFS Proxy on Azure IaaS as a failover for an on-premise ADFS infrastructure. There is some limited MSFT guidance on this, but it is lacking. You always address things from a real world perspective and don't gloss over 'issues'. We are specifically concerned about how to deploy the ADFS/ADFS Proxy components given Azure's currently limited networking capabilities.