← Cloud projects

Cloud · Architecture Concept

Enterprise Active Directory Foundation

Build a resilient Active Directory foundation where domain controllers, DNS, Sites, privileged access, backup, and cloud connectivity are designed as one identity dependency.

PlatformCloud
DomainIdentity
LevelIntermediate
Last reviewed2026-09-19
Use whenProvide resilient directory, authentication, policy, and name-resolution services for enterprise workloads.
Key decisionDNS is part of the identity design
Key conceptsActive Directory Domain Services · DNS · Sites and Services
Cost focusCompute for domain controllers
On this page

Building blocks

Active Directory Domain ServicesDNSSites and ServicesGroup Policy

Design goal

Keep authentication, directory, policy, and name resolution available through infrastructure failure without creating hidden single points of failure in DNS or administration.

Success criteria

  • Remove single-domain-controller dependencies
  • Align AD Sites with network topology
  • Protect privileged administration
  • Plan backup and recovery before cloud integration

Architecture

Deploy redundant domain controllers across failure domains, integrate AD-integrated DNS, and map Sites/Subnets to routed network locations.

Architecture flow

  • Clients locate domain controllers through DNS
  • Authentication is served by an appropriate site
  • Directory changes replicate between domain controllers
  • Cloud networks connect through controlled hybrid connectivity
Users / AppsDNSDC - Site ADC - Site BCloud Networks
Users / Apps
DNS
DC - Site A
DC - Site B
Cloud Networks

Architecture decisions

Decision

DNS is part of the identity design

Why

AD DS depends on DNS service records; DNS architecture should be designed together with domain controller placement.

Trade-off

Tightly integrating DNS with directory design improves authentication reliability, but DNS failures or misconfiguration can affect the entire identity plane.

Decision

Redundancy must cover failure domains

Why

Multiple domain controllers only improve resilience when they are not dependent on the same host, power, network, or region failure domain.

Trade-off

True failure-domain separation improves resilience, but requires additional compute, network, replication, and operational capacity.

Security

Protect the control and data paths deliberately. Use separate privileged identities, hardened administration paths, tiered access, and audited changes.

  • Least privilege
  • Privileged access workstations or hardened admin hosts
  • MFA for cloud control planes
  • Administrative audit logging

Availability

Design for the failure domain that must be survived. Provide at least two domain controllers where directory availability is required and place them across independent failure domains.

Disaster recovery

Treat regional recovery as a separate operating state. Maintain system-state aware backups and document authoritative/non-authoritative recovery procedures.

Cost drivers

  • Compute for domain controllers
  • Backup retention
  • Hybrid network connectivity
  • Monitoring and security tooling

Design assumptions

  • A single forest/domain is sufficient for the reference pattern
  • Network routing and time synchronization are available

Implementation plan

  1. Define domain, forest, DNS, IP, site, and hybrid-connectivity boundaries before placing domain controllers.
  2. Deploy domain controllers across the failure domains the identity service must survive, with DNS installed where the design requires it.
  3. Configure AD-integrated zones, forwarders/resolvers, and client DNS settings so authentication does not depend on an external or single resolver path.
  4. Map Sites and Services subnets to actual network locations and tune replication only where topology or bandwidth requires it.
  5. Protect privileged administration, system-state backup, time synchronization, and break-glass access, then monitor replication and DNS health.

Validate the design

  • Query critical DNS service records from each site and confirm clients locate the intended domain controllers.
  • Authenticate users/workloads from representative subnets and verify site-aware domain-controller selection.
  • Review replication health and simulate loss of one domain controller or DNS path.
  • Restore system state or an approved recovery copy in a controlled procedure and verify the documented AD recovery steps are usable.

Architecture basis

Continue a learning path