Configuring Azure AD Domain Services with Vnet peering.
The following is a demonstration designed to configure Azure AD domain services and directory services with multiple virtual networks.
The Environment and Architecture:
Azure Active Directory
- A stand-alone directory with the domain ravsalgado.com added and verified.
- The enterprise account is rav_salgado@****.com
- Azure only user globaladmin@ravsalgado.com.
Resource groups and Virtual Networks.
Resource Group: Ravsalgado_primary_RG1_Central
- Vnet:Primary_RG1_Central_Vnet
- Address Space:192.168.0.0/25
- PRG1_SubnetA: 192.168.0.0/27
- PRG1_SubnetB:192.168.0.32/28
Resource Group: Ravsalgado_Secondary_RG2_Central
- Vnet:Secondary_RG2_Central_Vnet
- Address Space:10.1.0.0/26
- SRG2_SubnetA: 10.1.0.0/28
Resource Group: Ravsalgado_Secondary_RG1_East
- Vnet:Secondary_RG1_East_Vnet
- Address Space:10.0.0.0/26
- SRG1_SubnetA: 10.0.0.0/28
Deploying Azure AD Domain Services
The basic steps for setting Azure Domain services can be found here . I would like to draw attention to a few key factors not mentioned in the documentation.
One key factor here is that Domain services resources are going to be set up on:
- A particular virtual network
- A particular subnet.
These resources for Azure Domain Services are:
- Two Network Interfaces, (Which I believe is for the microservice or container that’s running e DNS service)
- A load balancer
- An NSG that is applied to the subnet that holds the Azure Domain service resources.
- A public IP address that is associated with your domain.
Password hash synchronization to Azure Active Directory Domain Services.
Azure Active Directory Domain Services needs password hashes in a format that’s suitable for NTLM and Kerberos authentication. Azure AD does not generate or store password hashes in the format that’s required for NTLM or Kerberos authentication, until you enable Azure Active Directory Domain Services for your tenant
This is a crucial step in making sure that the domain admin users you will be using (globaladmin@ravsalgado.com) to add a VM to your domain, authenticates without any issues. The steps for hash synchronization for Azure online-only users and on-prem synchronized users can be found here
DNS IP internal.
One of the other crucial factors is that once you deploy Azure Domain Services in a subnet, two internal IP addresses are assigned to the sudo DNS server. As such when network peering is done with other virtual networks it’s important to assign these internal DNS server IP addresses to the DNS service Ip address on each of the peered virtual network.
Virtual Network Peering
Instructions on how to establish vnet peering can be found here. I configured the configurations with global and local vnet peering successfully and established a connection from both the primary and secondary vnets.
You would also need to consider the implications for design if you hope to isolate your resources and protect them using a Network appliance or Azure firewall.
Note that in this scenario the firewall can only be deployed in the same region as the vnets you peer to. Global peering for Azure firewall is currently not supported.
Once this step is complete your VMs in each of the Secondary virtual networks can be added to the domain without any issues.
Feel free to let me know if you run into any issues or have any questions with the confuguration.
