Extending Your On-Premises Presence to Azure (Hybrid Cloud) Step-by-Step Configuration Guide

Extending Your On-Premises Presence to Azure (Hybrid Cloud) Step-by-Step Configuration Guide

Moving to Azure does not have to mean “Cut Over and Hope.” The most practical Enterprise approach is to Extend what you already run On-Premises into Azure in a Controlled, Reversible way. This Hybrid Design lets you keep existing identity, DNS, Network Segmentation, Security Controls, and Operational Processes while you Modernize Workloads Gradually. In this guide, you will build the core Building Blocks of a true Hybrid Foundation: Identity Integration, Network Connectivity, Name Resolution, Governance, Security Posture, Monitoring, and then a repeatable pattern for Extending Workloads.

What you are building, conceptually, is a secure bridge between two environments. On-Premises remains a First-Class Network and Identity Authority. Azure becomes an Additional Region of your Enterprise Network with Consistent Access Controls, Routable IP Space, deterministic DNS, Centralized Logging, and Least-Privilege Administration.

2. Target Architecture Overview (What “Extend to Azure” Means in Practice)

At minimum, a Hybrid Extension includes these elements working together:

  1. Identity Extension

§  Microsoft Entra ID tenant for cloud identity and access controls

§  Hybrid identity using Entra Connect Sync (formerly Azure AD Connect) or Cloud Sync

§  Optional: federation (AD FS) if required, but most organizations prefer Password Hash Sync or Pass-through Authentication

  1. Network Extension

§  A hub-and-spoke Azure virtual network design (recommended) or a single VNet (small deployments)

§  Site-to-Site VPN or ExpressRoute from on-premises to Azure

§  Controlled routing and segmentation using subnets, NSGs, and optionally Azure Firewall

  1. Name Resolution Extension

§  DNS that works across both environments (on-prem DNS forwarders to Azure, and Azure DNS resolution back to on-prem)

§  Azure Private DNS zones for PaaS private endpoints when you start modernizing

  1. Governance And Security Extension

§  Management Groups, RBAC, Azure Policy, and resource locks

§  Defender for Cloud, Microsoft Sentinel (optional), Key Vault, and secure admin model (MFA, Conditional Access)

  1. Operations Extension

§  Monitoring and logging (Azure Monitor, Log Analytics)

§  Patch/update and configuration management (Azure Update Manager, Azure Policy guest configuration)

§  Backup and DR (Azure Backup, Azure Site Recovery where appropriate)

3. Prerequisites and Planning (Do This Before You Click Anything)

Before you deploy, make these decisions because changing them later causes rework.

  1. Address Space Plan

§  Choose Azure VNet CIDR ranges that do not overlap with on-prem networks.

§  Reserve enough space for growth, multiple spokes, and future services.

  1. Connectivity Choice

§  Site-to-Site VPN: fastest to deploy, good for initial hybrid and many steady-state cases.

§  ExpressRoute: preferred for high throughput, low latency, and more deterministic connectivity. Many enterprises start with VPN and later add ExpressRoute.

  1. Identity Choice

§  Recommended default for most: Password Hash Sync plus Seamless SSO.

§  Pass-through Authentication is viable when password hash sync is not allowed.

§  Cloud Sync is simpler for some scenarios, but Entra Connect Sync is still common for richer options.

  1. Region Choice

§  Pick Azure region(s) close to on-prem users and apps.

§  Decide whether you need a second region for DR early, or add it later.

  1. Naming and Tagging Standard

§  Resource names, tags (Owner, CostCenter, Environment, DataClassification), and a consistent RG pattern are not optional if you want sane operations.

4. Step-by-Step: Build the Azure Governance Baseline

This is the control plane for everything that follows.

  1. Create Management Groups (recommended layout)

§  Root

ü  Platform

v Connectivity

v Identity

v Management

ü  LandingZones

v Production

v NonProduction

ü  Sandbox

  1. Assign RBAC using groups, not individual users

§  Create Entra ID security groups such as:

ü  AZ-Platform-Admins

ü  AZ-Network-Admins

ü  AZ-Security-Admins

ü  AZ-Operations

ü  AZ-Reader-Audit

  1. Apply Azure Policy baseline (minimum recommendations)

§  Require tags on resource groups and resources

§  Restrict locations to approved regions

§  Enforce private endpoints for sensitive PaaS (when adopted)

§  Deny public IP on sensitive workloads (as your standard matures)

§  Audit diagnostic settings for critical resource types

  1. Create core Resource Groups

§  rg-platform-connectivity

§  rg-platform-management

§  rg-platform-identity (if needed)

§  rg-landingzone-prod-app1 (example)

§  rg-landingzone-nonprod-app1 (example)

PowerShell example (conceptual, adjust names and scope as required):

# Create a Resource Group
New-AzResourceGroup -Name "rg-platform-connectivity" -Location "eastus"

5. Step-by-Step: Create the Hub VNet and Subnets

A Hub vNet Hosts Shared Services and Security Controls. Spokes Host Workloads.

  1. Create the hub VNet

§  Example address space: 10.10.0.0/16

  1. Create standard hub subnets (example)

§  AzureFirewallSubnet (required name if using Azure Firewall)

§  GatewaySubnet (required name for VPN/ER gateway)

§  snet-shared-services

§  snet-bastion (if using Azure Bastion; subnet name must be AzureBastionSubnet)

  1. Apply NSGs to subnets (except GatewaySubnet and AzureFirewallSubnet where rules differ)

§  Default deny inbound from Internet

§  Allow required east-west, management, and domain services as needed

Portal Steps:

  1. Azure portal, Virtual networks, Create
  2. Basics: Subscription, Resource group rg-platform-connectivity, Name vnet-hub, Region
  3. IP Addresses: add 10.10.0.0/16
  4. Subnets: create required subnets listed above
  5. Review + create

PowerShell example:

$rg  = "rg-platform-connectivity"
$loc = "eastus"

$hubVnet = New-AzVirtualNetwork -Name "vnet-hub" -ResourceGroupName $rg -Location $loc -AddressPrefix "10.10.0.0/16"

Add-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -AddressPrefix "10.10.0.0/24" -VirtualNetwork $hubVnet | Out-Null
Add-AzVirtualNetworkSubnetConfig -Name "snet-shared-services" -AddressPrefix "10.10.1.0/24" -VirtualNetwork $hubVnet | Out-Null

$hubVnet | Set-AzVirtualNetwork

6. Step-by-Step: Configure Site-to-Site VPN (Common First Hybrid Bridge)

If you are doing ExpressRoute, skip to that section. VPN is often the first milestone because it proves routing, DNS, and security end-to-end.

On-Prem Prerequisites:

  • A VPN-capable edge device (Firewall/VPN appliance) with a public IP
  • IKEv2 support is strongly recommended
  • Defined on-prem networks to advertise to Azure

Azure Steps:

  1. Create a Public IP for the VPN Gateway
  2. Create a Virtual Network Gateway (route-based)
  3. Create a Local Network Gateway (represents on-prem)
  4. Create the Connection (shared key, IKE policy if needed)
  5. Validate routes and connectivity

Portal steps:

  1. Public IP addresses, Create, name pip-vpngw-hub
  2. Virtual network gateways, Create

§  Type: VPN

§  VPN type: Route-based

§  SKU: choose based on throughput and tunnels

§  Virtual network: vnet-hub

§  GatewaySubnet must exist

  1. Local network gateways, Create

§  On-prem public IP

§  On-prem address spaces (example 10.0.0.0/8 or your real ranges)

  1. Virtual network gateways, your gateway, Connections, Add

§  Connection type: Site-to-site

§  Shared key: set and match on-prem

  1. On-prem device: configure tunnel to Azure gateway public IP using the same shared key and parameters

PowerShell Example (High-Level):

$rg  = "rg-platform-connectivity"
$loc = "eastus"

$pip = New-AzPublicIpAddress -Name "pip-vpngw-hub" -ResourceGroupName $rg -Location $loc -AllocationMethod Static -Sku Standard

$vnet = Get-AzVirtualNetwork -Name "vnet-hub" -ResourceGroupName $rg
$gwSubnet = Get-AzVirtualNetworkSubnetConfig -Name "GatewaySubnet" -VirtualNetwork $vnet

$gwIpConfig = New-AzVirtualNetworkGatewayIpConfig -Name "gwipconf" -SubnetId $gwSubnet.Id -PublicIpAddressId $pip.Id

$vpngw = New-AzVirtualNetworkGateway -Name "vpngw-hub" -ResourceGroupName $rg -Location $loc `
  -IpConfigurations $gwIpConfig -GatewayType Vpn -VpnType RouteBased -GatewaySku "VpnGw2"

$lng = New-AzLocalNetworkGateway -Name "lng-onprem" -ResourceGroupName $rg -Location $loc `
  -GatewayIpAddress "YOUR_ONPREM_PUBLIC_IP" -AddressPrefix @("10.0.0.0/8")

New-AzVirtualNetworkGatewayConnection -Name "cn-hub-to-onprem" -ResourceGroupName $rg -Location $loc `
  -VirtualNetworkGateway1 $vpngw -LocalNetworkGateway2 $lng -ConnectionType IPsec -SharedKey "YOUR_SHARED_KEY"

Validation:

  1. Confirm the VPN connection shows Connected in Azure
  2. From an on-prem host, ping/test a VM IP in Azure (once you deploy one)
  3. From Azure, test connectivity back to on-prem IPs
  4. Verify effective routes on a NIC in Azure to ensure on-prem prefixes are learned

7. Step-by-Step: Configure DNS So Hybrid Feels Like One Network

DNS is where most “hybrid” projects break. Fix DNS early and everything becomes easier.

Common recommended approach:

  • Keep Active Directory DNS authoritative for AD zones on-prem.
  • Make Azure workloads use a DNS resolver that can resolve both Azure private zones and on-prem zones.

Two practical patterns:

Pattern A (simple): Azure VMs use on-prem DNS servers

  • Set VNet DNS servers to on-prem domain controllers.
  • Requires VPN/ER stability and good latency.

Pattern B (enterprise): Add DNS forwarders/resolvers in Azure

  • Deploy two small resolver VMs in snet-shared-services (or use Azure DNS Private Resolver)
  • Configure forwarders to on-prem DNS for AD zones and conditional forwarders for private endpoints.

Step-by-step (Pattern A):

  1. Virtual network, vnet-hub, DNS servers
  2. Set “Custom” and enter on-prem DNS IPs (domain controllers)
  3. Restart Azure VMs to pick up DNS changes or renew DHCP lease

Step-by-step (Pattern B with forwarder VMs):

  1. Deploy two Windows Server VMs in Azure (different availability zones if possible)
  2. Install DNS role, configure as forwarders
  3. Set conditional forwarders:

§  Your AD domain zone forward to on-prem DC DNS IPs

§  Any on-prem private zones forward to on-prem

  1. Set VNet DNS servers to the two Azure DNS forwarder VM IPs
  2. Configure those Azure DNS forwarders to forward unknown queries to:

§  On-prem DNS for internal domains

§  Public resolvers for Internet (or your enterprise policy)

8. Step-by-Step: Extend Identity with Microsoft Entra ID (Hybrid Identity)

This is the identity bridge that makes Azure access and Microsoft 365 access consistent.

Recommended baseline for most enterprises:

  • Entra Connect Sync with Password Hash Sync and Seamless SSO
  • MFA and Conditional Access for privileged roles

Step-by-step outline:

  1. Prepare on-prem Active Directory
  2. Confirm you have a supported AD forest functional level and healthy replication
  3. Ensure UPN suffix aligns with your verified domain in Entra ID (example user@company.com)
  4. Clean up duplicate proxyAddresses, invalid characters, and stale objects
  5. Ensure you have an enterprise admin account for installation and a least-privilege strategy afterward
  6. Prepare Entra ID tenant
  7. Create or confirm tenant
  8. Verify your custom domain in Entra ID
  9. Create break-glass accounts (cloud-only), exclude from Conditional Access, protect with strong controls
  10. Install Entra Connect Sync on a dedicated server
  11. Use a member server (not a domain controller) where possible
  12. Install Entra Connect
  13. Choose: Password Hash Sync and Seamless SSO (typical)
  14. Choose OU filtering (start minimal)
  15. Choose group filtering (optional)
  16. Enable password writeback only if you have a specific requirement and have designed for it
  17. Complete initial sync
  18. Validate identity
  19. Confirm users appear in Entra ID with correct UPN
  20. Test sign-in to an Entra-integrated app
  21. Confirm Seamless SSO works on domain-joined machines
  22. Validate password changes sync as expected
  23. Secure privileged access
  24. Require MFA for admin roles
  25. Use Conditional Access policies for admin portals and high-risk sign-ins
  26. Use Privileged Identity Management if licensed
  27. Enforce least privilege using RBAC and role-assignable groups

9. Step-by-Step: Secure Admin Access to Azure (Do Not RDP From the Internet)

A clean hybrid build avoids public RDP/SSH.

Recommended options:

  • Azure Bastion for interactive access without public IPs
  • Just-in-time access (Defender for Cloud) if you must open management ports temporarily
  • Private endpoints and private access paths where possible

Steps for Bastion:

  1. Create AzureBastionSubnet in hub VNet
  2. Deploy Azure Bastion in hub
  3. Remove public IPs from VMs
  4. Use Bastion to connect via portal with proper RBAC

10. Step-by-Step: Onboard Monitoring and Logging

Without logging, you cannot prove security or troubleshoot hybrid routing and identity issues.

  1. Create a Log Analytics workspace (platform management RG)
  2. Enable diagnostic settings for:

§  VPN gateway

§  Firewalls (if used)

§  Key Vault

§  Public IPs and NSGs (flow logs if needed)

§  Critical PaaS services

  1. Install Azure Monitor Agent on servers (Azure and on-prem if desired)
  2. Create baseline alerts:

§  VPN tunnel down

§  High packet drops

§  Failed sign-ins (Entra ID)

§  Privileged role assignments

11. Step-by-Step: Extend Workloads (Repeatable Landing Zone Pattern)

Once the bridge exists, extending presence means deploying spokes and placing workloads there.

Spoke Pattern:

  1. Create spoke VNet per application or domain
  2. Create subnets per tier (web, app, data)
  3. Peer spoke to hub (use VNet peering)
  4. Route through hub security (Azure Firewall/NVA) if required
  5. Apply NSGs and UDRs
  6. Use Private Endpoints for PaaS where possible
  7. Apply Azure Policy and tagging

Portal Steps (Spoke Peering):

  1. Create vnet-spoke-app1 with non-overlapping CIDR
  2. Create VNet peering:

§  Hub to Spoke: allow forwarded traffic if using firewall, allow gateway transit if hub gateway is shared

§  Spoke to Hub: use remote gateways if hub provides gateway

PowerShell example (peering):

$rg = "rg-platform-connectivity"

$hub  = Get-AzVirtualNetwork -Name "vnet-hub" -ResourceGroupName $rg
$spoke = Get-AzVirtualNetwork -Name "vnet-spoke-app1" -ResourceGroupName $rg

Add-AzVirtualNetworkPeering -Name "peer-hub-to-spoke-app1" -VirtualNetwork $hub -RemoteVirtualNetworkId $spoke.Id -AllowForwardedTraffic
Add-AzVirtualNetworkPeering -Name "peer-spoke-app1-to-hub" -VirtualNetwork $spoke -RemoteVirtualNetworkId $hub.Id -AllowForwardedTraffic -UseRemoteGateways

12. Step-by-Step: Validate End-to-End Hybrid Functionality

Validation is not a single ping test. You want to confirm identity, routing, DNS, and security as a system.

  1. Connectivity tests
  2. From on-prem to Azure private IP (ICMP may be blocked; use TCP tests too)
  3. From Azure VM to on-prem services (LDAP, Kerberos, file shares if relevant)
  4. Confirm effective routes on Azure NICs
  5. DNS tests
  6. Resolve on-prem internal names from Azure
  7. Resolve Azure private endpoint names correctly (when implemented)
  8. Confirm correct suffix search lists where applicable
  9. Identity tests
  10. Hybrid user sign-in to Entra-integrated application
  11. Conditional Access behavior matches design (compliant device, MFA prompts)
  12. Admin role activation (if using PIM)
  13. Security tests
  14. No inbound management ports exposed to Internet
  15. NSG rules align with least privilege
  16. Logging visible in Log Analytics

13. Common Mistakes and How to Avoid Them

Overlapping IP ranges is the fastest way to derail hybrid routing. Fix address planning before deployment. DNS misconfiguration is the second largest cause of “hybrid not working,” especially when teams mix on-prem DNS, Azure-provided DNS, and private endpoints without a clear resolution strategy. Another frequent mistake is treating RBAC as optional; if you do not build group-based access and policy baselines early, you will end up with ad-hoc permissions that are hard to audit and harder to clean up.

Finally, do not expose management to the Internet just to move faster. A hybrid foundation is supposed to reduce risk, not move it around.

14. Next Steps After the Hybrid Foundation

Once your presence is extended, you can choose a modernization path without pressure:

  1. Lift-and-shift selected servers into Azure IaaS (VMs) and keep identity and DNS consistent
  2. Introduce PaaS with private endpoints and private DNS zones
  3. Implement Azure Backup and Azure Site Recovery for core workloads
  4. Evolve toward Zero Trust with stronger Conditional Access, device compliance, and identity governance
  5. Expand to multi-region resiliency as workloads justify it

 

0 comments

Leave a comment

Please note, comments need to be approved before they are published.