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:
- Active Directory Considerations in Azure Virtual Machines and Virtual Networks Part 1 – Hybrid IT
- Active Directory Considerations in Azure Virtual Machines and Virtual Networks Part 2 – Azure Virtual Machines and Virtual Networks Basics
- Azure Virtual Machines and Virtual Networks Part 3 - Virtual DCs and AD File Placement
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:
- Redundancy – you can put backup domain controllers into the cloud
- Disaster Recovery – you can continue operations even if one or more main sites go down using an Active Directory infrastructure in the Azure Virtual Machines and Virtual Networks cloud
- Decrease latency for log ons – you can provide remote branch offices with closer access to Active Directory services without the risk of putting them on premises at the remote locations
- Support applications in the cloud that have Active Directory dependencies
There are surely more reasons, but these are a few to get your started.
Read Only Domain Controller Advantages
There are also several options available to you when you think about putting Active Directory in the Azure Virtual Machines and Virtual Networks cloud:
- Full read/write domain controllers in a production domain
- Full read/write domain controllers in a trusting domain or forest
- Read-only domain controllers in the production domain
- Read-only domain controllers in a trusting domain or forest
- No domain controllers at all, and you use Active Directory Federation Services
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:
- They support Windows integrated authentication
- They do not replicate outbound, which is good since outbound traffic is what you pay for
- They do not support inbound replication, which is what you pay for
- They do not possess every secret – only those that are cached, if you choose to use that model
- They enable you to filter attributes, so if there is PII included, you can make sure to filter those attribute that you do not want available on the RODC
Drawbacks to consider with read-only domain controllers in Azure Virtual Machines and Virtual Networks:
- Read-only domain controllers do not support all Active Directory dependent applications. That means that you’ll need to do some testing to determine if they are the right solution for the application you want the RODC to support. This could potentially influence the potential cost effectiveness of the RODC solution.
- If the site to site VPN that connects Azure Virtual Machines and Virtual Networks to your on premises network goes down, you will not be able to authenticate users.
- There are costs related to running the gateway. If the application that depends on the Azure Virtual Machines and Virtual Networks located RODC needs to be always available, then the gateway needs to be available too and that will incur additional costs
For more information on attribute filtering and credential caching, please see RODC Filtered Attribute Set, Credential Caching, and the Authentication Process with an RODC
Issues with DC locator and the inter-site topology generator and messenger
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:
- A collection of subnets defines a site
- You connected the sites together using site-links
- You can then create replication policies
When creating replication policies, consider the following:
- How frequently do you want replication to take place? If you put a read/write domain controller into Azure Virtual Machines and Virtual Networks, then inbound replication events are going to increase the cost
- What days of the week do you want replication to take place? Fewer days, lower cost
- Make sure that you do create replication policy based on when you want them to take place, and not have them be event-driven, as this can also run up the costs.
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.
Summary
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!
HTH,
Tom
Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, SCD iX Solutions Group
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder