Part 9: Deploying a Domain Controller in Azure and Integrating It

Many organizations are embracing hybrid architectures, extending their on-premises Active Directory into Azure for better resiliency and to support cloud-based workloads. Now that our AD DS environment is running on Windows Server 2025, it’s an ideal time to integrate a domain controller in Azure. This provides a geographically separate DC (great for disaster recovery) and local authentication for Azure-hosted VMs or services. We’ll walk through best practices like Azure networking setup, AD site configuration, and ensuring security for this cloud DC.

Preparing the Azure Environment

Azure Network Connectivity:
To allow an Azure-based DC to communicate with on-prem AD, you need network connectivity—typically a Site-to-Site VPN or ExpressRoute. For this guide, we assume a Site-to-Site VPN is in place, with the Azure VNet (e.g., 10.1.0.0/16) connected to the on-prem network (e.g., 192.0.2.0/24). Ensure firewall rules allow DC communication (LDAP, Kerberos, SMB, RPC, etc.).

Azure VM Setup:

  • Image: Windows Server 2025 Datacenter
  • Size: At least B2ms or D2s_v3 (2 vCPU, 8GB RAM)
  • Disk: Premium SSD
  • Network: Use a VNet/subnet connected to on-prem. Optionally, create a dedicated subnet for DCs.
  • Public IP: Don’t assign one – use private IP via VPN only.
  • NSG (Security Group): Restrict traffic. Allow DC-to-DC and admin RDP (via VPN or Bastion).
  • Hostname: Something like AZDC01
  • Static IP: Assign a static private IP (e.g., 10.1.0.4). Do this in Azure NIC settings.
  • DNS: Update the VNet DNS settings to use the on-prem DC IP(s), then add the Azure DC’s IP after promotion.

Promoting the Azure VM to a Domain Controller

Domain Join (Optional):
Join the VM to your domain using the GUI or:

Add-Computer -DomainName "CONTOSO.COM" -Credential (Get-Credential CONTOSO\Administrator)

Restart-Computer

#Install AD DS Role:

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

#Promote to DC:

Install-ADDSDomainController `

-DomainName "CONTOSO.COM" `

-SiteName "AzureSite" `

-InstallDns `

-Credential (Get-Credential "CONTOSO\Administrator") `

-SafeModeAdministratorPassword (ConvertTo-SecureString "YourDSRMpassword" -AsPlainText -Force)

Ensure replication succeeds using repadmin /showrepl AZDC01. If there are issues, check firewall and VPN.

DNS Integration:

  • This DC will receive DNS zones via replication.
  • Update the VNet DNS server list to include this DC’s IP.
  • On the Azure DC, set its NIC to use itself for primary DNS and a backup on-prem DC for secondary.

Global Catalog:
Ensure it is a GC (default is yes). Check using AD Sites and Services.

Active Directory Sites and Services Configuration

  • Create Site: Name it something like “Azure”.
  • Create Subnet: Match Azure VNet range (e.g., 10.1.0.0/16).
  • Move Server Object: Ensure the new DC’s object is placed under the Azure site.
  • Replication: Default replication via DEFAULTIPSITELINK is every 180 minutes. Adjust as needed (e.g., to 15 minutes).

This setup ensures Azure resources use the Azure DC, while on-prem clients use their local DCs.

Benefits and Use Cases

  • Provides redundancy if on-prem goes down.
  • Enables local auth for Azure VMs and apps.
  • Reduces cross-VPN authentication traffic.
  • Supports hybrid apps like Azure Files or AD-integrated services.
  • Enables closer placement of Azure AD Connect (if applicable).

Security Best Practices

  • Enable Azure Disk Encryption with BitLocker.
  • Avoid public IPs or open RDP ports.
  • Use Azure Bastion or VPN for management.
  • Enable regular Azure Backup.
  • Monitor logs and replication health like other DCs.

Verification Steps

  • From an Azure VM, run:

 

nltest /dsgetdc:contoso.com /Server:AzureVMName

#It should return the Azure DC.

#Simulate on-prem outage by disabling VPN and verifying Azure VMs still authenticate.

#On on-prem clients, check they don’t use Azure DC accidentally:

 

nltest /dsgetsite

nltest /dsgetdc:contoso.com /Site:OnPremSiteName

Time Sync Warning

Azure VMs often use the host’s clock (which can drift). Disable time sync integration and ensure the Azure DC uses domain time. Verify by running:

w32tm /query /source

It should point to the domain’s PDC Emulator, not “Local CMOS Clock” or Hyper-V integration service.

Real-World Insight

We’ve seen major reliability gains when deploying an Azure DC. For example, a cloud backup server that was previously VPN-dependent started querying AD locally, reducing backup errors and improving speed. However, we also saw issues where time skew caused Kerberos failures—disabling host time sync and letting the Azure DC follow the domain hierarchy resolved the issue. Always test time and replication carefully.

We’ve achieved a resilient hybrid AD configuration with an Azure-hosted DC that is now in play. In Part 10, we’re ready to raise the forest and domain functional levels to Windows Server 2025.

Cristal Kawula, Checkyourlogs.net