Deploy and Manage Domain Controllers in Azure.
Well you're probably thinking, Tim, are you going to demo this?
I absolutely am and I'm going to demo on‑premises Active Directory installation
and Azure installation. Here, we see our first topology diagram in Azure, and
the two options for extending your on‑premises network into a virtual network
in Azure are a site‑to‑site virtual private network, or VPN, and an
ExpressRoute circuit, or I should say,
or you could technically combine them both,
but normally it's an either/or proposition.
Either of these methods is going to be an always on connection between your
on‑premises edge and a virtual network. Common pattern is to VPN or
ExpressRoute into one virtual network that's your transit or hub, and then you
use virtual network peering to create routing paths among additional virtual
networks that are connected to your hub.
What makes this happen here with site‑to‑site VPNS is a IPSec IKEv2 tunnel.
It's a traditional virtual private network, which is a secure
tunnel over the internet and unsecure medium.
In Azure, you're you're going to need a virtual network gateway deployed into
its own subnet. You'll also need to create what's called a local gateway
resource in your Azure subscription that records the public IP address of
your on‑premises gateway, as well as the IP subnet addresses that you want to
route to and from on‑premises.
Lastly,
you create a connection and you'll need to configure obviously both your
local on‑premises gateway, as well as your virtual network gateway in Azure
and handshake them together using a pre‑shared key.
ExpressRoute is more expensive and more complicated to set up.
You'll need to work with an ExpressRoute provider, unless you go
the ExpressRoute direct route with Microsoft.
This is going to involve you bring in a couple redundant routers to the table
and do some extra work, but in what's compare and contrast,
both of these methods present a way to extend your network at Layer 3
into Azure such that you then can have Windows servers in your virtual
network that can then join your local AD DS domain or you could deploy
domain controllers in Azure that serve the on‑premises domain or you
could create a separate forest and do a forest‑to‑forest trust across
the cloud.
I mean, so many patterns there work. We have to remember, though, the
bottom line is that site‑to‑site VPN and ExpressRoute allow the
protocols and ports that we use in Active Directory just fine because
you've truly extended the network.
Another point to consider is that ExpressRoute bypasses the public internet.
So if AZ800 mentions that as a requirement in a case study,
you know they'll be asking you about ExpressRoute rather than a
site‑to‑site VPN, but as far as actually installing Active Directory
and promoting a server to a domain controller,
it's absolutely identical in Azure as it is on‑premises, it's just
going to be some mechanisms that you can use to do that could be
different as you'll see in the demo. Our hybrid cloud lab topology
that I've built for us looks like this.
First, we see at left a forest that consists of two domains.
My headquarters domain is timw.info.
I'm going to have two domain controllers there, as well as a Windows 11
client machine that I'll use for administration. We'll deploy a child
domain called appropriately enough child.timw.info that has a read/write
domain controller called CDC1, and also, a read‑only domain controller,
crodc1. I have a site‑to‑site VPN up that links my on‑premises
timw.infoforest into the cloud, and we'll deploy a third timw.info domain
controller in Azure.
And again,
you'll just see that it's the exact same processes as on‑prem
with some Azure‑specific optional twists.
And then lastly, we have another forest called acq.com with one
domain controller and this will serve as a nice springboard into the
next module when we look at trust relationships, in particular, interforest trust relationships.