Introduction
When organisations embark on their cloud adoption journey, it can be a daunting task and difficult to decide where to begin. Utilising Microsoft’s Cloud Adoption Framework (CAF) is always a good starting point to get familiar with the concepts that will be critical during the cloud transformation journey.
Whether Azure will be used to host important business applications or Disaster Recovery purposes, a topic that will always prevail is Active Directory. How should you extend your on-premises Active Directory to Azure and why should you even care? These are the questions that will be covered in this blog post.
Reasons for extending AD into Azure
There are many reasons why you might want to place Domain Controllers (DCs) in Azure, but below are some of the common reasons:
- Disaster Recovery – If DCs become unavailable on-premise, then traffic can be routed to Azure to ensure clients can still authenticate and communicate with the core network.
- Latency – When Virtual Machines (VMs) need to be stood up in Azure, then most likely they will need to be joined to the corporate Windows domain to ensure policies and regulations are being filtered to Azure. For this to function correctly, traffic will be transferred across the VPN tunnel, which can increase latency and Azure running costs. This is why placing DCs in Azure is a sensible approach to mitigate these issues.
- VPN Gateway Reliance – If there are service interruption issues with the VPN Gateway, then any member servers sitting in Azure will be unable to successfully authenticate.
- Ingress/Egress Traffic – Without DC presence in Azure, all traffic will be traversing via the VPN tunnel which will ultimately add strain on the site-to-site tunnel and increase Azure running costs.
Architecture Diagram
In the below diagram and scenario, a hub and spoke model has been utilised to separate the core workloads. The DCs have been placed in vnet2 which is peered with the hub network (vnet1). The application tier lives in vnet3 which will communicate with the DCs via the hub network.
Prerequisites
- VPN Gateway – A site-to-site VPN tunnel must exist between on-premises and Azure. For a detailed tutorial on how to achieve this, please view Microsoft’s documentation here. The exact method on
- Azure Subscription – You must have an Azure subscription already established in Azure. This can be created as a PAYG subscription or via an Enterprise Agreement depending on your forecasted spend with Microsoft.
- Virtual Networks – The VNETs must be appropriately split out to ensure optimal security. The hub network contains a VPN gateway and Azure Firewall for additional security.
- Availability Set – In vnet2, an availability set has been created to protect against Azure data centre upgrades.
- Virtual Machines – Two DC VMs have been created. The exact VM size is not something often raised or discussed in Microsoft documentation. AD DS and DNS are not resource hungry so a VM with 4GB and 2 cores should be sufficient. In particular, opting for a B2s VM will do the job. Remember, VM sizes can easily be scaled up and down depending on performance.
- Active Directory Domain Services – AD DS will need to be installed on the VMs. It is advised that the VMs should function as normal DCs. You won’t need to consider a Read-Only DC, as this is only used where the physical security can’t be guaranteed. In this scenario, the Azure estate is considered an extension of the corporate network, thus the security is guaranteed and controllable. It’s a good idea to keep the FSMO roles on the on-premises AD only.
Cloud Adoption Framework & Technical Considerations
When deploying any service in Azure, it is always helpful to keep CAF in mind. As this scenario deals with DCs in the public cloud, there are additional considerations that you will need to think about. Below is a list of some of the important factors to bear in mind:
- Network Security Groups (NSGs) – The DCs will need to be protected by NSGs at the subnet level. Only the necessary ports required for AD replication and communication will need to be opened. Please see a list of ports here.
- Resource Groups – It is strongly recommended to place the DCs in their dedicated resource group. This will allow security administrators to grant access to relevant personnel via Role Based Access Control (RBAC).
- RBAC – The IT team will need to start considering what the RBAC list needs to look like. Will it duplicate the access level on-premises? or will a new Azure maintenance team be stood up to support Azure?
- Azure Backup – What will the backup process be for backing up the DCs? It’s recommended to utilise Azure Backup for VM backup.
- Windows Image – Which Windows OS will be deployed in Azure? Does it need to match on-premises? This will heavily rely on the domain and forest functional levels and what’s compatible. Please see here for additional information.
- Update Management – The maintenance team will be interested in how the DCs will receive windows updates. Azure Update Management can be considered to relieve stress on the VPN tunnel (if an on-premise solution is being used e.g. WSUS).
Where possible, it’s advisable to consider Azure services for tasks like backup and update management. But this does rack up the costs. Please use the Azure pricing calculator to estimate the monthly spend and involve key stakeholders during this process.
Deployment Tasks
Unfortunately I don’t have a test Windows environment currently, as a result I’m unable to list step by step instructions with screenshots on how to configure and setup Active Directory. The below table lists the exact tasks that you will need to follow to achieve the desired architecture:
ID | Task Details |
---|---|
1 | Availability Set Create Azure availability set in Azure (UK South) to house the DCs |
2 | Azure AD DS Deployment Deploy two windows server images into the availability set (UK South). Assign static IP addresses to VM (within Azure). VMs to be deployed to the infra subnet. |
3 | Network Connectivity Assign static IP addresses to both VMs (within Azure). Configure NSG and Azure Firewall in infrastructure subscription (infra subnet) to allow communication between on-premises and Azure hosted domain controllers. |
4 | Active Directory: New Site Configuration On-premises AD – create a new site called “Azure” in Active Directory Sites and Services. |
5 | Active Directory: Create and configure new Site Link Create a site link between Azure VMs and on-premise DC. Name the site link something relevant. E.g., On-prem-to-Azure Associate the site link with the subnets defined in Azure. Also include the address space of additional VNETs in Azure. This way, workloads situated in other VNETs will successfully communicate with the DCs in Azure. |
6 | AD DS Installation Install and configure Active Directory Domain services on both VMs in Azure. |
7 | Anti-Virus Configuration Depending on the windows server operating system deployed, additional exclusions might need to be configured to allow the domain controllers to function correctly. Please see here for details. |
8 | Custom DNS settings in Azure Update VNET to utilize custom DNS and point to on-premises DNS IP as primary and list the Azure DNS server as the secondary address. |
9 | Test successful replication Perform tests to ensure that the domain controllers in Azure are functioning as expected. Test interval and general AD health checks. |
Note: It’s important to get the Active Directory Site link and configuration correct, this will ensure that the correct subnets in Azure are only allowed to communicate with the DCs situated in Azure.
Wrap Up
This post discusses the main considerations when it comes to extending on-premise Active Directory to Azure. It’s not as simple as just deploying a couple of VMs and installing AD DS on them. The considerations section highlights some of the main foundational points when it comes to CAF and Azure. The correct design, security and ongoing maintenance of the DCs will be imperative for a happy cloud journey.
If you have any questions regarding this post, please feel free to leave a comment or contact me directly for additional support.