I85PREP
⌘ K
Azure AZ-800 study materials
Azure AZ-800 study resources

Contoso - Placing Domain Controllers in Azure Without Leaking Authentication Across the VPN

Azure AZ-800 · Put your knowledge to work in context.

All case studies

Contoso - Placing Domain Controllers in Azure Without Leaking Authentication Across the VPN

Contoso has one AD forest and one domain, corp.contoso.com, with two domain controllers: DC01 in Amsterdam and DC02 in Dublin. All five FSMO roles are on DC01. Both DCs are global catalogs and run DNS; every client and server in the company points to DC01 as its primary DNS server and DC02 as secondary.

Thirty Windows Server VMs run in an Azure VNet (10.50.0.0/16) and are joined to the domain. They use the on-premises DCs for DNS across a site-to-site VPN. Last month the VPN tunnel was down for six hours; users on the Azure VMs could not sign in and applications that query AD failed. No AD site was ever defined for the Azure address space. Contoso wants domain controllers in Azure so the workload survives a WAN outage, and it must be certain that on-premises clients never authenticate against those new DCs over the VPN.

1. Design the domain controller placement and the AD site topology. State exactly what you create and why each piece is required.

Read the worked answer

Placement

  • Deploy two DCs in the Azure VNet, in separate availability zones (or an availability set if the region has no zones). One DC is a single point of failure for both Kerberos and DNS, which is exactly the failure mode they just had.
  • Make both new DCs global catalogs and DNS servers. The Azure VMs must never need to reach on-premises to resolve or authenticate.

Site topology (this is the part that answers "don't let on-prem clients cross the VPN")

  1. Create site Azure-Prod.
  2. Create a subnet object for 10.50.0.0/16 and bind it to Azure-Prod. Without a subnet object, the Azure VMs fall into the default site (Amsterdam), and the DC locator will happily hand out on-prem DCs.
  3. Create a site link containing Azure-Prod and name it with a higher cost than the existing on-premises site links.
  4. Create site and subnet objects for the Amsterdam and Dublin address spaces if they are missing, and verify that each on-prem subnet maps to its local site.

Why the cost matters: the DC locator walks subnets → site → site links and prefers the lowest-cost link. On-prem clients will only be offered the Azure DCs if their own site has no reachable DC, which is the behaviour you want during an Amsterdam outage but not during normal operation. Keeping the Azure site link cost high makes that fallback deliberate rather than accidental.

2. What must change in DNS and client configuration so that the Azure VMs resolve names during a WAN outage, and what will still break?

Read the worked answer

Change

  • Set the Azure VMs' DNS to the two new Azure DCs (static per-VM or via VNet/DHCP option set). Leaving them pointed at DC01/DC02 means every lookup still traverses the tunnel; fixing only the DC placement would fix authentication but not name resolution.
  • Remove DC01 as primary everywhere it appears in Azure-side configuration, including load balancer and application config files that hard-code a DC name.
  • Confirm the new DCs forward to the on-premises resolvers only for namespaces they do not host.

What still breaks - and must be inventoried first

  • AD-integrated zones replicate with the directory, so those names resolve fine in Azure during an outage.
  • File-backed primary zones, conditional forwarders pointing at on-premises-only DNS servers, and stub zones for partner domains will fail during an outage, because the new Azure DCs will forward across a dead tunnel.
  • Mitigation: convert any zone the Azure workload depends on to AD-integrated, and for partner namespaces either accept the outage or host a secondary copy in Azure.

Do not "fix" this by pointing Azure VMs at public DNS as a secondary - that causes split-brain resolution and internal-name leakage.

3. The post-incident review also found Kerberos failures from clock skew. Explain how the outage produces skew, and what role placement risk remains while all FSMO roles stay on DC01.

Read the worked answer

Clock skew

  • Azure VMs get time from the host through the Hyper-V time synchronization integration service, but a domain-joined machine follows the AD hierarchy instead: member servers sync from their authenticating DC, and DCs sync from the PDC emulator.
  • With the PDC emulator on DC01 in Amsterdam, any DC in Azure tries to reach it across the tunnel. When that path is down, the Azure DCs free-run on their own clocks. Kerberos tolerates 5 minutes of skew; beyond that, tickets fail - which is what the review saw.
  • Fix: give the Azure DCs a reliable, reachable time source independent of the tunnel (an internal NTP appliance reachable over ExpressRoute, or a documented external source), verify w32tm /query /status, and monitor skew rather than waiting for a sign-in failure.

FSMO risk

  • Logon does not require a FSMO holder, so the new DCs cover authentication during an outage.
  • But PDC emulator duties (urgent password replication, account lockout evaluation) and schema/domain naming operations do require reachability. With all five roles on DC01, a WAN outage or a DC01 failure still degrades the platform.
  • Place FSMO roles on a DC that is reachable from both environments with the lowest dependency on the tunnel, and document the seize procedure for the Azure DCs. Do not put roles on a DC that only exists to serve one site.