Implementing a Site-to-Site (S2S) tunnel is simple — so rather than walking through the steps procedurally, I want to focus on what each component is actually doing.

A Site-to-Site VPN connects two networks over the public internet using an encrypted IPsec tunnel. Each end has a gateway that authenticates the other using a Pre-Shared Key (PSK). Only traffic destined for the remote subnet goes through the tunnel — everything else uses the normal internet route. The tunnel is managed by IKE (Internet Key Exchange) which negotiates the Security Association (SA) — the agreed encryption parameters — before any traffic flows.

Before walking through the steps, here are the key addresses we’ll reference throughout

192.168.122.0/24— On-prem network hosting KVM VMs (virbr0)
192.168.1.106 — on-premises VPN gateway (Strongswan)
192.168.1.0/24 — on-premises Wi-Fi LAN
61.69.136.49 — **On-premises public IP
**20.219.67.227 — **Azure VPN Gateway Public IP
**10.66.0.0/16 — Azure VNet
10.66.0.0/24 — Azure GatewaySubnet
10.66.5.0/24 — Azure WorkloadSubnet

Some of these will be created in the steps below; others are already in place from earlier parts.

Azure Configurations

1. Create a virtual network in Azure

While creating a vnet using Azure portal, decide on an address range and create two subnets named GatewaySubnet and WorkloadSubnet as show below. In WorkloadSubnet we will create VMs that want to talk to on-premises.

Once the VNet is provisioned, we need three components at Azure end that enable the connectivity with on-premises — a VPN gateway, a Local Network Gateway and a link between these two components

2. Azure VPN Gateway

This is the component that is responsible for establishing a secure tunnel with the on-premises. VPN Gateway is deployed in the virtual network you have chosen to pair with your on-premises network and has to be deployed in GatewaySubnet only — this is a hard requirement. Azure reserves this subnet name specifically for gateway infrastructure and rejects deployment attempts to any other subnet name. All traffic comes in and goes out via this VPN Gateway if force tunneling is enabled. Incoming traffic lands in the GatewaySubnet and from there it will be routed to the destination within the VNet.

For our purpose, a Basic tier VPN gateway would suffice. The Azure portal no longer shows a VPN type selector — all new gateways are route-based by default which support IKEv2. This is what we will use.

Remember that on top of fixed monthly charge, there are costs associated with traffic entering and leaving the network via VPN Gateway — https://azure.microsoft.com/en-us/pricing/details/vpn-gateway/

Once the VPN Gateway is created, take a note of the public IP assigned to it. In my case it is — 20.219.67.227

3. Local Network Gateway

Now that we have a gateway in our Azure VNet, we need a way to identify the on-premises network. For this, an Azure service called Local Network Gateway is used. This is the representation of on-premises network. When you create a Local Network Gateway provide the static IP of your on-premises as the IP address and the network ranges that you want to include in the tunnel as address ranges —

IP address — 61.69.136.49 (public IP of your Wi-Fi router), you can confirm this by running the below command

curl -s ifconfig.me # 61.69.136.49

Note: This address can change when your ISP reassigns it, which typically happens on router restart or DHCP lease expiry. For home lab, this is fine but if you are having a serious setup you must consider getting static IP for yourself.

Address Space(s) —

**192.168.122.0/24** (the libvirt virtual network) &**192.168.1.0/24** (your Wi-Fi network)

Note: You can skip the Wi-Fi range if you do not intend to have other devices in your Wi-Fi to participate in the S2S tunnel

4. Connection

And the final bit of the Azure end of configuration is a Connection. A connection is the link between the VPN Gateway and the Local Network Gateway.

From VPN Gateway, create a connection of type “Site-to-Site (IPSec)” and choose IKEv2, provide the shared key (PSK), connection mode and leave the rest as it is.

On-premises configuration

On-premises needs VPN Gateway configurations similar to the Azure site. The on-premises configuration is simpler by comparison. We will use StrongSwan as the VPN Gateway and the following sections walk through the necessary configurations to enable a site-to-site tunnel

5. Install / Configure StrongSwan

StrongSwan is an open-source IPsec implementation for Linux. It runs as a daemon on the on-premises host and is responsible for IKE negotiation, SA establishment, and installing the resulting XFRM policies and keys into the Linux kernel.

Install StrongSwan and ensure it is running

sudo apt install strongswan
sudo systemctl enable strongswan-starter
sudo systemctl start strongswan-starter
sudo systemctl status strongswan-starter

6. ipsec.conf

This is StrongSwan’s main configuration file — it defines the tunnel connection parameters including peer identities, the subnets to advertise on each side, the encryption proposals, and the connection behaviour on startup and failure.

sudo nano /etc/ipsec.conf

Minimal config:

config setup
charondebug=“ike 2, knl 2, cfg 2”

conn azure-s2s
keyexchange=ikev2
left=<onprem_vpn_gateway> #Linux box with Strongswan
leftid=<onprem_vpn_gateway> #Linux box with Strongswan
leftsubnet=<onprem_subnet_1_range>,<onprem_subnet_2_range>
right=<azure_vpn_gateway_public_ip>
rightid=<azure_vpn_gateway_public_ip>
rightsubnet=<azure_workload_subnet_address_range>
authby=secret
auto=start
ike=aes256-sha256-modp1024! (acceptable for lab environments)
esp=aes256-sha256!
dpdaction=restart
dpddelay=30s
dpdtimeout=120s

Each attribute controls a specific aspect of how StrongSwan negotiates and maintains the tunnel:

**keyexchange=ikev2** — specifies IKEv2 as the key exchange protocol. IKEv2 is more efficient than IKEv1 (fewer round trips to establish the SA) and handles NAT traversal natively, which matters here since the on-premises side is behind a home router.

**left** / **leftid** — identifies the local end of the tunnel. left is the IP StrongSwan binds to; leftid is how it identifies itself to the remote peer during IKE negotiation. Both are set to the StrongSwan host’s LAN IP here.

**leftsubnet** — defines what on-premises ranges StrongSwan advertises through the tunnel. These must match the address spaces configured in the Azure Local Network Gateway — Azure uses the LNG configuration to inject routes into the VNet.

**right** / **rightid** — the mirror of left, identifying the remote peer — in this case the Azure VPN Gateway’s public IP.

**rightsubnet** — the network ranges behind the Azure VPN Gateway that on-premises should route through the tunnel. Traffic destined for these ranges will be intercepted by XFRM and encrypted.

**authby=secret** — use a Pre-Shared Key for authentication, as configured in ipsec.secrets.

**auto=start** — bring the tunnel up automatically when StrongSwan starts. Setting this to add instead would make StrongSwan a passive responder only.

**ike=aes256-sha256-modp1024!** — the Phase 1 (IKE SA) proposal: AES-256 encryption, SHA-256 integrity, and Diffie-Hellman group 2 (modp1024 — acceptable for lab environments). The trailing ! means this is the only proposal offered — StrongSwan will not fall back to weaker algorithms. Azure must match this exactly.

**esp=aes256-sha256!** — the Phase 2 (ESP) proposal governing how actual data packets are encrypted inside the tunnel. Same strict-match semantics as the ike line.

**dpdaction=restart** — Dead Peer Detection behaviour. If the remote peer goes silent, StrongSwan will attempt to re-establish the tunnel rather than leave a stale SA. dpddelay and dpdtimeout control how long it waits before declaring the peer dead.

Example —

config setup
charondebug=“ike 2, knl 2, cfg 2”

conn azure-s2s-manual
keyexchange=ikev2
left=192.168.1.106
leftid=192.168.1.106
leftsubnet=192.168.122.0/24,192.168.1.0/24
right=20.219.67.227 # (hce-d01-vpngw-pip)
rightid=20.219.67.227 # (hce-d01-vpngw-pip)
rightsubnet=10.66.5.0/24
authby=secret
auto=start
ike=aes256-sha256-modp1024!
esp=aes256-sha256!
dpdaction=restart
dpddelay=30s
dpdtimeout=120s

**_rightsubnet_** = where your workloads live = what you want to reach.

_GatewaySubnet_ is infrastructure — it’s where Azure’s VPN Gateway itself runs. You never deploy VMs there, and you never put it in _rightsubnet_. It’s not a destination, it’s a transit point.

So the mental model:

rightsubnet = subnets behind the remote gateway
 = where the actual VMs/services are
 = NOT the gateway’s own subnet

Same logic applies symmetrically to _leftsubnet_ on your side — it’s the subnets behind your StrongSwan (your VM network, your LAN), not StrongSwan’s own IP.

The gateway subnet on both sides is implied — both ends know the gateways exist because they’re talking to each other. What they need to tell each other is “what’s behind me that you can reach.”

7. ipsec.secrets

The ipsec.secrets file is read by Charon — StrongSwan’s IKEv2 keying daemon — at startup and on ipsec reload. It holds the Pre-Shared Key used to authenticate both peers during IKE Phase 1. The format is:

<local-id> <remote-id> : PSK “shared-secret”

The two IPs identify the tunnel endpoints — they must match the leftid and rightid values in ipsec.conf exactly, because charon looks up the secret by matching the peer identities presented during IKE negotiation. The PSK itself must match what was configured in the Azure Connection resource, character for character.

This file does not change structure over the lifetime of the tunnel. The only reason to update it is if you rotate the PSK — in Azure you set a new shared key on the Connection, then update the value here and run sudo ipsec reload secrets to pick it up without restarting the daemon or dropping the tunnel.

One important operational note: this file contains a plaintext secret and should be owned by root with permissions 600. StrongSwan will warn if it is world-readable.

sudo nano /etc/ipsec.secrets

192.168.1.106 20.219.67.227 : PSK “your_shared_key”

We have setup all necessary infrastructure to bring up the tunnel now. But before that, let us understand a bit about how tunnels are established

Under the Hood: The Mechanics of Tunnel Initiation

The S2S tunnel was initiated from on-premises — 
When StrongSwan sends the initial IKE packet outbound (src: 192.168.1.106:500 → dst: 20.219.67.227:500), the Wi-Fi router performs source NAT — replacing 192.168.1.106 with the public IP 61.69.136.49 — and records this translation in its conntrack table. When Azure replies, the router matches the inbound packet against that entry and reverses the translation, forwarding the packet to 192.168.1.106.

The S2S tunnel is initiated from Azure — 
in this scenario, the Azure VPN Gateway is the initiator of the tunnel. This will fail to even establish a tunnel unless a port-forwarding is configured on the Wi-Fi router. If you are curious, here are the steps to have Azure initiate the tunnel. 
1. Set auto=add in ipsec.conf — tells StrongSwan that it should not initiate tunnel and just be a responder, StrongSwan won’t initiate the tunnel on startup and won’t re-initiate if it drops.

2. Set Connection Mode to _InitiatorOnly_ in Azure Local Network Gateway » Connection » [Your Connection] » Configuration blade properties.

3. Enable port forwarding in your Wi-Fi router with these values 
_1. InternalIP:192.168.1.106 — InternalPort:500 — Protocol:UDP — ExternalPort:500 2. InternalIP:192.168.1.106 — InternalPort:4500 — Protocol:UDP — ExternalPort:4500_
Port 500 is used for the initial IKE handshake. Port 4500 is used for NAT Traversal (NAT-T) — once both sides detect a NAT device on the path, all subsequent IKE and ESP traffic moves to UDP:4500.

These rules tell the Wi-Fi router to forward any inbound UDP:500 and UDP:4500 traffic arriving on the WAN interface to _192.168.1.106_, regardless of the source. Without these rules, the router has no NAT mapping for unsolicited inbound IKE packets and drops them.

IMPORTANT — Who initiates the tunnel has no bearing on data packet routing between the sites as long as the tunnel is UP. Once the IPsec SA is established, the tunnel is a symmetric pipe — packets flow freely in both directions regardless of which side initiated IKE. Once the tunnel is up, the success and failure points are identical in both cases.

Bring the tunnel up

With both sides configured, bring the tunnel up from the StrongSwan host. Follow the below steps to bring the tunnel up.

# Check current state
sysctl net.ipv4.ip_forward

# Enable if 0
sudo sysctl -w net.ipv4.ip_forward=1

ip_forward must be enabled for the StrongSwan host to forward packets between interfaces — we will cover exactly why in Part 6.

#Start strongswan - if is just installed or not running else run ipsec restart and skip the second step
sudo ipsec start

#Bring connection up
sudo ipsec up azure-s2s-manual

#Verify
sudo ipsec status

ipsec status output should show the tunnel as ESTABLISHED

Security Associations (1 up, 0 connecting):
azure-s2s-manual[1]: ESTABLISHED 13 minutes ago, 192.168.1.106[192.168.1.106]…20.219.67.227[20.219.67.227]
azure-s2s-manual{1}: INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c0a6aaf5_i 90cbbb64_o
azure-s2s-manual{1}: 192.168.1.0/24 192.168.122.0/24 === 10.66.5.0/24

Summary

Now that the tunnel is established, it’s worth mapping out the traffic flows it enables — and one it doesn’t, yet. There are 3 scenarios of bi-directional traffic flow in our setup between —

1. Azure Virtual Machines and On-premises Virtual Machines
2. Azure Virtual Machines and On-premises VPN Gateway
3. On-premises VPN Gateway and the On-premises Virtual Machines

Except the packet flow from Azure virtual machine destined for on-premises KVM virtual machines (which sit behind StrongSwan on the libvirt network), all of the above will work without any additional configuration.

In the next part of the series we will discuss why they work and why one of them doesn’t.

I checked whether the UAMI had necessary RBAC roles to work on AzureWebJobsStorage — it had. So, I wasn’t sure what the issue was.

Analyzing further, I realized I had skipped a few mandatory variable settings to enable UAMI based authentication to AzureWebJobsStorage (setting the environment variable AzureWebJobsStorage__accountName alone does not suffice)

Steps to enable UAMI access to AzureWebJobsStorage

Enabling UAMI access to AzureWebJobStorage involves changes in Terraform (when the Function App is created), the App Settings (Environment variables) and finally the Role Based Access.

Terraform

If for some reason you want to use UAMI to authenticate with AzureWebJobsStorage, then Terraform block **functionAppConfig.deployment.storage.authentication**: should look like below

Note: I am using Flex Consumption tier

authentication = {
type = “userassignedidentity”
userAssignedIdentityResourceId = “”
}

This tells the platform to use UAMI for the deployment package blob container — the part that isn’t controlled by app settings.

App settings

Once the Function App is deployed with usermanagedidentity as authentication type (terraform), ensure the below variables are set in the Function App’s Environment variables

AzureWebJobsStorage__accountName =
AzureWebJobsStorage__credential = managedidentity
AzureWebJobsStorage__clientId =

All three settings are mandatory.

RBAC

This is the final bit. We have the Function App deployed, environment variables set, next, the UAMI needs privilege to access the storage account.

Provide Storage Blob Data Owner owner role to the UAMI on the storage account

With these three changes, your Function App will authenticate with its AzureWebJobsStorage using UAMI.

Caveat: Although this works, the issue with this approach is all services that are assigned this UAMI will gain access to the function’s storage account. This is not ideal if many services share the same UAMI. The better option will be to use System Assigned Managed Identity (SAMI) for authentication between Function App and its storage account. For the rest of the outbound calls that the functions might make, use UAMI.

Using System Assigned Managed Identity

To use SAMI just setAzureWebJobsStorage__accountName — SAMI is the default, no additional settings needed. Next, give SAMI Storage Blob Data Owner on the storage account. If you are using Terraform to deploy the authentication block of the Function App will look like this —

authentication = {
type = “systemassignedidentity”
}

SAMI is my preferred method for authentication with the AzureWebJobsStorage for the reasons already discussed in the caveat section.

Summary

Configuring a Function App to authenticate with its AzureWebJobsStorage using managed identity requires changes at three levels — Terraform, app settings, and RBAC — and all three must be consistent with each other. For UAMI, all three AzureWebJobsStorage__* settings are mandatory; omitting any one of them will cause the runtime to fail. However, personally I feel UAMI for AzureWebJobsStorage is rarely the right choice — since UAMI is a shared identity, every service assigned to it inherits access to the storage account. SAMI, which requires only AzureWebJobsStorage__accountName and a single role assignment, is the simpler and safer default for this use case.

Reference — Use User managed identity to replace connection string in”AzureWebJobsStorage” for function apps | Microsoft Community Hub

1. Provision a new Linux VM
2. Assign the DC IP
3. Install Linux Kerberos client tool
4. Join the domain
5. Validation

The fundamental domain join mechanics are the same for Windows and Linux. The underlying authentication protocol (Kerberos) is identical for both — the difference is integration depth. Windows has native AD support built in, whereas Linux requires explicit configuration via tools like realmd, SSSD, and the Kerberos client utilities. So, let’s get started with a new VM.

Provision a new Ubuntu VM

We will create a VM based on Ubuntu 22.04 LTS for our virtual network. You need to download the Ubuntu iso and create a VM using virt-manager following the regular VM creation process. Once the VM is up and running, let’s start with some connectivity checks.

Connectivity Checks:

Ping DCs:

ping 192.168.122.10
ping 192.168.122.11

This will work because the Linux VM will be created in the same network range as the Windows client or the DCs. If this is not the case, ensure you map the VM to the relevant network using the virt-manager (This can happen if you have multiple virtual networks running in your system)

Add the DC IP to the resolv.conf

This step is like what we do for a Windows client, just that we do it a bit differently. The Linux VM should use the Domain Controller’s IP as its DNS server. The fresh Linux VM will have the DNS pointing to itself at 127.0.0.53

If you remember, we used the GUI to change the preferred DNS for the VM in Windows. In Linux, the DNS server details reside in /etc/systemd/resolved.conf

On modern Ubuntu systems, the file /etc/resolv.conf is not meant to be edited directly because it is automatically generated and managed by the systemd-resolved service. Any manual changes you make will be overwritten. Instead, you should configure DNS settings in the source of truth, typically /etc/systemd/resolved.conf (or via Netplan/NetworkManager depending on your setup), and then restart the service.

Note — Even if /etc/resolv.conf appears stable after manual edits, it is still managed by the system in most modern Ubuntu setups and may be overwritten on reboot or network changes. Always configure DNS through systemd-resolved or Netplan for reliability

Edit the resolved.conf to set the DC’s IP as the DNS server for the Linux VM

sudo nano /etc/systemd/resolved.conf

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4>
# Google: 8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.go>
# Quad9: 9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#d>
DNS=192.168.122.10 192.168.122.11
#FallbackDNS=
Domains=hybrid.local
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
#StaleRetentionSec=0

Restart and check that value has persisted.

sudo systemctl restart systemd-resolved

Verify DNS resolution:

Now that the DNS has been updated try nslookup hybrid.local The expected output is

Server: 127.0.0.53
Address: 127.0.0.53#53

Name: hybrid.local
Address: 192.168.122.10
Name: hybrid.local
Address: 192.168.122.11

The server shown as 127.0.0.53 is the systemd-resolved stub — this is expected, as systemd-resolved intercepts all DNS queries locally before forwarding them upstream. Queries are forwarded to the configured upstream DNS servers (your DCs). The returned addresses confirm that DC DNS is now authoritative for hybrid.local

Install Kerberos Client Tools

From this step onwards, the process of domain join is different from Windows. While the Windows client has necessary Kerberos modules, Linux client should be enabled to communicate with Active Directory using Kerberos. To do that install the Kerberos client tool, [krb5-user](https://web.mit.edu/kerberos/krb5-1.4/krb5-1.4/doc/krb5-user.html)

What does krb5-user really do? It installs client end tools that enable communication with a server using Kerberos. In Kerberos, the password is never sent over the wire. Instead, it is converted into a cryptographic key, which is then used to encrypt a timestamp during pre-authentication, which will subsequently be decrypted by the server. The validation is the ability of the server to “decrypt” the client request using its version of the stored key — and this is precisely why clock skew breaks Kerberos. If the timestamp is outside the allowed window, the DC rejects it regardless of whether decryption succeeded.

Notes:

When the DC was promoted, the admin password you provided was hashed using DC’s preferred ‘method(s)’ (etype) and stored in ntds.dit (e.g. AES256 key stored against account)

When a Linux VM is created the krb5.conf file defines supported etypes

When the Linux VM wants to authenticate with the Windows AD, you initiate the Kerberos flow by running kinit

Client VM’s kinit sends → AS-REQ to DC saying, “I am administrator, The Client VM supports AES256, AES128, RC4”

DC responds saying “I need pre-auth, and for this account I use AES256”

Client then derives a key from the password (using the required encryption type, e.g., AES256) → uses this key to encrypt timestamp in Client VM. This is sent as AS-REQ (with pre-auth): username + AES256-encrypted timestamp

The DC decrypts this AS-REQ with the stored AES256 key against this user, validates the timestamp is within the allowed clock skew window (default 5 minutes) → issues TGT

The default TTL of a Kerberos TGT is 10 hours

Let’s proceed with the setup.

sudo apt update
sudo apt install krb5-user -y

Prompt: Enter default realm → HYBRID.LOCAL (uppercase).

In the next prompt provide the FQDN on your DCs separated by space

And finally when asked for primary DC, provide your primary DC’s FQDN

Run dpkg -l | grep krb5-user It should list krb5-user as installed.

Configure /etc/krb5.conf

We have installed the necessary client tools to enable Kerberos based exchange from the Linux VM. Next, the Linux VM’s Kerberos client must point to the Key Distribution Centers in the Active Directory. Update sudo nano /etc/krb5.conf as described below

[libdefaults]
default_realm = HYBRID.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = true
[realms]
HYBRID.LOCAL = {
kdc = 192.168.122.10
kdc = 192.168.122.11
admin_server = 192.168.122.10
}
[domain_realm]
.hybrid.local = HYBRID.LOCAL
hybrid.local = HYBRID.LOCAL

Confirm your changes have persisted — cat /etc/krb5.conf

we will validate if AD is issuing Kerberos tickets to us by requesting a Ticket Granting Ticket from AD KDC. Run kinit Administrator@HYBRID.LOCAL and enter Administrator password.

Next run klist

You should be seeing a ticket as below:

Default principal: Administrator@HYBRID.LOCAL
Valid starting Expires Service principal
03/06/26 19:11:11 03/07/26 05:11:11 krbtgt/HYBRID.LOCAL@HYBRID.LOCAL

If you are curious about the attributes of the ticket, run klist -f # shows flags like forwardable, renewable or klist -e # shows encryption types

Join Linux to Domain

We have the foundation required for a domain join. Now, we will install the required packages for the domain join

sudo apt install realmd sssd sssd-tools adcli samba-common-bin oddjob oddjob-mkhomedir -y

realmd — discovers which domains or realms it can use or configure. It can discover and identify Active Directory domains by looking up the appropriate DNS SRV records.

sssd — System Security Services Daemon. After the join, this is what runs continuously to handle authentication requests — it talks to the DC for login, group membership, sudo rules etc. The long-running engine.

sssd-tools — CLI utilities for sssd (sssctl, sss_override etc.) — useful for cache flushing and diagnostics.

adcli — Active Directory CLI. realmd uses this under the hood to perform the low-level AD join operations (creating the computer object in AD, setting up the machine account).

samba-common-bin — provides tools like net and wbinfo that realmd/sssd lean on for certain AD operations.

oddjob — a D-Bus service that runs privileged helper tasks on behalf of other services. sssd uses it to do things it can’t do as its own user.

oddjob-mkhomedir — the specific oddjob helper that automatically creates a home directory the first time a domain user logs into the Linux machine. Without this, a domain user authenticates successfully but lands with no home directory.

realmd + adcli → join-time (one-off operation)
sssd + sssd-tools → runtime (ongoing authentication)
oddjob + mkhomedir → login-time helper (home dir creation)
samba-common-bin → shared plumbing both layers use

Verify the configuration and connectivity to the domain controller

sudo realm discover hybrid.local

hybrid.local
type: kerberos
realm-name: HYBRID.LOCAL
domain-name: hybrid.local
configured: no
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin

The above proves network connectivity to the DC, correct DNS resolution, and that AD is responding to discovery queries.

Join the domain as Administrator

sudo realm join --user=Administrator hybrid.local

Post domain join, verify the configuration and connectivity to the domain controller

sudo realm list

hybrid.local
type: kerberos
realm-name: HYBRID.LOCAL
domain-name: hybrid.local
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
login-formats: %U@hybrid.local
login-policy: allow-realm-logins

Run, id testuser1@HYBRID.LOCALyou will see that the testuser1 is looked up from the Domain Controller by the Linux Client.

Enable automatic home directory creation:

sudo pam-auth-update
# Enable “Create home directory on login”

Enable “Create home directory on login”

Verification

As a final test, you should be able to successfully login using one of the test users you had created and used for the Windows client (testuser1@HYBRID.LOCAL). Notice that the home directory for testuser1 is created.

Also, login to the DC and see a new Linux VM getting added there under hybrid.local > Computers

Summary

This concludes the part of the series where we established an on-premises identity foundation. In this series, so far, we have established

• A functioning Active Directory forest (hybrid.local) with two domain controllers
• Multi-master replication verified across both DCs — SYSVOL, NETLOGON, and directory objects
• FSMO roles identified and accounted for
• A Windows client and a Linux VM both domain-joined and authenticated via Kerberos
• DNS working end-to-end: internal resolution via the DC, external resolution via the forwarder

Up next, a S2S VPN tunnel with Azure which would complete the hybrid connectivity foundation

Active Directory (AD) is designed for multi-master replication, meaning multiple domain controllers hold a copy of the directory database.

Adding a second DC provides:

• High Availability — authentication continues if one DC fails
• Load Distribution — clients can authenticate against different DCs
• Replication Redundancy — AD database changes replicate automatically

In this part, we will:

• Provision a secondary domain controller
• Assign a static IP
• Join the domain
• Install AD DS and promote the server
• Verify replication and health

Let’s get started and add the second domain controller.

Provision Secondary domain controller

For the second DC, create another Windows Server 2022 VM using the same process outlined in the first part of this series.

Ensure that the newly created VM is attached to the same libvirt virtual network so it can reach the primary DC

Run ipconfig /all to confirm the network range, and gateway IP are the same as the primary DC. If you are following along then the gateway should be 192.168.122.1

Assign Static IP

Running ipconfig /all, you will notice a preferred IPv4 address for this VM. It is 192.168.122.145in my case. This IP was handed out by DHCP (dnsmasq) when the VM was created and attached to the virtual network. It can change the next time you restart the virtual network, and the VMs that have joined the domain will not be able to reach the DC. To avoid this, we will assign a static IP to this VM.

Open Server Manager

1. Click Local Server
2. Before setting the static IP, let us rename the computer to HCE-DC02and restart.
3. After restart, go to Local Server and Click the link next to Ethernet
4. A pop-up Right-click your Ethernet adapter → Properties
5. Double-click Internet Protocol Version 4 (TCP/IPv4)
6. Select Use the following IP address option
7. Enter the below values:

IP address: 192.168.122.11 - The static IP we have chosen for secondary DC
Subnet mask: 255.255.255.0
Default gateway: 192.168.122.1 - Bridge’s IP

8. Select Use the following DNS server addresses

Note: Before executing this step, do a small test. Run nslookup and you will notice DNS query is sent to the gateway _192.168.122.1_. dnsmasq, which runs on the gateway, cannot answer query about hybrid.local and forwards it up the chain — to your WiFi router, then to your ISP’s DNS. None of them have ever heard of _hybrid.local_ because it is not a public domain — it exists only inside the primary DC’s DNS. The query times out somewhere in that chain and returns nothing useful

Now, the secondary DC needs to rely on primary DC for any name resolution for domains managed by primary DC. In our case, hybrid.local is visible only in the context of primary DC and for secondary DC to reach other virtual machines in hybrid.local domain, it must consult primary DC’s DNS. That’s why you must set the Preferred DNS server as 192.168.122.10

Set Preferred DNS server: 192.168.122.10

Once the above steps are completed, check if the static IP is updated by running ipconfig

Note around VM rename — Rename the server before promotion — renaming a DC after the fact is not recommended.

Now, we can verify domain controller discovery. Run nslookup in interactive mode

nslookup
set type=SRV
_ldap._tcp.dc._msdcs.hybrid.local

The SRV record should return the hostname of DC1.

Join the Domain

At this point, the VM is able to resolve the primary DC, and it has a static IP assigned. We just need one more step before promoting this VM as secondary DC. It must first be a domain member server.

Unlike the primary DC which created the domain during promotion, the secondary DC is joining a domain that already exists. It needs a computer object, and a secure channel established before the promotion wizard can authenticate against the existing domain and begin replication.

Run PowerShell as Administrator:

Add-Computer -DomainName hybrid.local -Credential HYBRID\Administrator -Restart

After reboot, log in as hybrid\Administrator

To verify domain membership, run whoamiThe current domain\user should be displayed hybrid\administrator

Install Active Directory Domain Services Role

Now that the VM (it’s not a DC yet) has joined the domain, the next step is to make it a domain controller.

Open Server Manager > Click Manage (top right) > Click Add Roles and Features > Click Next until you reach Server Roles > Check: Active Directory Domain Services> When prompted: Click Add Features > Click Next until Install & Click Install

Promote domain controller

After installation completes, click the notification flag. Select: Promote this server to a domain controller and follow the wizard. The server will reboot after installation automatically.

Note on deployment configuration —

While installing pay attention to these attributes

1. when the wizard prompts for a forest, Select: Add a domain controller to an existing domainProvide domain name as hybrid.local
2. Domain controller options — 
   a. check Domain Name System (DNS) serverand Global Catalog
   b. uncheck Read only domain controller (RODC)
   c. Set a Directory Services Restore Mode (DSRM) password
3. Ignore the DNS delegation warning.
4. In Additional Options choose Replicate from:to HCE-DC01.hybrid.local

Verify Both Domain Controllers Exist

The secondary domain controller is set up now. Run the following validation to confirm the promotion succeeded.

On both the DCs, open Active Directory Users and ComputersNavigate to Domain Controller ,You should now see HCE-DC01and HCE-DC02

This confirms both DCs are part of the domain. We have successfully set up High availability for the domain controllers.

Verify Active Directory Replication

Active Directory replicates directory changes between the two controllers automatically. You can check that by running repadmin /replsummary

Example output:

Beginning data collection for replication summary, this may take a while:
…..

Source DSA largest delta fails/total %% error
HCE-DC01 14m:44s 0 / 5 0
HCE-DC02 02m:40s 0 / 5 0

Destination DSA largest delta fails/total %% error
HCE-DC01 02m:40s 0 / 5 0
HCE-DC02 14m:44s 0 / 5 0

Interpretation:

• largest delta → how long since last replication
• fails/total → replication failures

A healthy environment shows: 0 failures This proves multi-master replication is working.

After promotion and replication stabilizes, update DNS settings so each DC points to itself as primary and the other DC as secondary.

Verify SYSVOL Replication

Group Policies live in the SYSVOL folder and must replicate between DCs. Check the share exists by running net shareIt is a quick sanity check.

SYSVOL shares are only published by Windows when the DC considers itself healthy and SYSVOL replication is complete. Their presence confirms that DFS-R has done its job and this DC is ready to serve Group Policy to domain members.

Look for SYSVOL, if they are present, the replication of GPO is working fine.

Identify FSMO Role Holders

Even though AD supports multi-master writes, some operations must be handled by a single role owner to avoid conflicts. These are the FSMO roles (Flexible Single Master Operations).

Check which server holds them netdom query fsmo

Example output:

Schema master HCE-DC01
Domain naming master HCE-DC01
PDC HCE-DC01
RID pool manager HCE-DC01
Infrastructure master HCE-DC01

In small environments like this, all roles may remain on the first DC.

Note: multi-master covers most directory writes; FSMO roles are for the specific operations where a single authority is required to avoid conflicts.

Why Multiple Domain Controllers Matter

With two DCs:

• Both hold a replicated copy of the Active Directory database
• Clients discover them through DNS SRV records
• Clients choose a DC based on site proximity and priority
• If one DC is offline, clients automatically fail over

Authentication flow now becomes:

Client
↓
DNS SRV query
↓
List of Domain Controllers
↓
Client selects reachable DC
↓
Kerberos authentication

This is why clients never hardcode a Domain Controller IP. DNS provides the dynamic discovery layer.

Summary

In this part, we introduced a second domain controller and validated replication, establishing high availability for Active Directory.

Current lab state:

HCE-DC01 → First domain controller
HCE-DC02 → Additional domain controller
Client VM → Domain joined

This completes the Active Directory redundancy layer making it resilient.

In the next part, we will integrate a Linux VM and validate Kerberos-based authentication, extending identity beyond Windows systems.

We will be following the below sequence.

• Promote the Virtual Machine hce-dc01 , created in part 1 as primary domain controller and create domain, forest, and OU
• Create user accounts
• Domain join a Windows client

Primary Domain Controller Configuration

The official Microsoft documentation defines a domain controller as — 
 “A domain controller is a server that is running a version of the Windows Server® operating system and has Active Directory® Domain Services installed.”

For a simple hybrid cloud environment, a domain controller is not mandatory. So, why do we need this? Some hybrid scenarios depend heavily on the on-premises having an identity plane. Example, AD Connect. To introduce the identity plane in our virtual network, we need a server to manage the domain, forest, OU, users, policies, user authentication, and policy enforcement. This will be our domain controller, and the VM we created in part 1 will be used for this purpose.

Before starting this configuration we will run ip addr and take note down the IP range of the virtual bridge and Wi-Fi router. The output of the above command will be a list of all the interfaces running in your box with their IP ranges. Notice the virtual bridge, virbr0 (created when we set up the virtual network, refer to part 1) has a network range of 192.168.122.1/24, in my case

virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 52:54:00:d9:a6:2b brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever

Look for your Wi-Fi router range in the output. wlp58s0 is my Wi-Fi network and it has the range of 192.168.1.1/24

wlp58s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 04:ed:33:e3:9d:f1 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.106/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp58s0
valid_lft 84447sec preferred_lft 84447sec
inet6 fe80::d291:8b3e:4e0:cc87/64 scope link noprefixroute
valid_lft forever preferred_lft forever

virbr0 gateway is 192.168.122.1
wifi router gateway is 192.168.1.1

I will pick an IP from the virbr0 range and assign it to the newly created VM, which is going to be our primary domain controller.

Static IP for Domain Controller

The reason we need a static IP for the domain controller is to ensure that the domain controller is reachable even if the virtual network restarts. dnsmasq — we briefly touched on this in part 1, is responsible for assigning IPs to the virtual machines. When the virtual network restarts, it will act as the DHCP and start handing out IPs to all the VMs connected to virbr0. If the domain controller gets a different IP when the virtual network restarts, it will break the domain join for all the VMs that were part of the domain controller. To avoid this, we will assign static IP for the domain controllers.

Now that we know the IP range of virtual network, I will pick an IP, say 192.168.122.10 as my primary domain controller’s IP.

Login to the Windows Server we created in part 1 and follow below steps to set the static IP —

Before setting the static IP, rename the computer to HCE-DC01 if you haven’t done it already and restart.

Open Server Manager

1. Click **Local Server** -> Click the link next to **Ethernet**
2. A pop-up Right-click your Ethernet adapter → **Properties**
3. Double-click Internet Protocol Version 4 (TCP/IPv4)
4. Select **Use the following IP address** option
5. Enter the below values:

IP address: 192.168.122.10 - The static IP we chose
Subnet mask: 255.255.255.0
Default gateway: 192.168.122.1 - Bridge’s IP

8. Select **Use the following DNS server addresses**

9. Set Preferred DNS server: 192.168.122.10

10. Click OK → Close all windows

Check if the static IP is updated by running ipconfig

When you set up the first Domain Controller, it must use itself as a DNS. Once the secondary domain controller is up, they should ideally cross reference each other

Note of VM rename — Rename the server before promotion — renaming a domain controller after the fact is painful.

Install Active Directory Domain Services Role

For a server to perform the role of a domain controller, it needs certain capabilities. These capabilities include a storage to persist the objects (forest, users, computers, groups, and policies), authentication layer, and policy enforcement mechanisms. This is not a exhaustive list of capabilities. I have listed only those relevant to our hybrid environment right now.

Active Directory Domain Services is a feature that you install on your Windows Server to make it a domain controller. Here is the official definition of AD DS — “A directory is a hierarchical structure that stores information about objects on a network. A directory service, such as Active Directory Domain Services (AD DS), provides methods for storing directory data and making this data available to network users and administrators. For example, AD DS stores information about user accounts, such as names, passwords, phone numbers, and so on. AD DS also provides a way for authorized users on the same network to access this information.”

Rough steps to install AD DS

Open Server Manager > Click Manage (top right) > Click Add Roles and Features > Click Next until you reach Server Roles > Check: Active Directory Domain Services> When prompted: Click Add Features > Click Next until Install & Click Install

I’m not going into the details of the installation as many resources document the process in detail.

With this, the virtual machine has a necessary feature to perform the role of a domain controller.

Promote This Server to a Domain Controller

Installing the AD DS role and promoting the server are two distinct steps, and it’s easy to miss why. Here is the distinction that matters. What makes a server a domain controller is not what’s installed — it’s whether a valid, initialised NTDS.dit exists, the NTDS service is running against it, and the network knows where to find it via SRV records. Promotion is the act of going from capable to instantiated.

Open Server Manager > You should see a yellow triangle notification at top right. Click it. > Click: Promote this server to a domain controller

Note on deployment configuration

While installing, pay attention to these attributes

1. when the wizard prompts for a forest, Select: Add a new forest Root domain name can be given as hybrid.local
2. Domain controller options — 
   a. Forest functional level: leave default 
   b. Domain functional level: leave default 
   c. DNS Server should already be checked 
   d. Global Catalog should be checked 
   e. Do NOT check Read-Only DC 
   f. Set a Directory Services Restore Mode (DSRM) password (Write this down somewhere safe.)
3. Ignore the DNS delegation warning.
4. When creating a new Active Directory forest, the setup process also asks for a NetBIOS name for the domain. NetBIOS is a legacy naming system that predates modern DNS-based Active Directory environments and is widely used in older Windows networks for computer and resource identification. It will auto-fill: HYBRID, Leave it.

Again, I’m not providing detailed steps on every screen of the wizard; this process is well documented. Apart from the attributes I have mentioned above, rest can be left with the default value. If you see any warning when checking the pre-requisites, you can ignore them. They will not have any effect on the environment we are building. We will revisit in future if needed.

⚠ After the installation, the server will reboot automatically.

After the reboot you will be able to login as Administrator to the new domain

Now, we the domain controller up and ready. As a first test, try nslookup google.com. You will see that the domain controller failed to resolve this query. Let’s fix this next.

Adding a DNS Forwarder

After installing Active Directory Domain Services, the Domain Controller also becomes the authoritative DNS server for the new domain (hybrid.local). At this point the DNS server knows how to resolve internal Active Directory records such as domain controllers, LDAP services, and domain-joined machines. However, it has no knowledge of external internet domains like google.com or microsoft.com. When a domain-joined machine sends a DNS query for an external address, the request reaches the domain controller but cannot be resolved. Configuring a DNS forwarder solves this by instructing the DNS server to pass any unknown queries to an upstream resolver (for example, the home router or a public DNS server such as 8.8.8.8). The domain controller therefore resolves internal names itself and forwards everything else, allowing domain clients to access the internet while still using the domain controller as their primary DNS server.

To set up the forwarder, Open Server Manager > Tools → DNS > Double click on your server name > Right-click → Properties > Go to Forwarders tab > Click Edit > Add the virbr0gateway IP 192.168.122.1

If try the lookup again nslookup google.com, it will resolve.

Without a forwarder, the DNS server attempts recursive resolution using root hints, which can introduce delays or timeouts in lab environments behind NAT. Configuring a forwarder provides a faster and more predictable path for resolving external names.

Creating User Accounts

Next, create normal domain users. In the domain controller, launch Active Directory Users and Computers, go to Users folder and create two test users. testuser1 and testuser2. Set password and enable the account.

Create a client VM to join the domain

Now that the domain controller is ready, we can test if client VMs are able to join the new domain we created. To test the domain join, spin up a new Windows VM , our client VM. I created another instance of Windows 2022 Server as I did not want to download another iso, just for the testing.

Join client VM to Domain

When you spin up a new client VM, its preferred DNS will be the gateway 192.168.122.1 (in line with the IP range of the virtual network).

Configure the Client VM’s DNS

Before joining the domain, its DNS server must point to the domain controller’s IP. The reason being the domain hybrid.local is not publicly resolvable like google.com — it exists only in the domain controller’s DNS. If the client VM uses any other DNS server, it will fail to locate the domain controller and the domain join will not proceed.

Set-DnsClientServerAddress -InterfaceAlias “Ethernet” -ServerAddresses 192.168.122.10

if the name “Ethernet” is not resolvable use the below command to look up the actual interface alias

Get-NetAdapter | select Name, InterfaceAlias, Status

Testing the Client

Step 1 — Check the DNS server (from Client VM)

On the client VM, open PowerShell as Administrator and run:

ipconfig /all

DNS Server should be 192.168.122.10

Step 2 — Verify if nslookup resolves (from Client VM)

On the client VM, test domain controller discovery via DNS.

nslookup _ldap._tcp.dc._msdcs.hybrid.local

It should return —

Above snip shows that the test VM now uses the domain controller as it’s DNS and DNS server is responding. We are good to join the domain.

Step 3 — Check if SRV record is correct (from Client VM)

Run nslookup in interactive mode: Inside the prompt, query the SRV record

set type=SRV
_ldap._tcp.dc._msdcs.hybrid.local

If you see your domain controller hostname listed under svr hostname DNS + SRV discovery is working.

Step 4 — Test LDAP connectivity (from Client VM)

From the client, test LDAP connectivity. Test-NetConnection 192.168.122.10 — Port 389.The response should say TcpTestSucceeded : True

Join the domain (from Client VM)

We are all set to join this VM to the domain. Run the below PowerShell command to join the domain

Add-Computer -DomainName hybrid.local -Credential HYBRID\Administrator -Restart

What happens internally:

• Client queries DNS for domain controller (SRV record)
• Client contacts domain controller via LDAP
• Admin credentials authenticated (Kerberos/NTLM) to authorize the join
• Domain controller creates a Computer Object in AD
• Machine account password established — this becomes the secure channel secret
• Client reboots as domain member

Verification

Domain membership verification — Log in as HYBRID\testuser1 - that you created earlier. Run whoami; should return: hybrid\testuser1.echo %logonserver% should show your domain controller hostname \\HCE-DC01.

This proves that Kerberos + secure channel + domain controller communication is working.

Validate AD Object Creation — On the domain controller, if you open **Active Directory Users and Computers** and go to **Computers** you should see your client machine listed. This proves that AD object lifecycle works.

Summary

In this part we set up a domain controller, domain joined a VM and tested the connectivity. Although single Domain Controller set up works, it is a single point of failure. If the only domain controller fails:

1. Authentication stops
2. Kerberos tickets cannot be issued
3. Group Policy stops applying
4. New logons fail

In the next part, we will build redundancy for the domain controller by adding a secondary domain controller.

In this series, I will take you through building an on-premises / Azure hybrid environment, with the on-premises network running entirely on a single machine. We will set up an on-premises Active Directory forest, create OUs and users, deploy domain controllers, join Windows and Linux VMs to the domain, and establish hybrid connectivity to Azure using an S2S VPN tunnel.

I want to clarify right at the outset that on-premises identity is not a mandatory starting point for a hybrid cloud environment. But I have chosen to build it from the ground up starting with the identity plane (on-premises Active Directory) .

To follow along you do not require deep networking or Linux expertise, but comfort with basic bash and networking concepts will help — and we will build the required knowledge as we go. Where appropriate, I will reference official documentation rather than re-explaining well-documented concepts.

At the end of this series, I will share my Github repo with the automation scripts for the infrastructure.

When I started exploring hybrid environments, I assumed it would require multiple machines, dedicated networking, and possibly additional hardware. That made it feel like something I couldn’t easily experiment with on my own setup. As I explored further, I realized those assumptions weren’t entirely true. I was able to build a working hybrid environment on my laptop, keeping everything contained and manageable. This series documents how I put it together. Here’s the setup I’m using: a laptop running Linux Mint 22.1 (Xia) with 16 GB RAM, a regular home Wi-Fi router, and an Azure subscription (PAYG).Let’s get started.

Building an On-premises virtual network

In this first part of the series, I will set up the virtual network on my Linux laptop. This is the foundation for the hybrid environment we are building. By the end of this article, we will have laid the foundation which will include a virtual network — our on-premises representation and a Virtual Machine within the virtual network.

The above diagram shows what we will have in place by the end of this article.

Software prerequisites and why you need them

The on-premises network is virtual. We will need libraries and applications that enable the creation and management of virtual networks and virtual machines. Follow the below steps to prepare the environment.

Installation steps for KVM, QEMU, libvirt and virt-manager vary by Linux distribution and version. Refer to your distribution’s documentation for the correct package names and commands

• Verify virtualization is enabled — Run egrep -c '(vmx|svm)' /proc/cpuinfo A result greater than 0 means your CPU supports hardware virtualization and you’re good to go.
• Install KVM hypervisor and QEMU — These two work as a pair. KVM is the Linux kernel module that provides hardware virtualization, allowing the Guest OS to execute instructions directly on the host CPU at near-native speed. QEMU handles the emulated hardware that the Guest OS interacts with — the virtual disk drives, the network card, and the VGA BIOS that Windows thinks it’s seeing.
• Install libvirt — this is the virtualization manager I will be using to manage my virtual network. It is the control layer. It translates GUI actions into XML definitions and complex command-line instructions for the hypervisor. It manages storage pools, virtual networks, and VM lifecycle. For example, you add a new virtual hardware, say, a CDROM, libvirt will generate the XML configuration to support CDROM virtualization which will then be read and processed by QEMU.
• Virtual Machine Manager (virt-manager) — a handy GUI for libvirt. You launch it with virt-manager, and it lets you create and manage VMs but does not run them.
• Download Windows Server 2022 Evaluation version ISO file. The OS must be a server OS that supports Active Directory Domain Services and hence I’ve chosen Windows Server 2022
• Download virtIO from https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso

Once the above steps are completed, run virsh net-list --all This should show the default network that libvirt just created.

At this stage, the virtual network is up and all the tools needed to create and manage VMs are in place.

Role of libvirt, virt-manager, KVM and QEMU

It helps to build a simple mental model of how these components fit together — specifically, how virt-manager interacts with the underlying hypervisor.

The Management Flow (Control Plane) — when you create or configure a VM:

virt-manager → libvirt → QEMU/KVM

• virt-manager provides the GUI
• libvirt acts as the control layer, translating actions into configurations
• QEMU/KVM executes those configurations

The Execution Flow (Data Plane) — when something runs inside the VM:

User → Guest OS (Windows) → QEMU → KVM → Hardware

• QEMU handles device emulation (disk, NIC, etc.)
• KVM provides direct access to CPU virtualization features

This separation helps explain why VM configuration and VM execution are two different layers.

Virtual Networking

Before we create the virtual machine, a few networking concepts around virtual networking and libvirt are worth clarifying.

Virtual network — the private address space where your VMs live. They exist only inside the host and are not visible to the WiFi network that is connecting your laptop with other laptops, phones and other devices in your WiFi network.

Bridge (virbr0)— Layer 2 construct — the virtual switch that connects your VMs to each other and to the host, like a physical switch in a rack. Imagine VM1 wants to send a packet to VM2, it forwards traffic based on MAC address learning (similar to a Layer 2 switch) and will forward the packet to VM2. It acts like a Layer 2 switch inside your Linux host. Every VM connected to the default network, plugs into this switch.

Gateway (192.168.122.1) — Layer 3 construct — the door out of the virtual network; packets destined for anywhere outside the virtual network go here first and then get routed based on the defined route table.

Gateway vs bridge — At first, they looked similar to me. It took me some time to understand the difference. The bridge connects devices at Layer 2 by MAC address. If two VMs in the same virtual network want to talk, the bridge connects them; they bypass the gateway. The gateway is the IP address assigned to the bridge interface, acting as the Layer 3 entry/exit point for the virtual network. It is the address VMs use when sending traffic outside the virtual network

VMs talk to each other through the bridge, they talk to the outside world through the gateway, and the virtual network is the address space that gives them all a place to live.

When libvirt is first installed, it automatically creates a default virtual network with a virtual switch called virbr0 — visible via ip a. Behind this bridge, libvirt configures dnsmasq for DHCP and DNS, and uses iptables/nftables on the host to provide NAT routing. Any VM you create is connected to this network unless you specify otherwise.

libvirt modes

libvirt supports three modes, namely, NAT, Bridge and Internal. For our hybrid environment, the virtual network uses NAT mode described in https://wiki.libvirt.org/VirtualNetworking.html meaning that the WiFi router sees all packets from the virtual network as originating from the Linux host. It has no notion of the virtual network. This approach requires no changes to the home network and keeps the virtual environment isolated, while still allowing outbound internet access.

Use bridged networking if you want your virtual machines to obtain an IP address from your LAN. Or use Internal Network if you want a fully isolated lab.

Traffic flow in default (NAT) mode looks like this:

VM →
virtual NIC →
virbr0 (virtual switch) →
NAT (iptables/nftables on host) →
Linux host →
physical network →
internet

If you use bridged mode, the VM connects directly to your physical network through a Linux bridge (e.g., br0). In that case:

VM →
virtual NIC →
Linux bridge →
physical NIC →
real LAN

No NAT. The VM behaves like a real machine on your network.

Creating Virtual Machines

Now, we can start creating a Virtual Machine. This virtual machine will be the primary domain controller (will be covered in Part 2), so, let’s name it appropriately. I will call it hce-dc01. Give at least: 4 GB RAM, 2 vCPU, 60 GB disk for the virtual machine. This sizing is sufficient for a lightweight domain controller while keeping resource usage manageable on a single host machine.

Launch virt-manager from the terminal. It opens up the GUI of virtual manager. Select option to create a new VM, follow the wizard by providing configurations as outlined above. Use the downloaded ISO image and install Windows Server OS. The installation is quite straightforward.

Important — Make sure you install Windows Server 2022 Desktop Experience.

Once the Windows Server 2022 OS is installed, the VM will reboot allowing you to set the Administrator password.

Once the VM is ready, go to the details view and verify the below settings.

For Virtual NIC choose — e1000e. This is an emulated Intel NIC that Windows recognizes out of the box — it gets you network access during installation before VirtIO (discussed in the next section) drivers are in place.

For video select QXL — this is a paravirtualized display adapter that gives you a responsive desktop with better resolution support compared to the default VGA

Add VirtIO ISO as CD-ROM in virt-manager

What and Why? — [VirtIO](https://wiki.libvirt.org/Virtio.html) is a paravirtualized device interface used between Windows and QEMU. Instead of emulating physical hardware like SATA or Intel NICs, VirtIO provides purpose-built virtual drivers that both the guest and hypervisor understand directly — reducing CPU overhead and improving throughput.

Follow the below steps to install VirtIO

1. Open virt-manager → select your VM → Open → Show virtual hardware details
2. Click Add Hardware → Storage → CD-ROM
3. Choose Select or create custom storage → point to ~/ISOs/virtio-win.iso
4. Boot (or reboot) the VM

Now inside the VM you will see two CD-ROMs:

• SATA CDROM1 → Windows Server ISO
• VirtIO CD-ROM → drivers

Installing VirtIO
Now that we have the VirtIO ISO mounted to VM as a CDROM drive, navigate to the CDROM drive and run the exe installer (**virtio-win-gt-x64.exe**) It installs all the necessary VirtIO drivers for disk, network, and optional devices automatically. Once the drivers are installed, shut down the VM, change the NIC type to ‘virtio’ in virt-manager, and then start it back up for better throughput.

This step completes the configuration of the Windows Virtual Machine. When hce-dc01 was created, virt-manager automatically connected it to the default virtual network created by libvirt — Let’s verify that now

Verification

To confirm the virtual network is configured correctly, run virsh net-dumpxml default

<network connections=‘1’>
<name>default</name>
<uuid>73e80935-c747-4ad7-88a1-5417707abc02</uuid>
<forward mode=‘nat’>
<nat>
<port start=‘1024’ end=‘65535’/>
</nat>
</forward>
<bridge name=‘virbr0’ stp=‘on’ delay=‘0’/>
<mac address=‘52:54:00:d9:a6:2b’/>
<ip address=‘192.168.122.1’ netmask=‘255.255.255.0’>
<dhcp>
<range start=‘192.168.122.2’ end=‘192.168.122.254’/>
</dhcp>
</ip>
</network>

In the above snippet you will notice that bridge virbr0 is configured with a DHCP range from 192.168.122.2 to 192.168.122.254.

Login to the new VM and check its IP (ipconfig). You will see an IP within this range allocated by dnsmasq.

Also, remember this range must not overlap with the range your Wi-Fi provides (it usually doesn’t, but worth noting)

Summary

With these steps, we have a working virtual network and a Windows Server 2022 VM ready to be configured. In the next part, we will turn this VM into a fully functional Active Directory domain controller — laying the groundwork for identity in our hybrid environment.

This guide outlines the process for assigning application roles to a Managed Identity (MI) in Entra ID. It covers observed behaviors, inherent limitations, and the necessary steps required when an MI must authenticate with another application (such as an API in APIM) using role-based access control (RBAC).

Scenario

In a typical architecture, a Logic App utilizes a Managed Identity (either System-Assigned or User-Assigned) to communicate with downstream resources. When that Logic App needs to call an API exposed via APIM, the following requirements usually apply:

• The API is protected by its own App Registration in Entra ID.
• The API expects the caller to possess specific app roles (e.g., API.Read or API.ReadWrite).
• The Logic App must obtain an OAuth token containing these roles to successfully authorize against the API.

The Challenge

Managed Identities are automatically created Service Principals. A common point of confusion is that they do not appear in the App Registration section of the Azure portal; they are found exclusively under Enterprise Applications.

Because the Azure portal does not currently provide a UI for assigning app roles to Enterprise Applications directly, it is not possible to assign roles like API.Read through the standard “API Permissions” blade used for traditional App Registrations.

The Workaround — Assigning App Roles via PowerShell / Microsoft Graph

You can use the below Powershell to assign roles to your Managed Identity

# Install-Module Microsoft.Graph -Scope CurrentUser (If not done already)

# Your tenant ID (in the Azure portal, under Azure Active Directory > Overview).
$tenantID = ‘{tenantId}’

# The name of the server app that exposes the app roles.
$serverApplicationName = ‘{serverApplicationName}’

# The name of the app role that the managed identity should be assigned to.
$appRoleName = ‘{appRoleName}’ # For example, Api.Read

# Look up the Logic App / Function (Client application) managed identity’s object ID.
$managedIdentityObjectId = ‘{managedIdentityObjectId}’

# Connect-MgGraph -TenantId $tenantId -Scopes ‘Application.ReadWrite.All’,‘Directory.Read.All’
# or a more restricted set of permissions (recommended):
Connect-MgGraph -TenantId $tenantId -Scopes ‘Application.Read.All’,‘AppRoleAssignment.ReadWrite.All’

# Look up the details about the server app’s service principal and app role.
$serverServicePrincipal = (Get-MgServicePrincipal -Filter “DisplayName eq ‘$serverApplicationName’”)
$serverServicePrincipalObjectId = $serverServicePrincipal.Id
$appRoleId = ($serverServicePrincipal.AppRoles | Where-Object {$_.Value -eq $appRoleName }).Id

Write-Host ‘$serverServicePrincipal ’ $serverServicePrincipal
Write-Host ‘$managedIdentityObjectId ’ $managedIdentityObjectId
Write-Host ‘$serverServicePrincipalObjectId ’ $serverServicePrincipalObjectId
Write-Host ‘AppRoleId >’ $appRoleId

# Assign the managed identity access to the app role.
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $serverServicePrincipalObjectId -PrincipalId $managedIdentityObjectId -ResourceId $serverServicePrincipalObjectId -AppRoleId $appRoleId

• PrincipalId → Managed Identity object ID (Logic App)
• ResourceId → API service principal object ID
• AppRoleId → GUID of the role defined in the API registration

After this assignment, tokens requested by the Managed Identity will include the required roles claim, allowing successful authorization against the API.

Note

• For clientId to be able to be used as an audience it must “own” App Roles. And the consumer-client-id should have been provided this roles in AAD. I think you can further check these claims in the Authentication section

Key Takeaways

• Managed Identities always appear as Enterprise Apps in Azure AD.
• App roles cannot be assigned via the portal for Enterprise Apps; Graph / PowerShell is required.
• Token validation depends on correct Issuer, Audience, and presence of role claims.
• Explicit role assignment ensures tokens carry the required roles for API authorization.

Symptom

Calling Azure Table Storage REST API returns:

403 Server failed to authenticate the request.
Make sure the value of Authorization header is formed correctly including the signature.

Even though Authorization header looks valid

Root Cause

The request is missing x-ms-version header

Azure Storage requires this header to determine the API version used for request validation. Without it, the service may reject the request with a misleading authentication error.

Fix

Add header

x-ms-version: 2020–08–04

Example minimal headers:

x-ms-version: 2020–08–04
Accept: application/json;odata=nometadata
Content-Type: application/json

Lesson learned

If Azure Storage returns a 403 authentication error for a manually signed REST request, check for missing x-ms-version before debugging the signature.