Putting an Active Directory domain controller in the Azure cloud
Cloud Director
Since Azure 2010 achieved production maturity, much has happened on Microsoft's cloud platform. Continuous innovations see the service rapidly growing, and administrators can choose from a variety of goodies from the Microsoft portfolio of new technologies. What looks so simple at first glance can turn out to be tricky when it comes to the details.
One popular option is to integrate cloud resources with existing infrastructure in a hybrid configuration. A hybrid network lets you keep your most essential core resources close and local, while still enjoying the benefits of a cloud for scaling to meet demand.
Once you get a significant part of your network up in the cloud, you might be wondering if you can put an Active Directory domain controller in the cloud also to facilitate authentication for cloud resources and act as a backup for local domain controllers (DCs).
This article shows how to get started with adding a domain controller to your Azure configuration.
Confusion with Portals
Azure offers two management portals: the classic model and the resource-based model [1]. The older model is the classic deployment model. Certain activities, such as Azure Active Directory, can only be managed from the classic model. The model for the resource manager has been around since 2014, and it was long dubbed the "Preview Portal." Since last year, according to Microsoft, the resource manager portal is now the preferred portal.
Of course, the services acquired for a subscription can extend across both models (portals); however, mixing the models makes management more difficult, because you won't be able to manage everything through a single interface.
Servers in the Cloud
Virtual servers are likely to be one of the most widely used technologies in Azure. There are many possible ways to deploy them, either through one of the portals or PowerShell or by using the cross-platform command-line interface for Windows, Linux, and OS X.
You can select an image from the predefined catalog. Some images feature an application, such as SQL or SharePoint. You can expand the catalog of available images with your own creations and launch new servers based on your personal images, prepared with Sysprep, then upload these images as VHD files to Azure [2].
Pay attention to what you call the components you add to your cloud network. As your network grows, you'll find it much easier to navigate if you use a naming convention that gives a shorthand description of the resource. See the box titled "Naming Conventions" for more on naming servers and other resources in Azure.
Naming Conventions
When you create objects in Azure, the portal often suggests a name. These autogenerated names are anything but intuitive and do not really help you orient. If your cloud configuration includes several servers and other cloud-based components, it makes sense to think in advance about a naming convention.
If you have multiple subscriptions and distribute the Azure components across them, it might make sense to include the name of the subscription as part of your naming strategy. If your environment is global, it may be beneficial to include the region in the naming schema. Also, resource groups can be an important indicator for your conventions. A resource group is a configuration container that includes virtual machines and other components. You can then perform activities for all items belonging to the resource group.
As you can see from these few examples, the naming scheme is not easy. Familiarize yourself with the elements in Azure. If you know which components are important for you, that is, what your infrastructure requirements look like, you will find it easier to develop naming conventions. See the Azure Infrastructure Services Implementation Guidelines for more information [3].
Extend On-Premises AD toward Azure
Suppose you want to extend your local Active Directory (AD) to work with Azure. The target is an AD site that is based on a subnet in Azure – along with a DC in Azure, provided by a local VM. Keeping a domain controller in the cloud allows your cloud-based servers to authenticate without having to take a long detour across the WAN. Also, if the DC in the local data center even goes down, the Azure DCs can still authenticate via the site topology.
Interestingly enough, setting up an AD site in Azure by placing your own DCs there has nothing to do with Azure Active Directory (AAD). AAD is a separate service that holds identities for Office 365 and gives the administrators in Azure roles and rights for Azure work. The scenario presented in this article is not concerned with AAD but with creating a replica of the local AD in Azure.
First, you need to check out your AD and decide whether your environment is suitable for the extension to Azure. This is what the "Virtual Machine Readiness Assessment Test" [4] does; you need to answer a couple of questions at the beginning (Figure 1). Armed with the information you provide, the tool checks to see whether the local scenario matches your plans. Among other things, the assessment test examines the network connection and tests the health of the domain controller using dcdiag (Domain Controller Diagnosis). The test is also suitable for a SQL or SharePoint setup. The result of the test is summarized in a Word file, which also provides links to further information.
Buy this article as PDF
(incl. VAT)