1 00:00:01,040 --> 00:00:03,940 Deploy and Manage Domain Controllers in Azure. 2 00:00:03,940 --> 00:00:06,250 Well you're probably thinking, Tim, are you going to demo this? 3 00:00:06,250 --> 00:00:11,300 I absolutely am and I'm going to demo on‑premises Active Directory installation 4 00:00:11,300 --> 00:00:16,470 and Azure installation. Here, we see our first topology diagram in Azure, and 5 00:00:16,470 --> 00:00:20,740 the two options for extending your on‑premises network into a virtual network 6 00:00:20,740 --> 00:00:24,570 in Azure are a site‑to‑site virtual private network, or VPN, and an 7 00:00:24,570 --> 00:00:26,440 ExpressRoute circuit, or I should say, 8 00:00:26,440 --> 00:00:28,990 or you could technically combine them both, 9 00:00:28,990 --> 00:00:31,180 but normally it's an either/or proposition. 10 00:00:31,180 --> 00:00:35,080 Either of these methods is going to be an always on connection between your 11 00:00:35,080 --> 00:00:40,010 on‑premises edge and a virtual network. Common pattern is to VPN or 12 00:00:40,010 --> 00:00:44,590 ExpressRoute into one virtual network that's your transit or hub, and then you 13 00:00:44,590 --> 00:00:49,330 use virtual network peering to create routing paths among additional virtual 14 00:00:49,330 --> 00:00:51,290 networks that are connected to your hub. 15 00:00:51,290 --> 00:00:57,060 What makes this happen here with site‑to‑site VPNS is a IPSec IKEv2 tunnel. 16 00:00:57,060 --> 00:01:00,210 It's a traditional virtual private network, which is a secure 17 00:01:00,210 --> 00:01:02,790 tunnel over the internet and unsecure medium. 18 00:01:02,790 --> 00:01:06,020 In Azure, you're you're going to need a virtual network gateway deployed into 19 00:01:06,020 --> 00:01:09,360 its own subnet. You'll also need to create what's called a local gateway 20 00:01:09,360 --> 00:01:13,370 resource in your Azure subscription that records the public IP address of 21 00:01:13,370 --> 00:01:18,000 your on‑premises gateway, as well as the IP subnet addresses that you want to 22 00:01:18,000 --> 00:01:20,330 route to and from on‑premises. 23 00:01:20,330 --> 00:01:20,780 Lastly, 24 00:01:20,780 --> 00:01:24,420 you create a connection and you'll need to configure obviously both your 25 00:01:24,420 --> 00:01:28,970 local on‑premises gateway, as well as your virtual network gateway in Azure 26 00:01:28,970 --> 00:01:31,830 and handshake them together using a pre‑shared key. 27 00:01:31,830 --> 00:01:35,060 ExpressRoute is more expensive and more complicated to set up. 28 00:01:35,060 --> 00:01:38,170 You'll need to work with an ExpressRoute provider, unless you go 29 00:01:38,170 --> 00:01:40,900 the ExpressRoute direct route with Microsoft. 30 00:01:40,900 --> 00:01:44,680 This is going to involve you bring in a couple redundant routers to the table 31 00:01:44,680 --> 00:01:48,090 and do some extra work, but in what's compare and contrast, 32 00:01:48,090 --> 00:01:52,450 both of these methods present a way to extend your network at Layer 3 33 00:01:52,450 --> 00:01:57,540 into Azure such that you then can have Windows servers in your virtual 34 00:01:57,540 --> 00:02:03,200 network that can then join your local AD DS domain or you could deploy 35 00:02:03,200 --> 00:02:08,510 domain controllers in Azure that serve the on‑premises domain or you 36 00:02:08,510 --> 00:02:12,970 could create a separate forest and do a forest‑to‑forest trust across 37 00:02:12,970 --> 00:02:13,300 the cloud. 38 00:02:13,300 --> 00:02:16,650 I mean, so many patterns there work. We have to remember, though, the 39 00:02:16,650 --> 00:02:20,730 bottom line is that site‑to‑site VPN and ExpressRoute allow the 40 00:02:20,730 --> 00:02:25,350 protocols and ports that we use in Active Directory just fine because 41 00:02:25,350 --> 00:02:27,270 you've truly extended the network. 42 00:02:27,270 --> 00:02:31,320 Another point to consider is that ExpressRoute bypasses the public internet. 43 00:02:31,320 --> 00:02:35,060 So if AZ800 mentions that as a requirement in a case study, 44 00:02:35,060 --> 00:02:38,170 you know they'll be asking you about ExpressRoute rather than a 45 00:02:38,170 --> 00:02:42,470 site‑to‑site VPN, but as far as actually installing Active Directory 46 00:02:42,470 --> 00:02:45,490 and promoting a server to a domain controller, 47 00:02:45,490 --> 00:02:49,490 it's absolutely identical in Azure as it is on‑premises, it's just 48 00:02:49,490 --> 00:02:53,010 going to be some mechanisms that you can use to do that could be 49 00:02:53,010 --> 00:02:57,600 different as you'll see in the demo. Our hybrid cloud lab topology 50 00:02:57,600 --> 00:02:59,370 that I've built for us looks like this. 51 00:02:59,370 --> 00:03:03,400 First, we see at left a forest that consists of two domains. 52 00:03:03,400 --> 00:03:06,540 My headquarters domain is timw.info. 53 00:03:06,540 --> 00:03:10,690 I'm going to have two domain controllers there, as well as a Windows 11 54 00:03:10,690 --> 00:03:14,460 client machine that I'll use for administration. We'll deploy a child 55 00:03:14,460 --> 00:03:19,890 domain called appropriately enough child.timw.info that has a read/write 56 00:03:19,890 --> 00:03:24,390 domain controller called CDC1, and also, a read‑only domain controller, 57 00:03:24,390 --> 00:03:29,470 crodc1. I have a site‑to‑site VPN up that links my on‑premises 58 00:03:29,470 --> 00:03:35,340 timw.infoforest into the cloud, and we'll deploy a third timw.info domain 59 00:03:35,340 --> 00:03:36,700 controller in Azure. 60 00:03:36,700 --> 00:03:37,150 And again, 61 00:03:37,150 --> 00:03:40,360 you'll just see that it's the exact same processes as on‑prem 62 00:03:40,360 --> 00:03:43,230 with some Azure‑specific optional twists. 63 00:03:43,230 --> 00:03:48,130 And then lastly, we have another forest called acq.com with one 64 00:03:48,130 --> 00:03:51,790 domain controller and this will serve as a nice springboard into the 65 00:03:51,790 --> 00:03:58,000 next module when we look at trust relationships, in particular, interforest trust relationships.