Save to My DOJO
There are two Hyper-V-related topics that I simply will not take questions on anymore. It’s not because I don’t like you or because I doubt that you’re truly in crisis. It’s because I believe that the cornucopia of warning signs has existed long enough that you could have easily avoided your predicament and that there will be no positive return on any time invested in helping you continue on your current path. The first of these topics is pass-through disks. Stop using them and you’ll stop having trouble with them; it really is as simple as that. The second is the topic of this post: Hyper-V hosts in workgroup mode. I have tried to find the poisoned wellspring whose judgment-clouding miasma has caused so many administrators to make this ill-fated decision, but have come up empty. I see a great many people explaining how to do it, which lends the practice an undeserved credibility. I realize that I have contributed to that as well; people wanted to know how to do it so I talked about how to do it. However, I can’t find anyone with any recognized level of authority claiming that a Hyper-V host should be excluded from the domain. It is time that we, as a community, start proclaiming that the act of placing Hyper-V hosts in workgroup-mode is poor practice.
Exceptions
Few things in this industry are fixed rules, and the domain vs. workgroup decision for Hyper-V is not one of the few. Here are a few solid reason for not joining a Hyper-V host to a domain:
- You don’t have a domain. If not having a domain is working for you, I wouldn’t create one just for Hyper-V. Home systems are great examples. Very tiny networks are good examples. Networks where the Hyper-V host is the only Microsoft server system are good examples.
- All the guests are in a DMZ and you don’t want to connect the physical unit to your internal network. I have done a fair bit with DMZ-based systems in my career and I don’t really believe that this reason is very solid. The Hyper-V host and its guests can be completely isolated from each other so that there is no meaningful risk of having the host exist on a protected internal network while one or more guests live entirely in a DMZ. That said, the principle is not entirely without merit and might be worth it if it makes your security officer happier. However, if the host is in the DMZ, then it must be treated like any other computer in the DMZ; that means that you cannot perform any of the security-reducing tasks that must be done to manage it remotely.
- You have committed crimes against humanity and are seeking redemption. Remotely managing a non-domain-joined Hyper-V host by anything but RDP is ridiculously complicated and frustrating. It will work one day and not the next, just because. Every time you install an operating system update on any involved system, you’ll wonder if that’s the last time the remote connection will ever work. If you believe that you have done something so terrible as to deserve this fate, then I suppose I shouldn’t hinder you. But, I also shouldn’t help you, because that would defeat the purpose. Looking up the answers on the Internet is cheating. [Note: if you have actually committed crimes against humanity, then you are a bad person. However horrid the experience may be, using workgroup-joined Hyper-V will not absolve anyone of any atrocities.]
Even if one of the above situations applies to you, your solution should be to open the firewall on port 3389 to specified sources, enable Remote Desktop, and work with your host in an RDP session.
Responding to the Common Reasons for Leaving a Hyper-V Host Out of the Domain
Just as it’s tough to find any experts recommending this configuration, it’s surprisingly difficult to find people giving reasons for why they choose this route. I can’t tell if they think that everyone does it that way and that they’re just following the crowd or if they’ve locked themselves onto a particular course of action and reason and logic aren’t playing a part. I did find a couple of explanations, so we’ll tackle them head on.
Myth 1: Leaving a Hyper-V Host Out of the Domain Increases Security
Repeat after me: There is absolutely no condition in which a workgroup configuration is more secure than a domain configuration. It might be possible that your domain’s security is awful, but putting any connected system in a workgroup just makes everything more awful. If you then take the next step of configuring the host so that you can manage it remotely by MMC consoles, you have reduced its security below the already-pitiful protection of the workgroup system.
- Using the TrustedHosts configuration at all lowers security. What this does is tell the system: “any computer, literally any computer, that claims to have a name on this list — trust it completely”. It is trivially simple to watch computer names travel across a network via broadcast, determine who is communicating with whom, and then spoof a name.
- Authentication to remote workgroup-connected machines requires the full credential set to be passed to the target system on each connection. If the authentication communication is intercepted, it can be compromised. I don’t dabble much in black/white hat techniques so I wouldn’t know for sure, but I wouldn’t be surprised if simply duplicating the response packet would work just as well since machine authentication has been bypassed with TrustedHosts.
- That tinkering that you have to do in DCOMCNFG? All of that is reducing security. I don’t even like granting read permissions to Anonymous, and here some of you are giving it administrative privileges.
I’m sure that this myth arose from some well-meaning place. Someone was probably thinking that if their Hyper-V host was compromised and a member of the domain, that the domain would similarly be compromised. Examine that for what it is. If it were true, then no computer should ever be joined to any domain for precisely the same reason. Think of what would happen if any domain member were compromised. The risks are the same. If your workgroup-connected Hyper-V host is operating even one domain-joined virtual machine, then a successful assault against the host makes its domain-joined status irrelevant. Maybe someone believed the opposite — that if the domain were compromised and the Hyper-V host wasn’t part of it, that the Hyper-V host would remain unaffected. All else being equal, cracking domain security is exceedingly more difficult than cracking workgroup security. If someone has broken into your directory, they’ll have your workgroup hosts as soon as they want them, especially if you’ve taken all of the security-reducing steps necessary for remote connectivity.
To expose this as a myth, if I were interviewing a systems administration job candidate and that person said that s/he chooses workgroup mode for anything except roles intentionally exposed directly to the Internet on the grounds that workgroup mode is more secure than domain mode, that person would not be hired. Qualifying it with, “but only for Hyper-V,” is nonsensical.
Myth 2: The Hyper-V Domain Controller Myths
I tackle issues in this category often, and I’m very disheartened that they do not appear to be losing force. If you’re not familiar with what I’m talking about, there are a few myths that involve Hyper-V and domain controllers, with the basic premise of all of them being that if a Hyper-V host cannot reach a domain controller, something critical will not work. Every single one of these notions is false. This is not the post in which I wish to have this discussion, so I’m just going to leave it with a few simple remarks. Hyper-V does not need a domain controller to start. It does not need a domain controller to start its guests. It does not need a domain controller to allow you to log on using local credentials. If the cached credentials feature is enabled in your domain, Hyper-V does not need a domain controller to allow you to log on using those cached credentials. The only time that Hyper-V ever absolutely requires a domain controller is when it is utilizing virtual machines on SMB 3 storage. Leaving the Hyper-V host out of the domain precludes it from using SMB 3 storage at all, so that is not a solution to the problem.
Not-Quite-Myth 3: The DMZ Issue
A lot of people leave Internet-facing systems, such as web servers and Exchange Edge servers, out of the domain. That makes sense because there is a greater-than-insignificant chance that the operating systems on such units could be compromised and any local credential stores cracked. Active communications sessions could also be compromised. Because some of these roles have traversal paths across the firewall into protected networks, compromised credentials or sessions would be extremely dangerous for the environment. In illustration:
Edge Traversal
A similar example is the web server/SQL server combination. The web server sits outside the domain but has a tunnel to an internal SQL server. It is definitely a valid security measure to leave these hosts off the domain so that domain credentials are (theoretically) never placed in jeopardy. There is one critical difference between leaving those out of the domain and leaving your Hyper-V host out of the domain: There are additional steps that administrators must take to ensure that no sensitive information is ever left on a web or e-mail host in the DMZ. No one who talks about leaving Hyper-V out of the domain ever brings up the topic of hardening the host against intrusion. All they talk about is crippling the security so that it can be remotely managed.
Unfortunately, some administrators have trouble with the full picture when those DMZ-based systems live on a Hyper-V host. In truth, the diagram is still exactly the same as above, provided that your network segmentation is done correctly. However, those administrators may not mentally separate the Hyper-V host from its guests; to them, a compromise of a guest is also a compromise of the host. This is not how virtualization works.
Myth 4: Workgroup Mode is the Only Way to Protect Hyper-V from Bad Group Policies
It’s no secret that there are a couple of group policies that can cause problems for Hyper-V. That’s hardly a reason to exclude it from the domain. Mitigating facts:
- As I said before, these policies are not secret. Don’t override the Create symbolic links policy. In fact, most everything under User Rights Assignment is likely to break something somewhere, so just stay out of that branch when setting domain policies. If you’re using iSCSI, don’t enable the policy that forces it to be disabled.
- Group policy settings that cause problems for Hyper-V cause problems for other things. If you have a policy that breaks Hyper-V, then it’s only a matter of time until it breaks something else. The proper answer is to fix the policy, not go leaving things out of the domain.
- Active Directory has features that make these problems a non-issue. Look into Organizational Units and, if you’re really stuck, Block Inheritance. Ideally, your Hyper-V hosts will be in their own OU. If you can attach it directly to the root domain OU, that’s best. If you attach it to a sub-OU, that sub-OU can have policies that reverse those coming down from the parent.
Punishing yourself and reducing the security of your Hyper-V host is not the proper way to address a poorly configured domain. All those things do is add to your management burden which reduces the amount of time that you have available to fix your problems.
The Truths of the Domain and Hyper-V
To understand why everything is OK with plugging your Hyper-V host into the domain, you need to dig a bit into Active Directory, workgroup mode, and the basics of virtualization. I’m going to start with virtualization because it is the most important part and it explains why the DMZ issue is mostly a myth.
Virtualization is Segregation
The entire purpose behind placing systems into a DMZ is to keep them as separate as possible from your sensitive systems. Whether people realize it or not, it’s tough to have systems any more separated than they are in the inner space of a hypervisor. I often wish that the term partition hadn’t fallen out of favor in the hypervisor lexicon. This is how you should think of a hypervisor, its management operating system, and its guests:
Hypervisor Partitions
These machines share nothing in common except the Hyper-V host. This is virtually like having a lot of physical servers in the same datacenter. This is what virtualization is. Yes, there’s the VMBus and whatnot, so the management operating system isn’t entirely disconnected from the guests, but are there any known exploits of VMBus? I have heard of one “possible” compromise that was patched out. If there are any surviving issues, what difference do you expect domain membership to make? The separation is at least as good as having all of your servers in the same room using common rack, cooling, power, and switching equipment. The following is a perfectly valid configuration:
Domain and DMZ Together
In the above image, the only system that isn’t domain-joined is the web server. Its only access to the SQL server is via the firewall. Functionally, this configuration is no different than the Edge image that I showed you earlier. The only difference is that we’re talking about virtual systems instead of physical systems… as far as you know. The Edge system in the first image could very well be a guest of a domain-joined Hyper-V host that is sitting on a protected network. Although it’s not shown in these diagrams, you could certainly use dedicated NICs to host a DMZ-only virtual switch if you want. That way, the networking for the domain systems and the DMZ systems do not need to share any common physical network pathways. However, VLANs should work just as well.
The benefit of this build is that only the web server is exposed to the Internet. You don’t need to place your Hyper-V host in the DMZ at all. Should you decide to go that route anyway, make sure that you don’t make any of the security-lowering settings on the Hyper-V host so that it can be managed remotely. RDP is all you get.
The Reality of Workgroup Mode
Workgroup mode is inherently insecure. It is, in many ways, an anachronism from an era when there were no domain controllers. It survived into the early domain days for many reasons: Microsoft and backward-compatibility were once more or less synonymous terms, there was no hardware-sharing virtualization, and server-class hardware was so expensive that the phrase “entry-level server hardware” wasn’t even coined yet. Many companies just couldn’t afford the multi-thousand dollar expenditure of a domain controller, so they skipped it. Those were also the days when Microsoft’s operating system security deserved most of the ridicule that it received. Even so, Microsoft really only went far enough so as to allow members of a workgroup to share some things, like Word files. If they ever intended for one workgroup system to handle the task of managing or being managed by another, I certainly missed the memo. This was peer-to-peer networking in the truest sense of the word peer.
If all those things that you have to do in order to manage a remote workgroup system feel like dirty hacks, that’s because they are dirty hacks. In today’s era, when Microsoft has worked very hard to repair their security practices and processes, it’s simply not practical to expect them to allow anyone to break down the walls that they have spent so much time building. While they are making a few changes starting in 2016 that will coincidentally improve ease of remote workgroup management in some ways, you will still be enabling security-reducing dirty hacks in order to make Hyper-V host manageable in workgroup mode.
The Reality of the Domain
The domain is the way of the hierarchical Microsoft network. When Hyper-V is present with even one guest, the environment is automatically hierarchical. Nothing else comes close enough to even bother making comparisons. I think everyone knows this part.
With that said, each computer is still its own entity. That includes Hyper-V hosts. I know that this is a conceptual struggling point for a great many people; I have lost track of the number of times I’ve lost my temper trying to explain to vendors that if I place a domain account into the local Administrators group, then the account is a local administrator. I believe that lack of understanding around the Windows security model is what leads many administrators do some of the things that they do. When you join a computer to a domain, its local security is altered in a number of ways; Domain Admins become local admins, so on and so forth. However, local accounts remain. Services continue to run under the “LocalSystem” account. The identity of LocalSystem and other built-in accounts is unaltered. The local Security Accounts Manager (SAM) database remains, with some new entries. Group policies are enforced from the domain, but enforcement utilizes existing mechanisms on the local computer. In short, the local computer does not cease to exist as a unique entity just because it is part of a domain. Local credentials still work. Joining a domain allows you to leave the peer-to-peer network where you must compromise security in order to enable remote management and enter a hierarchical environment where you can easily establish superior/subordinate relationships without giving up any protections.
The Benefits of the Domain and Hyper-V
The summary of all of the above works itself out as several benefits that you get from joining the domain as opposed to leaving it out:
- Drastically simplified remote management. Everything just works. The pages and pages of instructions and frustration are just not necessary. The firewall ports are automatically open, the accounts are already there, and you don’t have to do much of anything except follow industry best practices.
- Drastically improved security. The control that your domain can exert over a Hyper-V host is the same as for any other member server. You can have a group policy that locks the host down the moment that it becomes a member. You can add and remove domain accounts and manipulate local accounts without ever directly touching the Hyper-V system again. You can authenticate with expiring Kerberos tickets instead of transmitting user name/password combinations that are valid until someone remembers that they should change passwords occasionally (read: never). When your Hyper-V host accepts a connection from a remote machine, it has the assurance of the domain controller that the remote computer is who it says that it is. Secure DNS registration works.
- The incentive to use Hyper-V Server or Windows Server Core as opposed to GUI Windows Server is stronger. With so many things being controlled centrally, the need to directly access any individual Hyper-V host is nearly eliminated. We’ve all been told, and should understand, that a GUI-less system provides security benefits. With the plethora of historical evidence indicating that remote management of a workgroup system is going to break at some point, how comfortable will you be if your only control option is RDPing to a command line?
- All of the features work. Shared Nothing Live Migration requires domain membership. SMB 3 shares require domain membership. Assigning SSL certificates to a domain member from your Enterprise Certificate Authority so that it can participate in secure Hyper-V Replica takes a fraction of the time of any other method.
It’s time. Add-Computer and get your life back.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
More in this category
About the Author
Eric Siron
1047 thoughts on "Yes, Your Hyper-V Host Should be Domain-Joined"
And what about Hyper-V Replica ?
Imagine a use case when you have only 2 Servers (very small Customer, they exist), with 2 vms on each server.
If you only have 1 virtualized DC, you cannot use planned failover because the DC has to be off in the process.
I don’t see how t achieve redondancy and flexibility without WORKGROUP mode and certificates.
Regards.
Sebastien
I challenge that premise at its root. Active Directory replication’s capabilities dramatically exceed anything Hyper-V Replica can offer at a fraction of the risk and frailty. The proper solution is to have the source and host both running their domain controllers as full-time peers without Hyper-V Replica. Using HVR on a single domain controller starts off with reduced redundancy and flexibility. Forcing the hosts to be in workgroup mode compounds an already suboptimal configuration.
Obviously, but that mean more licences for dedicated DCs, and for SBEs, the additionnal cost is sometimes a no-go.
If the replica virtual machines aren’t licensed, then they are illegal.
I know that, of course. Open SA to cover replica (cold backup). So big costs already exist and each additionnal DC does cost one more licence, that’s my only point to defend workgroup mode in tiny setup. DCs everywhere if the customer owns a goldmine…
If an organization has enough licenses to qualify for Open License and doesn’t mind the added expense of Software Assurance, then I find it difficult to believe that they can’t come up with one more Windows Server license to cover ADDS in the Replica site. Tiny customers almost universally use OEM licensing and they cannot save on licensing costs by using Replica. I disagree with Microsoft’s position on this, but it is the truth.
But, for anyone that can get themselves into OL program in the first place, $800US out-of-pocket cost hardly requires a “goldmine” even if you pay it all up front. The reduced administrative effort alone typically saves that much in the first year. Microsoft allows OL SA to be amortized into multi-year installments, so the annual payment for that license could easily be less than $200US. I have worked with the smallest customers, and there has never been a single one that could afford a replica site that couldn’t easily find another $200 in of their annual budget.
I’m also taking your word that you can’t fail over a domain controller if its hosts are domain joined. I haven’t tried it myself, but I’m unaware of anything in the failover process that would require domain connectivity. This sounds like another variant of the “chicken and egg” myth.
Nice way to change the subject. Pathetic.
Why Pathetic? Costs NEVER come as an argument in this post, right ? Security is an argument, licensing cost IS also a reality for tiny customers.
And what about Hyper-V Replica ?
Imagine a use case when you have only 2 Servers (very small Customer, they exist), with 2 vms on each server.
If you only have 1 virtualized DC, you cannot use planned failover because the DC has to be off in the process.
I don’t see how t achieve redondancy and flexibility without WORKGROUP mode and certificates.
Regards.
Sebastien
Its a funny post 🙂
You write it as its the most logical and natural thing, and then your own points confirm thats its sort of bs. Maybe not entirely, but there are many good and valid reasons to put a Hyper-V host in a workgroup, the most obvious being the security part. Yes its more secure to not have a shared identity base, since it means guaranteed compromisation if one or the other is compromised, unlike if the host is in a workgroup. Then its still as secure as any other server – Do you really not see this?
Any way i found it funny that you’ve convinced your self so much, so i had to comment 🙂
What I hear you saying is, “I disagree but I can’t explain why.” If you don’t join your Hyper-V host to the domain over a “shared identity base”, then you should not ever join any computer to the domain for exactly the same reason.
I disagree with this premise because the benefits of joining the domain are unnecessary for a host server compared to another server or pc. Yes you can use domain policies to manage the host but most likely your host is not going to share any policies with other servers (especially in smaller orgs when you only have one physical host) so the configuration on the domain instead of locally doesn’t get you anything other than the ability to manage the host from the DC. I don’t know what remote management tools you use by mine don’t lock me out of the host after updates. If that is the case then find better tools. They are out there.
I’m not experiencing any remote management tool problems. It never happens to me because my hosts are in my domain. I’m speaking on behalf of all those people who fill up the forums with “it worked yesterday and now it doesn’t” complaints.
You say that you disagree with the premise, but what you have actually done is decide that, just because you don’t personally enjoy the benefits of a domain-joined host, that the experiences of the millions of administrators that are enjoying them are invalid. If you prefer a reduced-security system, good for you, I guess. Don’t pretend that the benefits don’t exist. All servers in even the smallest domain benefit from a centralized security model even if they aren’t using group policy at all. Most servers will share at least a few policies and it’s always easier to open up a single policy console to manage them all.
Its a funny post 🙂
You write it as its the most logical and natural thing, and then your own points confirm thats its sort of bs. Maybe not entirely, but there are many good and valid reasons to put a Hyper-V host in a workgroup, the most obvious being the security part. Yes its more secure to not have a shared identity base, since it means guaranteed compromisation if one or the other is compromised, unlike if the host is in a workgroup. Then its still as secure as any other server – Do you really not see this?
Any way i found it funny that you’ve convinced your self so much, so i had to comment 🙂
our dc is guest.how would i join the host to cd this is a guest of itself?
Same way that you join any other computer.
I’d suggest that perhaps “domain joined” is the right way to go for Hyper-V hosts, but not necessarily the same domain as the guests. There’s a definite value in isolating management functions in a virtualized environment away from the network segment attached to users, particularly when online backup functions take place to network shares using products such as Altaro.
By having the Hyper-V hosts visible only to the management VLAN, along with the management interface of switches, wireless access points and routers there is reduced security risk, and if a “management domain” is employed you have the same benefits as those outlined above.
Agreed on the guests. There are lots of legitimate reasons that someone might put a guest in harm’s way such that keeping them out of the domain is a good plan. Examples are the web and Exchange Edge servers I mentioned. I don’t know of any legitimate reasons to place a Hyper-V host in such a position, nor am I aware of any hardening guides around such a placement as there are for web and Exchange servers. They should be given the protection of domain membership and whatever other isolation tactics that can be reasonably applied.
In case that appears that I’m disagreeing with you on the management domain, I’m not. I think that level of distance is overkill for most, but it does satisfy the concern around the “shared identity base” brought up by the other commenter without degrading security. An administrator can still place a Hyper-V host into an isolated management network without going to that extreme.
I’d suggest that perhaps “domain joined” is the right way to go for Hyper-V hosts, but not necessarily the same domain as the guests. There’s a definite value in isolating management functions in a virtualized environment away from the network segment attached to users, particularly when online backup functions take place to network shares using products such as Altaro.
By having the Hyper-V hosts visible only to the management VLAN, along with the management interface of switches, wireless access points and routers there is reduced security risk, and if a “management domain” is employed you have the same benefits as those outlined above.
While googling for current articles on exactly this subject, I found this one to be both informative and entertaining (ie. the “redemption” argument).
The only thing I’d like to see would be a few links to authoritative Microsoft references. Granted, Eric’s credentials appear to speak for themselves. Also, the points are logical, hence I’m thus far drinking the Kool Aid offered here. But, the admonition presented feels like a dad stifling critical thinking by saying: “do it because I said so”.
Asking to much to request sprinkling in a few external references?
If you feel that any of my points are not well-supported within this article, please indicate which and I will work on them. At the same time, given that Microsoft’s preferred environment involves domains, I have yet to be presented with a single valid reason other than those I mentioned to break away from that design. If someone wishes to argue against Microsoft’s intended design for Microsoft’s products, I feel it is upon that individual to provide solid justification.
While googling for current articles on exactly this subject, I found this one to be both informative and entertaining (ie. the “redemption” argument).
The only thing I’d like to see would be a few links to authoritative Microsoft references. Granted, Eric’s credentials appear to speak for themselves. Also, the points are logical, hence I’m thus far drinking the Kool Aid offered here. But, the admonition presented feels like a dad stifling critical thinking by saying: “do it because I said so”.
Asking to much to request sprinkling in a few external references?
Fair enough. I also enjoyed your articles Demystifying Virtualized Domain Controllers Parts 1 & 2.
My primary reason for not joining the domain is security from the domain admins. If I am managing a hyper-v host and performing backups of servers using Veeam, the domain admins shouldn’t ever need to access the hosts. If an admin corrupts active directory, or some ransomware attacks all the network shares and attached servers, I can restore VMs to the last backup without worrying about my host and backups. In the cluster world, you do need a domain which, although it may be wrong, I would create a separate domain for the clustered hyper-v servers. More complex but in some environments, the domain admins have no clue how to use active directory properly.
Sounds like you need to fire your domain admins, hire domain admins that you can trust, and then join your Hyper-V hosts to the domain.
Are you seriously trying to say that you won’t have to worry about workgroup-joined hosts if ransomware spreads through the domain? Really? No wonder you left that comment anonymously.
The domain admins aren’t under my management. I’m just trying to provide a potential case for an environment where you provide host support, and the host is in either (A) a separate domain or (B) a workgroup mode that you do not change any remote management, and use a VPN or other secure connection to the host. This way you never interact with the domain. You said a couple times in your article, it is definitely a valid security measure to leave (DMZ) hosts off the domain.
Your potential case involves people with broad administrative powers that should not have broad administrative powers. No basic system architecture approach can secure against that. An article saying to leave the Hyper-V hosts out of the domain would be equally “wrong” if that was what it was attempting to address.
You’re twisting my words. Yes, it’s perfectly valid to leave DMZ hosts off the domain. Web hosts. RDS gateways. That sort of thing. It doesn’t make sense to put a Hyper-V host in a DMZ in the first place. At most, I acknowledge that people are doing it.
How about to minimizing lateral movement if comprised. Yes, if that level of compromise is attained by an attacker (domain admin), you’re in a world of hurt. I utilize non-domain hosts for processes like backups (making them essentially air-gapped) , syslog and other critical network security systems.
It doesn’t minimize lateral movement because workgroup mode is never more secure than domain mode. At your high security point, you are transmitting authentication information with long expiration lifetimes (probably eternal) instead of Kerberos tokens with short expiration lifetimes. At your low security point, you have opened, and therefore hijackable, channels between the non-joined and joined systems that do not use a rotating protection scheme. Does no one attend white hat conferences anymore? Did the Wireshark project die while I wasn’t paying attention?
Security is an area about which I’m very serious. Are you saying that if I connect to a Windows 2012 R2 server with HyperV via RDP (soon to be FIPS140 complaint), using a complex password with at least 12 characters, this is not reasonably secure (yes, ‘secure” is relative)? That using Wireshark, I could creak the creds? I will admit though, that i don’t change the passwords very frequently…..
Encryption is data privacy. It is not data security.
RDP does not use schannel.dll. Depending on patch levels and registry settings, it will gleefully downgrade from TLS to lower SSL levels of security.
But, you’re also implying that the ONLY inter-computer connections going on are RDP. It sounds like they are not. Unless you’ve taken a great deal of care to change defaults, they’re all passing authentication packets using NTLM. Sixth graders are cracking NTLM during an Hour of Code. Not sure what they’re doing with the other 50 minutes.
If you just joined them to the domain, you’d be done worrying about this already.
If NLA is turned on RDP will not downgrade to NTLM. NLA is turned on by default when you turn on RDP access on a workgroup system. You can easily turn off NTLM in a workgroup server under control panel, administrative tools local security policies network security with no fear that a GPO or domain admin will get in there and turn it back on.
Ignorance of how to properly secure a workgroup server is not an excuse for not using workgroup mode.
Eric, I appreciate you helping us understand some of the differences between domain security and workgroup security. In a nutshell, you are saying a default install of Server 2012 (patched) is more secure with a domain versus non-domain set up, correct? Since workgroup security can be downgraded to a less secure authentication level? So in my example where we set up a separate domain for the clustered HV hosts, does this solve my concern of trying to separate the host and backup software from the production VM domain/untrained domain admins who only know basic AD management? Their primary job is maintaining the server applications and installing/updating software. I’m just trying to solve both issues without excessive security risks. I mean, some of these guys turn off AV and UAC when their software doesn’t work, never turn it back on. Or even forgetting they joined the CEO to domain admin group. Then the CEO clicks on a ransomware email and asks why our backups were infected too! Some of this is theoretical of course but the concern is real. Thanks!
From a technological standpoint, a domain is always more secure than a workgroup configuration, yes.
Workgroups don’t have security at all. Each machine has a local accounts database of users and that is all that it knows. Each machine is essentially its own domain. Its only other method for identifying anything else is SSL certificates. In order for such a computer to be able to share data to/from others, you must punch holes in its “domain” security. Since a workgroup mode machine cannot verify anyone else’s identity, your hole punching essentially consists of selectively granting access to anonymous users and computers. In a domain, you can outright deny anonymous access and selectively grant access only to people and computers that can prove that they are who they say are.
In your situation as presented, you are in a toxic, self-destructive environment. If you cannot positively impact your corporate structure, start looking for other employment. That environment is headed for disaster.
Two things:
To play the ball as it lies, you could set up a management domain. It’s not a simple task to correctly build one; many people wind up taking shortcuts that make them no more secure than a single domain. However, if done correctly, you could migrate all important resources across the domain barrier. From there, you can easily set it so that any given domain admin in your shop of horrors is just a regular user in the management domain. What usually happens, though, is that the overemployed domain admins whine until they are given admin access in the management domain as well, and you wind up with a really complicated system that doesn’t solve the only problem it was designed to address.
The most correct thing to do is strip them of domain admin powers. You say that “their primary job is maintaining the server applications and installing/updating software”. That is not a domain admin function. Local admin privileges are adequate. The first step to a secured domain is not allowing anyone to have greater privileges than they need to do their job. You can create a “Server Admins” group and use Group Policy to place it in the local Administrators group of your server OU(s). If your layout is more complicated, use more granular groups and OUs. The point is, it’s the admins that you don’t trust, lock them away.
Hello Eric,
Thank you for your article.
I took your advice, joining the host to the only guest which is the Windows Server Essentials 2012R2 Domain Controller. The host itself down one day. Looking through the logs, I eventually found that the following message:
Windows is going to be shutdown because your environment is out of compliance.
and
The Non-domain Member Check policy detected a condition in your environment that is out of compliance with the licensing policy. This server can only be in a workgroup or be a domain controller.
in the
Microsoft-Windows-Server Infrastructure Licensing/Operational log.
Changing the host back into a workgroup has stopped the error messages.
It’s a big problem to suddenly have the server shutdown for no apparent reason. I think you should warn about this problem
That check only looks to see if there is another DC or if the WSE system is a member server. Joining a Hyper-V host to a WSE domain will not trigger either condition. Something else is going on. I could even believe a bug.
Hey Eric,
I was wondering about the licensing compliance as well with using HyperV host in domain. From what my licensing rep has told me, if we put the HyperV host on our domain, then we will be required to license it.
As it stands, we are using open licensing on a single host that is in a workgroup. This host then runs hyperv and hosts our 2 guest VMs, a DC and exchange server. We only require 1 VL for these 2 servers as I’ve been told.
I’ve also been told that in order for this compliance to be met, the host would need to be in a workgroup with no roles attached. If we were to put the host into a domain of any kind, we would require a second VL for our physical host.
Is this actually the case? Thanks
I wasn’t in on the conversation, so I’m not sure if your licensing rep needs to retake some licensing courses or if something was misunderstood. But, no, that is not the case.
I don’t believe that the word “domain” even appears in Microsoft’s licensing documents at all. I assure you that domain membership has no bearing on Microsoft operating system licensing.
This part: “no roles attached” is accurate. The Hyper-V host can only run Hyper-V and and roles/features/applications that exclusively supports the virtual machines. A bit more precisely, if a role/feature/application can directly provide a service to anything (person, device, service, etc.) that is not one of the local virtual machines, then its operating system consumes a licensed instance. So, if you were to install Active Directory Domain Services, then you would be in license violation. But, that’s not what you’re proposing to do. Being a domain member is a status change, not a role/feature/application. It does not qualify as an externally-available service, so it does not consume a license.
That is what my thoughts were as well. I was going through Ingram Micro and their reps haven’t been impressive at all, hence my skepticism of their information.
Thanks for the clarification!
Eric, I stumble upon your post becuase we have hosts that are in WG and not Domain. I want to use replication and kerberos versus cert for replication. We want to move our server hosts to the domain. Can this be done if the host is already running production VMs without any issue? I am not a super tech and only oversee the work of techs but want to have a plan that works well for our business and rationale while discussing with our team.
Hi Matt,
Yes, you can do this.
If you have good backups, then you can completely screw up the entire process at every step and still be OK. If it came down to it, you could completely rebuild the hosts, join them to the domain, and restore the VMs. Make backup priority number 1.
Thank you!Sounds like a plan. Appreciate it. You have great input.
Hi Eric, I only looked up this procedure as we are inheriting a client that had chosen to go down this path (why, after all the certificate and replication issues?) I noticed in your procedure that you mention in step 2:
“1. Shut the VMs down. Make sure that they are not set to auto-start.”
Surely you exclude the DC itself if it’s running as a guest? Join the domain and then shut it down?
Just confirming, as I guess it’s a chicken and egg situation, and maybe you meant to mention that, as there would be no DC to join.
Thanks for the procedure though.
Chris.
That particular commenter talked about hosts plural, which implied to me that he could shut down all the guests on a single node and still have a DC available somewhere. If the only DC was local, then yes, it would need to stay online. It might not even be necessary to down the VMs at all. I recommended that in the off-chance that Windows decided not to properly set permissions on a VM file because it was in use, as that might be unpleasant to diagnose and correct. It might be a completely unnecessary precaution. Having never changed the domain membership status of a Hyper-V host with guests, I wanted to make the safest guess.
This was a great read, appreciate the work that went into it. If you could add a bit more thought to the TrustedHosts comment I would appreciate it. I was installing my first 2016 server and had a hard time remotely managing it with a Windows 10 workstation. I ending up having to add the server to my trustedhosts file on the workstation, in addition to the firewall settings and enabling powershell remote. Am I understanding things correctly that we should never be touching the trustedhosts file – this is what you mean by punching holes in the security (of the workstation). I am not sure how to make it work otherwise.
Domain security is the equivalent of: “You must have a valid government-issued identification card and have current registration in our system to get past this point.”
TrustedHosts is the equivalent of: “Whatever that name you tell us is yours must appear on this list and we’ll blindly believe whatever you say.”
Hello Eric,
I have small network with 2012R2 DC and several member servers.
I also have a 2012R2 non-domain joined Hyper-V Host with a 2008R2 guest which is domain joined SQL server.
Would there be any issue joining the 2012R2 Hyper-V host to the domain at this point?
Well, I won’t put myself on the hook for anything that might happen in a domain that I am not personally familiar with.
For a typical domain and a typical Hyper-V host, this would not be problematic. Have backups and a regression plan just in case.
I have a HyperV Server 2012 that runs a handful of VMs, Windows and Linux, on a small home network including a Windows Server 2012 R2 Essentials domain controller. Since day one I’ve always included the host in the domain, and I entirely agree with your stance on this matter.
I manage the VMs mostly using Hyper-V Manager, and hardly ever have any problems with this.
However, yesterday, I managed to do something rather stupid. I was investigating a slowdown in my internet connection, and while connected to the domain controller VM via RDP, I foolishly disabled the DC’s network adapter. Disaster! My RDP session not surprisingly dropped out, and Hyper-V Manager wouldn’t let me in, so I couldn’t even open a Virtual Machine Connection session (in spite of the fact that my current user is a member of a group that is included in the Hyper-V Adminstrators group on the host).
After a lot of head scratching, I managed to find a spare monitor and keyboard to attach to the normally-headless host server (I never thought I’d have to use a VGA connector again!). Fortunately it allowed me to login using cached credentials, and I was then able to shut down the DC, remove the existing virtual network adapter and add a new one using Powershell. Then I restarted the VM, but I wasn’t home and dry yet.
One of WSE’s licensing restrictions is that you have to use it for DHCP – it won’t allow a second DHCP server on the network (which strikes me as a really petty restriction on Microsoft’s part). And of course the newly added virtual network adapter had a silly default configuration because it couldn’t contact a DHCP server: and I couldn’t find a way to get it to refresh once the DHCP was running in the DC, because I still couldn’t actually connect to the DC at all.
At this point I was beginning to think that if the Hyper-V host weren’t domain-connected, I’d probably be able to connect Hyper-V Manager to it and then get a Virtual Machine Connection session on the DC – but I wasn’t about to go down that road!
In the end, I dusted off an old unemployed but still working Windows 2000 Server (yep, really) VM running on a Windows 10 desktop Hyper-V, not domain joined , and configured its DHCP server, and lo and behold the DC immediately picked up a valid network configuration and I was then able to RDP to it again and restore it’s proper static IP settings.
It took me several hours to work through this seemingly straightforward scenario: that’s one of the problems with WSE, Hyper-V Server, etc: they just work so well that you never really have to learn any of this stuff (obviously different for a professional system administrator in a corporate setting with multiple hosts, failover clusters etc).
So I was well pleased when sanity was restored, but I have to wonder whether I missed something somewhere that would have made it all a lot easier…
As someone who has lost multiple days of his life over minute problems, I feel your pain. Ouch! I am glad you got it fixed.
I would have started with “.Administrator” in an RDP session to the host. In fact, that’s exactly what I do when I derp up my home domain, which I may or may not do on an average of three or four times each year. VMConnect should work from there unless it’s shielded.
If couldn’t connect with VMConnect even as the local admin, then I would have added a second vNIC to the DC and turned on the DHCP server in my router. Really super worst-case, I would have enabled Hyper-V on one of my too-many desktops and laptops and built a Linux or Windows VM for DHCP.
Then I would connect in, re-enable the main adapter, then disable the emergency adapter. Bob’s your uncle.
Thanks for your reply.
I had forgotten about the /admin switch on mstsc. That would have given me a command prompt session on the host, but nothing more since the host is Hyoer-V Server, not full Windows. But it would have saved me having to mess around with keyboards and mice (though the good thing about that was that it encouraged me to vacuum all the accumulated dust off the back of the server, which sits rather inaccessibly on the floor in an alcove under a window, guarded by a lion, and gets very little – read ‘zero’ – attention! Actually I lied about the lion..).
I may possibly have been able to make vmconnect work from a desktop, but I doubt it, since I can’t actually make it work even when the DC is running properly. Ah! I’ve just discovered why that is: the version of vmconnect in current Windows 10 can’t be used to manage VMs running on Hyper-V Server 2012 R2. Great! And I don’t have any desktops earlier than Windows 10…
The rest of what you say is pretty much exactly what I did, except that I used my old Windows 2000 VM rather than my router or a Linux VM (of which I have a couple) simply because I already know how to config DHCP on that.
Anyway, I think that the take-away from all this is that I should upgrade my host to Hyper-V Server 2016 some time soon – I’ve been putting it off, because I don’t like messing with something that works so well as it is. But not quite well enough as it turns out!
I have a question. I have a Domain Joined Hyper-V host which hosts SBS2011. The problem I have is that the host comes up, makes a network connection with no DC. The ethernet interface reports “network 3”. The hosted DC comes up and starts serving up mycompany.local. The hosted system doesn’t switch over from “network 3” to “mycompany.local” unless I disable and enable the network connection. This leaves the host kind of stranded.
Is this common or did I set something up wrong?
I don’t know how common it is, but it’s not unheard of. I have not been able to replicate the problem — my own systems always figure it out. The problem lies with the Network Location Awareness service — it should eventually figure out that the domain is available and fix everything. I don’t think I can get you any closer to the solution than that.
Hi Eric,
Great writeup. Currently sitting over the concept for a new installation and planning to keep a separate management network for Hyper-V hosts (clustered) and out-of-band management features of network components (Switches, SANs, USVs etc.).
Also planning to put the Hyper-V hosts into the domain but this (and backup) is where I struggle – how would you connect the Hyper-V hosts (and with it the management network) to the (virtual) DCs in the guest network securely. Seems like its beating the purpose of the separate VLAN / network.
Unfortuantely I couldn’t really find an answer to that so far but maybe you have some best practices or thoughts here.
Thanks a lot,
Jens
In small networks, I rarely distinguish VLANs, therefore the management adapters and the DCs reside in the same subnet. In larger networks, the DCs are in one subnet VLAN (usually firewalled) and the Hyper-V hosts reside in another, connected by a router.
I like Erics work and agree with most everything and learn from him. But saying workgroups fail over time is not quite what I have experience. I don’t use RDP though. Have a 18 PC WORKGROUP only with Hyper V 2012 and many data bases and PCs. Never once in 8 years have I not been able to connect. I bypass remote desktop and VPN (they only used for last resort) and use a low overhead client on the PCs. Not logmein but the same concept. ZERO ISSUES.
I’ve had ZERO downtime (knock on wood) Domain just a little easier to admin but not much in small workgroup. So I say that picture he painted can go in the Myth column. I’ve not even had issue with vpn and remote desktop, i just do not care for remote desktop.
That aside I think the article is very good.
One anecdote from one lucky person does not make what happens to many other people into a myth. Look, if pointless busy work micromanaging a bunch of systems makes you happy, you do you. But, please report back when an LLMNR responder attack sniffs a Hyper-V host password and takes everything from you in one shot. I’m curious if you’ll still be glad for all that extra work you did.
I guess I would rather be lucky than good :).
Also “Local accounts do not auto-lock. Brute force attacks are viable in a workgroup”
I have all my WG computers set to autolock. after x amount of attempts they can try no more. So even a simple password becomes very hard to brute force crack when you only get 3 attempt to brute force guess.
“if pointless busy work ” You are starting to sound like the guys post which you chastised. Pointless? You don’t have enough information on the particulars to say that. Sounds a bit condescending.
Wow you now are wishing bad things on people that support you. Hoping I get hacked? shame on you, cancel cancel that thought.
You would first need to explain how the LLMNR got on the system in the first place. What extra work are you talking about? If you are going to fear monger please explain. It like you are not happy that I’ve had ZERO down time in 8 years (might be 12) and you are now wishing bad things on me.
Well, you see, the LLMNR responder ships with Windows. That’s how it got there. We get to disable it as an attack vector in our domains, but you workgroup owners can’t do that without more or less killing local name resolution. Seems to me that a workgroup expert such as yourself, doing all the necessary work to keep his environment secure as you claim, would know that.
I had plenty of years in the field, maintaining all sorts of nasty things. I have a very good idea of how much effort is needed to properly maintain a workgroup. If I’m being honest, I probably only know part of what I should have been doing. Doesn’t sound like you’re putting in that level of effort. Doesn’t even sound like you’re reading the CVEs. Doesn’t really even sound like you’re all that familiar with the technology.
I didn’t wish anything bad on you. You read that interpretation in all by yourself. I do wish you would set aside your pride and do the right thing. I don’t have any ill will because this isn’t even about you. Your workgroup’s “security” doesn’t just impact you, it impacts everyone that uses it and all your customers. See, if I ever have to sign a breach disclosure, it will say something like, “I did the best that I could with the knowledge and tools available to me and the bad guys broke in anyway.” You couldn’t truthfully say that. If that’s what you want for yourself, you do you. But I doubt those people deserve that.
I reject your challenge because I have nothing to prove to you. Calling me out by side-stepping my article’s merits and then demanding a personalized rebuttal to a claim that you haven’t even begun to support? Nope. The entire Windows infosec community says that you’re wrong. All of it. You think that workgroup mode is better? Go pick a paper written about it and debunk that. Keep on debunking until you run out of trained, credentialed, experienced Windows security experts. THEN you come challenge me. Just so you’re prepared, no one will accept “My network has been OK” as rebutting evidence. That’s not how it works.
If every admin on Earth who thinks that workgroup mode is inferior to domain mode decides not to follow me, I’m good with that. I’m not here for the popularity.
Eric I do appreciate all your posts and I was only disagreeing on
1. All Workgroups eventually break down. (mine never did yes anecdotal)
2. LLMNR responder attack sniffs a Hyper-V host password . I meant how did the sniff attack take place in the first place. Not how the respoder itsself. Sorry if that came out wrong, maybe I was tired when typing.
I get what you are saying that in this sense a workgroup is less secure because (a big if) a sniff attack takes place a workgroup is less secure.
Agree that one should do what he can to lock down as well as you can
And yes joining the core HV host to a domain is something i will do. Thanks!
But… On another side topic on security. I am interested in your thoughts on healthcare vendors using the hippa loophole (deindentifying data and selling it) without the Drs or patients knowing. It seems to be a common practice in contracts that is worded in such a way that at first it seems innocent and never mentions what they really do with the data. (Sell it)
To me that is a lowering of security as data can be reindentified (not easily) but it can be.
forgive me on the side topic. 🙂
I lost track of this thread, that’s why I never replied.
Sniff attacks are not your concern. Almost no one bothers trying to sniff Windows passwords anymore because there are easier ways to break things.
The LLMNR responder attacks pretend to be computers that the victim trusts. Without a domain, you have an uphill battle trying to prove that a remote machine is who it says it is. Same for users. A workgroup-mode machine is essentially a domain unto itself and it has no reliable way to verify anyone else’s identity. LLMNR attacks are not trivial, but they are a lot easier than password sniffing. When such an attack works, sniffing the password is unnecessary. The victim will give it up willingly. These attacks are initiated by someone that has managed to jump onto your wired or wireless network, or any internal attacker that’s already connected.
Domains provide a third-party identity arbiter and passwords don’t ever cross the network for AD-secured resources.
You can have vendors sign an additional data access agreement. Basically, “vendor won’t sell patient or doctor data and this agreement supersedes all others and client will sue vendor out of existence if vendor violates this agreement”. Some will refuse your business if you try that, of course. My thoughts are that it’s horribly dirty practice, especially since healthcare vendors aren’t going broke.
I have been in the IT business most of my life and I learned a long time ago that there is no one-size-fits all solution. The reality is that workgroup mode is perfectly fine for a hyperv host IF all that host does is run hyperv guests.
I have setup many hyperv servers and have a few opinions on this, they are worth what they cost you (just as Eric’s advice is worth what it cost you):
1) If you are afraid of running powershell commands to manage windows servers you have no business at all running Server Core. You are an amateur. (frankly your also an amateur if you don’t know a lick of Unix commands but that’s another story) The prospect of RDPing into a Core hyperv server and seeing a command prompt should not be a problem.
2) Core is almost worthless unless you have a lot of servers that are the same hardware. Firmware updates, device driver patches, and so on often virtually require the GUI. To give you a simple example, Dell’s Perc H730p raid card has a driver in the Server 2016 install ISO and an updated driver you can download and install off the Dell website. The downloaded driver is NOT signed – at least not in any way that Server 2016 install thinks it is. You have to install server 2016 then download and run the dell GUI installer to get the current driver. The industry is rife with this kind of hacked up install programs they will always produce a GUI installer first then -maybe- get around to making sure it works in Core.
3) The GUI is swapped out and inactive for the most part when you are not logged into it so if your environment is just a few servers, like under 10, there’s little point in NOT installing it, it’s resource consumption is minor on a modern server.
4) In my opinion it is bad practice to mix the roles of Hyperv host and stuff like domain controller services, dhcp services, dns, sql, etc. I have done it in special situations (like when the customer is really small and has ONE physical server) but management is weird to say the least. If you are going to run a hyperv host it SHOULD be like an ESXI server and JUST RUN hyperv guests (and in fact if you don’t know what ESXi is you also are a reeking amateur IMHO) Note that the “free 2 vm license” people talk about in server standard does NOT apply if you are running “roles” on the hyperv host. If you are doing filesharing or running roles or any of that – you only get to run ONE windows server vm.
5) Eric drastically overemphasizes the importance of remote management tools (RSAT, etc.) There is little difference in effort between using RDP to manage servers and using RSAT when there are not many servers. In fact there’s 3rd party software programs where you can gather all your servers into one window and use RDP on all of them if your so obsessed with having one pretty picture listing all servers. I will also point out that it’s a bit tricky to run remote management tools and be absolutely sure you are doing what you think you are doing on the server you think you are doing it on, you have to really pay attention at times. RDP gives you a separation you don’t have otherwise.
RSAT and friends only start to become useful IF you have a large BigCompany network with dozens to hundreds of servers. I’d say anything above many 20 of them. Or if you are doing anything special like requiring bitlocker on laptop disks, etc.
6) There’s a big difference between a hyperv server built to run hyperv guests that are WINDOWS SERVERS vs hyperv guests that are workstations or clients. Under windows server standard you can only run 2 VMs that are “free license” SERVER vms. But you can put as many other hyperv vms on a windows server standard hyperv host as you want as long as they are running something other than windows server. Consider that windows server is pretty resource intensive and you may want to use the host server as an application server or file server or other role server and run some non-intensive vms for tests, or other non-windows applications. Unlike windows server you can run a Linux mailserver in a 4GB ram VM with 1 CPU. In that scenario then of course you would put your hyperv server in the domain.
Yes, if you have a large BigCo environment then you may get benefits by using RSAT and putting your hyperv hosts in the domain. You also definitely should put hyperv hosts in the domain if you are running any services (file serving, etc.) on them in addition to hyperv. But IMHO you shouldn’t be doing this anyway. All it takes is for an iis process to runaway or something of that nature on a hyperv host and all your guest servers are dead.
If all you are doing is running hyperv guests on a hyperv host then there basically is nothing TO manage on the host – the only time you should ever BE on the host is to shut down and start up hyperv images, delete and create hyperv images, and run patches on the host. You don’t need anything other than RDP to manage it and frankly I am somewhat surprised at the vitrol from Eric regarding RDP. If you run a CA on your network somewhere and copy a private CA certificate to your hyperv host, then you can setup RDP with a certificate and Eric can waste his time “sniffing rdp passwords” all day long – although I would love to see him do this on a modern switched network since the switch port he is on isn’t even going to SEE the frames from my workstation to the server – good luck decrypting them. You don’t need your hyperv hosts registering into the DNS since they should all have static IPs and permanent host entries in the DNS, and you definitely don’t need to RSAT into your hosts unless you have user-accessible services on them which you shouldn’t be doing. So workgroup mode for the hyperv server is really not a problem and the gloom-and-doom contrived scenarios are not a reason to make that decision on.
Lastly I will point out that the truly secure who have a large number of hyperv host servers would RUN A SEPARATE ACTIVE DIRECTORY DOMAIN just for the hyperv hosts. That is what Microsoft does with its Azure services you don’t think that they put their hyperv hosts in the same domain as customer guest servers, do you????
You know what sort of thing drunk drivers say right before they kill a bunch of people? “I’ve been doing this for a long time and nothing bad ever happened to me. And look, I even take back roads and wear my seat belt.” That’s essentially what I hear you saying. And, you’re being self-righteous and condescending about it. Want to prove yourself right? Anecdotes, bragging about your length of time in the industry, and trying to use the word “amateur” as a shaming insult do not cut it. Get the numbers. Get the data. Get the take of trained infosec people. Put in the effort to do some authentic research. Show your work.
“Sniffing rdp passwords” is not a phrase that I ever used, nor did I even imply the use of any exploits in that category. If you’re going to quote me, quote something that I actually said. If you ever again deliberately misquote someone on this site for the purposes of changing their message into something that you can easily attack, I will block any further comments from you. Do better.
I’m about to type a whole lot of stuff to address your points, and I know that you’re going to come back with more one-offs to try to convince the world that you’ve already thought of it, so I’m going to put four very simple, unrefutable statements right here in the beginning for the TL;DR crowd:
“rdp password sniffing”: We don’t break workgroup security with basic packet sniffers. The only trick is the initial penetration. Once in, it’s just a matter of time. In your case, I would just wait for 3389 to go hot and then I’d pull your clear-text credentials out of LSASS memory. Worst-case (as the attacker), I set recovery for full memory dump and then trigger a blue screen. Poof, all I need, right there on disk where I can get to it with read-only access. From a security standpoint, THAT is why we use PowerShell and RSAT instead of RDP or console-access tools like VNC, NOT because we fear packet sniffers. But, these tools in a workgroup only protect one side since they still can’t use Kerberos tickets. And of course, it’s the side that’s easiest to break into.
Before we walk away from RDP, sure, putting a certificate on the server helps a bit. It ensures that, when establishing an RDP connection, that you as the client are connecting to the proper server. But, the server is more trustworthy than the client. Are you also putting in all the effort to establish and require client certificates? If you did, how does the server know that someone didn’t compromise your workstation and steal your private key? Did you set up a proper revocation chain? When was the last time you published your CRL? What does RDP do if it can’t acquire a CRL?
But, most attackers probably won’t wait for an RDP session. First, they penetrate some system (usually by exploiting the fact that nearly 100% of users on workgroup machines are local admins and will gleefully install anything). Then, they exploit the core reason that workgroups are not secure (from above): you have no way to verify the identity of anything or anyone for the majority of communication types. Then, it’s just a matter of exploiting credential-prompt fatigue to get you to log in. That’s how these attacks work, not by “sniffing RDP passwords”.
Turning off NTLM addresses exactly ONE breach factor. It does not do anything at all to address the overall responder attack category. Locking a system out of DNS is an anti-pattern, precisely because the LLMNR attacks work SPECIFICALLY because DNS lookup fails. Yeah, you can connect by IP, but that only protects you against already-unlikely sniff attacks. All of your machines are broadcasting their names onto the network all the time. Workgroup users are accustomed to plugging their credentials into pop-up boxes and then saving them for the system to indiscriminately hand out to anyone that more or less fits the description of a known entity. Again, if you cannot verify the identity of the user or computer that you are trading information with, YOU ARE NOT SECURE. Workgroups CANNOT be properly secured BY DEFINITION. This is basic, data security 101 stuff. You can lock off today’s LLMNR attacks, and wall out yesterday’s NTLM attacks, but you are just sticking your fingers into the dam holes as they appear without ever addressing the core structural problem.
Your individual points:
1. and 4. Using “amateur” to try to shame people into agreeing with you is childish. Do better. Do your research, show your work, and prove why you’re right instead of assuming that you’re right and devolving into broadside attacks against people that don’t immediately fall in line. Shaming never works anyway.
2. You can install the PERC driver, and every other Dell driver that I’ve tried, in Server Core pretty easily. You made an assumption without an attempt.
3. Take some of the heat and shame out of that, and you’re fairly well on-point. I could critique some things, but I’ll just leave it with the request that you do a bit more research.
4. You have arrived at a correct opinion, but by about a half dozen incorrect reasons. Do better.
5. When you RDP or VNC to a system, your passwords are sitting in clear text in LSASS memory. When you use PowerShell or RSAT, the greatest risk is client-side. In a domain, you can avoid clear-text credentials. It is also factually incorrect to say that RDPing into multiple systems and opening their management tools locally is in any way easier than managing them all from a single pane of glass. The time consumption factor alone negates that entire line of thinking. Multiple products use “single pane of glass” as a selling point because it is 100% accurate. It’s also ridiculous to claim that you’re less likely to forget which server you RDPed into than to look over at the server list in Hyper-V Manager to see which one is highlighted. I mean, that’s just embarrassingly wrong.
Your point #6 is completely wrong in almost every way that a thing can be wrong. Your understanding of licensing is off. Whether or not you join your Hyper-V host to the domain has exactly 0 relevance to the amount of resources that your VMs draw or the OSes that they operate. I can’t even follow the logic trail you followed to get to that one.
I don’t even know what you’re talking about with the separate AD domains thing. Microsoft lets customers keep their own domains on Azure because why the heck would you ever shoehorn any customer into your domain? It steals their autonomy, exposes them to you and to each other, and puts more work on you. But, are you trying to say that you use workgroups because other people use two or more domains? What are you even trying to say here? Very, very, very few organizations use dedicated management domains. I have never even heard of any organizations setting up a domain JUST for their Hyper-V hosts. Separate domains are not inherently more secure than single domains. If configured incorrectly, they are less secure, for essentially the same reason that workgroup is not secure. The organizations that break out into multiple domains do so because it’s easier to divide and conquer along logical boundaries than it is to try to monolithically manage millions of objects. Smaller orgs that try the multiple domain approach tend to collapse into a single domain or tear down the walls between them.
What really kills me here is that you imply that you have a DNS server. ADDS and DNS are practically made for each other. You literally went to all that work, got to where you’re nearly begging for a domain, could have saved yourself probably days worth of work, and then didn’t do it? Security aside, WHY would you do that to yourself!? The only times I’ve ever seen that were from people that just didn’t know any better and tech providers that screwed their customers by billing for security-related hours that never had to happen in the first place.
No matter what, this is a bizarre hill that you have chosen to die on. But hey, you gotta do whatever makes you happy.
Your style is unique compared to other folks I have read stuff from. I appreciate you for posting when you’ve got the opportunity, Guess I will just bookmark this page.
Im thankful for the post.Really thank you! Awesome.
For the longest time, I’ve always loved to join Hyper-V host to domain for simple and centralized administration.
I was attacked by Ransomware twice in the past 4 years. Both time, ransomware spread out to all domain joined computers including Hyper-V host which stopped all the VMs on the host and made the restore really painful.
LockBit 2.0 is the one I’ve encountered recently, and it used Remote Code Execution (from Exchange server) to run Group Policy and disable all domain joined servers/PC and then process the encryption right after. All of my none-domain joined servers survived the attack but domain joined hosts all need to be rebuilt.
I am reconsidering my stand with domain join hosts after this and I am reviewing the possible replication feature in Altaro to perform the replication instead.
Just sharing my experience.