Last month in Active Directory: Windows Server or Windows Azure, I gave an overview of the different ways you can configure 14-year-old Windows Server Active Directory with 1-year-old Azure Active Directory. In this and future posts I’m going to dive a little deeper into each configuration and its major use cases. Though it doesn't directly use Azure Active directory, today I’m going to focus on the scenario where a Windows Server Active Directory forest is both on premises and extended into a public IaaS cloud.
Windows Server Active Directory in IaaS
Before I go any further I want to (again) clear up some naming confusion. The Active Directory role installed on a Windows Server is technically known as Active Directory Domain Services (AD DS). However, when AD DS is referred to as a component of Microsoft’s hybrid cloud architecture, Microsofties have begun calling it Windows Server Active Directory even though this term technically encompasses other Windows Server roles such as Active Directory Certificate Services. Therefore, when I talk about Windows Azure Active Directory vs. Windows Server Active Directory just think of AD DS for the latter.
One of the basic capabilities of a public IaaS cloud is that you can connect it to your on-premises network, thus providing a hybrid environment where local resources can access cloud resources and vice versa. You can of course have an on-premises IaaS private cloud, but for the sake of clarity I'm sticking to just the public scenario. (The different ways you can connect an on-premises network to a public cloud vary from vendor to vendor and are outside the scope of this article; what counts is that you have cross-network connectivity.)
With this connectivity you can create a VM inside your IaaS environment, point its DNS client to on-premises DNS servers, join an on-premises AD forest, and promote this IaaS VM to a domain controller. You now have an AD forest that spans both on-premises and IaaS cloud environments (Figure 1).
Alternatively, you could create a new AD forest with the IaaS DC VM and connect it to the on-premises forest with a forest trust (Figure 2):
Use cases
Why would you want to put domain controllers for on-premises forests into an IaaS cloud? The primary use case for this configuration is to provide AD services for legacy application VMs that are also in the cloud. By “legacy”, I don’t mean the apps are obsolete; I mean the apps require a traditional AD domain and associated infrastructure (supported by IaaS) rather than web services with RESTful APIs (supported by PaaS). These services include authorization, group policy, and some authentication.
In this hybrid configuration, you may want to configure these VMs into one or more AD sites containing IaaS subnets to take the WAN link connecting your on-premises datacenter and the IaaS cloud into account. If your IaaS DCs have no awareness of these network differences, AD-related traffic for IaaS application VMs may not choose the IaaS DCs you’ve built nearby.
I want to squeeze in another configuration I didn’t include in the original article: Windows Server Active Directory standalone in an IaaS cloud. In this configuration, domain controller VMs have no connection to any on-premises resources. An obvious use case for this is a development or test environment (which I use myself).
Considerations for this configuration
Each IaaS cloud vendor has its own idiosyncrasies related to VM connectivity. For example, you must not assign an Azure VM a static IP address because it may eventually result into a complete loss of connectivity to the VM. Until recently the only way you could ensure an Azure VM received the same IP address (a best practice for a DC) was to put it on its own Azure virtual network. You can use this workaround, but recently it’s become possible to assign an Azure VM the equivalent of a DHCP reservation via PowerShell. Microsoft has a very thorough article on guidelines for deploying Windows Server Active Directory on Azure VMs, and longtime Active Directory guru John Craddock has an excellent session on running AD in Azure from Tech Ed 2013.
I strongly recommend that you run Windows Server 2012 or R2 on your IaaS DCs because Active Directory on these newer operating systems is far more virtualization tolerant. Note, however, if you try to run the Active Directory installation wizard on a Windows Server 2012 or R2 DC in the cloud with the purpose of adding it to your existing Windows Server 2008 / R2 forest, the Windows Server 2012 / R2 forest prep and domain prep upgrade functions will automatically be executed as part of the promotion process. This is not something you want to be surprised with in a production forest!
If you need to provide AD services in an IaaS cloud but are leery of any password hashes leaving your datacenter (as would happen with a full, read/write DC), consider a read only DC (RODC). Among its other capabilities, you can configure a RODC to filter AD attributes stored on it. The most common example of this attribute filtering is to never store password hashes locally on the RODC; in this case, the authentication request is forwarded to the nearest RWDC (in this case, on premises) to perform the operation.
Putting production forest domain controllers in a public IaaS cloud is a first step towards a unified, hybrid on-premises / cloud environment – and a mandatory one if you plan to make your current production applications mobile between the two. Why? Because IaaS is the least disruptive, logical first step into off-premises cloud computing. To take advantage of the PaaS programming model, most applications must be redesigned and rewritten; IaaS can support the VMs you have today.
In my next post I’ll outline a complicated, three-way hybrid environment that many enterprises will soon find themselves contemplating.
Sean writes about cloud identity, Microsoft hybrid identity, and whatever else he finds interesting at his blog on Enterprise Identity and on Twitter at @shorinsean.
