Managing Hyper-V
-
@matteo-nunziati said in Managing Hyper-V:
ok comany is closing. after dinner will put notes here!
it is just winrm, trusthosts and same user/password/workgroup setup. then you can fly!
OK - I was just referencing the page you linked to.
-
@matteo-nunziati said in Managing Hyper-V:
ok comany is closing. after dinner will put notes here!
For the weekend?
-
@romo is getting our headless Hyper-V cluster up in the lab today. Going to be testing stuff on it very soon.
-
@scottalanmiller said in Managing Hyper-V:
@romo is getting our headless Hyper-V cluster up in the lab today. Going to be testing stuff on it very soon.
No iDRAC or other ?
-
@Dashrender said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@romo is getting our headless Hyper-V cluster up in the lab today. Going to be testing stuff on it very soon.
No iDRAC or other ?
That is not what headless means.
-
@Mike-Davis said in Managing Hyper-V:
In part of my strategy to prevent CryptoLocker or a bad actor from taking out my backups if a computer/server gets infected, I'm not domain joining my hosts now. I realized that even with a share on the network that used a service account, if a hacker elevates privileges and gets domain admin, they can reset the password on the backup service account and then wipe out my backups. If the backup target is not domain joined, they can't do that. Same idea with the host.
I'm curious as to what others are thinking. We love disk to disk backups, but it's really hard to air gap them with out physical interaction.
This is just stupid.
There is not any type of realistic risk for this kind of scenario that does not involve a ton of prior failures.
Within a single organization, there is zero reason to not have the hypervisors domain joined.
There will be no possible way to lose anything because there should be no possible way that a privileged account like domain admin can be compromised without ignoring other best practices.
-
@DustinB3403 said in Managing Hyper-V:
I'm in the camp of not joining your hypervisors to the domain.
If you get locked (because of domain controls) out of your hypervisors then you're SOL, along with the domain functions.
This is also just stupid.
Being domain joined in no way affects the root account ( or original administrator account on hyper-v ) from working in any way.
I just cannot grasp how people keep repeating this kind of garbage.
-
@DustinB3403 said in Managing Hyper-V:
Sounding more and more like hyperv is a disaster without these kinds of tools
Only if self inflicted. There is zero wrong with the Hyper-V Manager mmc snap in for normal hyper-v management in a small organization.
Yes, 5 nine was nice. But still not hard to manange.
-
@BRRABill said in Managing Hyper-V:
@Dashrender said in Managing Hyper-V:
@Tim_G said in Managing Hyper-V:
I don't understand what the issue is here. Install and configure a Hyper-V Host... then connect to it via Hyper-V Manager, FCM, or PowerShell. None of the Windows GUI tools do anything that you cannot do with PowerShell. In fact it's the other way around. You can do way more to Hyper-V with PowerShell than from any tool. Just learn the commands and move on. They are so easy.
That allows you to manage the hypervisor.. what about getting console access to the VMs?
Why wouldn't you use RDP there? Or PowerShell?
Are you not paying any attention to what you are reading?? Remote access is not console access.
-
@matteo-nunziati said in Managing Hyper-V:
ok comany is closing. after dinner will put notes here!
it is just winrm, trusthosts and same user/password/workgroup setup. then you can fly!
This is the answer for non domain joined systems.
But most people have no need for this in the SMB as a MS AD deployment is almost always already in place.
@Dashrender opened this thread with a poor hypothetical scenario.
It is something that can apply to an ITSP or consultant, but it is completely not something that will apply to the vast majority of deployments.
-
Although it does apply to us, we are putting Hyper-V in a situation today where there is no AD currently, nor planned. Just by coincidence.
-
@scottalanmiller said in Managing Hyper-V:
Although it does apply to us, we are putting Hyper-V in a situation today where there is no AD currently, nor planned. Just by coincidence.
It will certainly begin to apply more and more.
This is very true and why the loss of 5Nine as a free tool is so sad.
Do not forget that 5Nine is still available, just no longer free.
-
@JaredBusch said in Managing Hyper-V:
@Mike-Davis said in Managing Hyper-V:
In part of my strategy to prevent CryptoLocker or a bad actor from taking out my backups if a computer/server gets infected, I'm not domain joining my hosts now. I realized that even with a share on the network that used a service account, if a hacker elevates privileges and gets domain admin, they can reset the password on the backup service account and then wipe out my backups. If the backup target is not domain joined, they can't do that. Same idea with the host.
I'm curious as to what others are thinking. We love disk to disk backups, but it's really hard to air gap them with out physical interaction.
This is just stupid.
There is not any type of realistic risk for this kind of scenario that does not involve a ton of prior failures.
Within a single organization, there is zero reason to not have the hypervisors domain joined.
There will be no possible way to lose anything because there should be no possible way that a privileged account like domain admin can be compromised without ignoring other best practices.
There are zero day exploits out there. Networks get hacked. I'm trying to limit risk.
-
@JaredBusch said in Managing Hyper-V:
@Dashrender opened this thread with a poor hypothetical scenario.
It is something that can apply to an ITSP or consultant, but it is completely not something that will apply to the vast majority of deployments.
Not hypothetical at all - It's Wired's setup.
In fact, no one ever actually answered my question, Should all Hyper-V hosts be in a single domain to simplify Hyper-V host management?
The only thing that resembles an answer is no - because we don't join the domain at all
-
@Mike-Davis said in Managing Hyper-V:
@JaredBusch said in Managing Hyper-V:
@Mike-Davis said in Managing Hyper-V:
In part of my strategy to prevent CryptoLocker or a bad actor from taking out my backups if a computer/server gets infected, I'm not domain joining my hosts now. I realized that even with a share on the network that used a service account, if a hacker elevates privileges and gets domain admin, they can reset the password on the backup service account and then wipe out my backups. If the backup target is not domain joined, they can't do that. Same idea with the host.
I'm curious as to what others are thinking. We love disk to disk backups, but it's really hard to air gap them with out physical interaction.
This is just stupid.
There is not any type of realistic risk for this kind of scenario that does not involve a ton of prior failures.
Within a single organization, there is zero reason to not have the hypervisors domain joined.
There will be no possible way to lose anything because there should be no possible way that a privileged account like domain admin can be compromised without ignoring other best practices.
There are zero day exploits out there. Networks get hacked. I'm trying to limit risk.
No. You are much mistaken.
In a well designed network a zero day has not access to anything except the user profile. The user has no access to hyper-v management. The user should have to to that from a VM on their workstation.
-
@Mike-Davis said in Managing Hyper-V:
@JaredBusch said in Managing Hyper-V:
@Mike-Davis said in Managing Hyper-V:
In part of my strategy to prevent CryptoLocker or a bad actor from taking out my backups if a computer/server gets infected, I'm not domain joining my hosts now. I realized that even with a share on the network that used a service account, if a hacker elevates privileges and gets domain admin, they can reset the password on the backup service account and then wipe out my backups. If the backup target is not domain joined, they can't do that. Same idea with the host.
I'm curious as to what others are thinking. We love disk to disk backups, but it's really hard to air gap them with out physical interaction.
This is just stupid.
There is not any type of realistic risk for this kind of scenario that does not involve a ton of prior failures.
Within a single organization, there is zero reason to not have the hypervisors domain joined.
There will be no possible way to lose anything because there should be no possible way that a privileged account like domain admin can be compromised without ignoring other best practices.
There are zero day exploits out there. Networks get hacked. I'm trying to limit risk.
I agree with JB, if you are compromised this badly, why care more about your hypervisor than the VMs? I'm assuming the VMs are all part of the domain. Sure with control over the hypervisor, they could kill a whole box faster - but we really don't see that being the case, they aren't killing boxes, they are stealing data, or encrypting it.
-
@Dashrender said in Managing Hyper-V:
@JaredBusch said in Managing Hyper-V:
@Dashrender opened this thread with a poor hypothetical scenario.
It is something that can apply to an ITSP or consultant, but it is completely not something that will apply to the vast majority of deployments.
Not hypothetical at all - It's Wired's setup.
@wirestyle22 works for a MSP correct? This MSP manages disparate city equipment.
This is ok different than any other MSP scenario.
Nothing on his machine should have always access to disparate networks.
So the thing you are proposing should not exist.
Now if these disparate networks, with various AD domains, are all city networks, then just pick a domain to join all the hypervirors to and move one.
-
@JaredBusch said in Managing Hyper-V:
@Dashrender said in Managing Hyper-V:
@JaredBusch said in Managing Hyper-V:
@Dashrender opened this thread with a poor hypothetical scenario.
It is something that can apply to an ITSP or consultant, but it is completely not something that will apply to the vast majority of deployments.
Not hypothetical at all - It's Wired's setup.
@wirestyle22 works for a MSP correct? This MSP manages disparate city equipment.
This is ok different than any other MSP scenario.
Nothing on his machine should have always access to disparate networks.
So the thing you are proposing should not exist.
Now if these disparate networks, with various AD domains, are all city networks, then just pick a domain to join all the hypervirors to and move one.
In this example we are only managing city equipment but it all exists on multiple subdomains.
-
@Dashrender said in Managing Hyper-V:
@JaredBusch said in Managing Hyper-V:
@Dashrender opened this thread with a poor hypothetical scenario.
It is something that can apply to an ITSP or consultant, but it is completely not something that will apply to the vast majority of deployments.
In fact, no one ever actually answered my question, Should all Hyper-V hosts be in a single domain to simplify Hyper-V host management?
The only thing that resembles an answer is no - because we don't join the domain at all
That is completely the opposite of what I said. I said join everything to the domain.
-
@wirestyle22 said in Managing Hyper-V:
@JaredBusch said in Managing Hyper-V:
@Dashrender said in Managing Hyper-V:
@JaredBusch said in Managing Hyper-V:
@Dashrender opened this thread with a poor hypothetical scenario.
It is something that can apply to an ITSP or consultant, but it is completely not something that will apply to the vast majority of deployments.
Not hypothetical at all - It's Wired's setup.
@wirestyle22 works for a MSP correct? This MSP manages disparate city equipment.
This is ok different than any other MSP scenario.
Nothing on his machine should have always access to disparate networks.
So the thing you are proposing should not exist.
Now if these disparate networks, with various AD domains, are all city networks, then just pick a domain to join all the hypervirors to and move one.
In this example we are only managing city equipment but it all exists on multiple subdomains.
Then pick one and join them all to it.
Make a VM on a workstation or something that is also joined to that domain and connect to that VM to manage them.
