Hyper-V Masterclass – Debunking Virtual Domain Controller Myths
Articles,  Blog

Hyper-V Masterclass – Debunking Virtual Domain Controller Myths


Hello and welcome to our video Hyper-V and Virtual Domain Controllers: A Myth-Busting Session My name is Eric Siron. I frequently contribute to the Hyper-V Blog hosted by Altaro Software I have been awarded by Microsoft as a Cloud and Datacenter Management MVP with a primary focus on Hyper-V This video is sponsored and distributed by Altaro Software, makers of Altaro VM Backup The software is an easy-to-use Virtual Machine backup solution for Microsoft Hyper-v and VMware vSphere In this video we intend to debunk some of the most crippling myths around Hyper-V and domain controllers Believing these myths makes your Hyper-V deployment less secure and more difficult to manage This video will tackle two myths The first insists that Hyper-V must not be in the domain at all The second says that a Hyper-V system cannot host its own domain controller We’re going to take just a few moments to quickly step through the falsehoods that support these myths Once that’s done we’re going to see a demonstration that destroys these myths The Altaro blog hosts a detailed discussion that examines the myths of Hyper-V and domain controllers You can read it at the URL on the screen We’re only going to briefly touch on those points in this video The most important thing to understand is that workgroup mode never provides a superior security model over domain mode Workgroup mode is literally peer-to-peer networking. No work group member considers any other computer to have any authority The domain security model establishes a hierarchical system to validate remote computer identities When you attach to a domain joint Hyper-V hosts It asks the domain controller to vouch for the identity of both you and the computer that you are using Workgroup mode does not allow that One reason that some people leave their Hyper-V hosts out of the domain is when all of its guests are in an unsecure internet connected network typically referred to as a DMZ That looks something like this Your guests are connect the DMZ because you want them to be accessible to anonymous users Why would you ever want that for your Hyper-V hosts? A Hyper-v host can be safely connected to an internal secured network even when all of its guests are connected to unsecured networks We also know that bad domain configurations and policies can cause problems for Hyper-V hosts However, that’s true for just about anything Your first solution should be to clean up your domain If you can’t do that your second choice should be to place your Hyper-V hosts into an organizational unit that blocks inheritance Leaving them out of the domain is not a solution Finally, administrators with only one Hyper-V host worry about the chicken-and-egg problem That’s part of our next myth, so let’s move on to that discussion The chicken-and-egg myth plays a major role in this video, so let’s get a smaller problem out of the way first Time drift Microsoft operating systems are not considered real-time That means that they do not have a strict dependence on time keeping and do not contain any mechanism that guarantees time accuracy Even the most stringent Microsoft systems allow for time variances of several minutes Because it virtualizes computer hardware Hyper-V must also emulate a real-time clock for its guests That depends on Windows software so it isn’t truly real-time The inevitable result is that Hyper-V guest clocks will drift That time drift can pose a particular problem for virtualized domain controllers First, the domain controller with the primary domain controller flexible single master operation FSMO role is considered the authority for time in a domain If you only have one domain controller and that’s running on Hyper-V and the Hyper-V system is part of the domain then you have created a circular dependency That problem is easy to solve disable time synchronization for all virtualized domain controllers and ensure that your domain time is properly configured We have an article that explains how to do that at the URL shown on your screen Now we can move on to the chicken-and-egg problem This myth states that if a Hyper-V system hosts the domain controller and is joined to that domain then Hyper-V will not be able to start That is completely false Anyone with the domain joined laptop that has ever traveled to any location away from the domain has already debunked this Hyper-V is never really joined to the domain Its management operating system is a domain member Hyper-V runs above its management operating system Therefore, Hyper-V can never truly be made dependent upon domain availability Let’s see it in action I have a physical Hyper-V host running Windows Server 2016 It has a single guest also running Windows Server 2016 They are completely isolated from the physical network. They can’t talk to anyone except each other We’re going to create a new domain and forest Then we will join the Hyper-V hosts to that domain Then we’re going to test it all out I am using mesh commander to connect directly to the Hyper-V host out-of-band management interface All of its physical adapters are disabled It does have an internal virtual switch And on that it has an IP address on a network I created just for this It hosts a single virtual machine that we’ll be using as our domain controller This virtual machine has an IP address on the same network And I’ve installed the prerequisites earlier so now let’s create our Active Directory forest This is a domain that I have registered And it is installing and this will take several minutes Okay the domain controller is installed So we’re going to let it restart All right, we’re back, let’s test login See that it does want to log into that new domain that we just created And it worked so the main controller is now created Okay, so now that we’re back to our host. Let’s start off by disabling the time sync service for that VM Which is right here And for demo purposes, let’s also turn off the automatic start And at some point I need to come in and change this automatic stop action to be shut down instead of saved But I can’t do that because the virtual machine’s running, so we’ll do that later Okay, let’s join our host to the domain Okay, that was easy enough Let’s go ahead and restart it Because we did not Set our virtual machine to auto start it will take longer to reboot than normal because it will look for a domain and it won’t find it However, notice that it will start Okay, so now we’re booted See it does want to use local credentials because it’s a new domain join So let’s see what happens if we log into our domain Even though we know that our domain controller is not running Cause it’s looking for it and we know that it’s not on so that’s why it’s taking so long So then it tells us No logon server is available We’ve never logged on so what are we gonna do? We’re going to say okay We’ll go back to our local login and login that way Okay, so now we’ve successfully started give it a minute or two for it to do all of its startup routines They’re up secure the main controller started In production you’ll want to ensure that virtualized domain controllers are set to always start with a delay of 0 Doing so ensures that domain services will be available and responsive as quickly as possible Ok so now it’s running Ok so let’s see what happens on a normal restart of the host Should go much more quickly this time And the main controller should be started this time so it should work out This looks promising And there you have it, its logging in our domain administrator account Even though the domain controller is a guest of this host Everything is okay Going forward, if you were to have a domain controller problem you would still have cash credentials You would be able to log in as a domain admin. Even if that guest did not start Now also, I just need to be sure that I can figure backup for my domain controller So that if something were to happen I would be able to restore it I could always log in locally if I needed to Everything would be fine That concludes our session on myth-busting Hyper-V and domain controllers Please visit us at Altaro.com and thanks for watching

Leave a Reply

Your email address will not be published. Required fields are marked *