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.
-
@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.
-
@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.
Wired's machine that he is using to manage the Hyper-V for the City, all belong to the city. So for the sake of this conversation, ignore that he actually works for an MSP. Instead consider him an internal IT resource.
Which then moves to you agreeing with the idea of putting all Hyper-V hosts into a single domain for ease of management.
-
@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?
Hyper-V Manager gives you console access to the VMs.
-
@Tim_G 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?
Hyper-V Manager gives you console access to the VMs.
Is that a PowerShell tool? How do you get the console via PowerShell?
-
@scottalanmiller said in Managing Hyper-V:
@Tim_G 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?
Hyper-V Manager gives you console access to the VMs.
Is that a PowerShell tool? How do you get the console via PowerShell?
I'm kind of heading the cloud way without a cloud. My prod templates anymore don't have console logins. I mean you can look at the console but no users can log in through it. Only SSH from Tower with a 4096 bit key.
-
However I have no idea if this is possible with Windows or not.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@Tim_G 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?
Hyper-V Manager gives you console access to the VMs.
Is that a PowerShell tool? How do you get the console via PowerShell?
I'm kind of heading the cloud way without a cloud. My prod templates anymore don't have console logins. I mean you can look at the console but no users can log in through it. Only SSH from Tower with a 4096 bit key.
Right, this is what I was thinking is a good fix. But it requires building that template somewhere initially.
-
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@Tim_G 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?
Hyper-V Manager gives you console access to the VMs.
Is that a PowerShell tool? How do you get the console via PowerShell?
I'm kind of heading the cloud way without a cloud. My prod templates anymore don't have console logins. I mean you can look at the console but no users can log in through it. Only SSH from Tower with a 4096 bit key.
Right, this is what I was thinking is a good fix. But it requires building that template somewhere initially.
That's why I specified prod. Dev still has console access. So if I need it I can use it. Then just move that to prod.
-
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@stacksofplates said in Managing Hyper-V:
@scottalanmiller said in Managing Hyper-V:
@Tim_G 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?
Hyper-V Manager gives you console access to the VMs.
Is that a PowerShell tool? How do you get the console via PowerShell?
I'm kind of heading the cloud way without a cloud. My prod templates anymore don't have console logins. I mean you can look at the console but no users can log in through it. Only SSH from Tower with a 4096 bit key.
Right, this is what I was thinking is a good fix. But it requires building that template somewhere initially.
That's why I specified prod. Dev still has console access. So if I need it I can use it. Then just move that to prod.
Ah, I see.
-
Obviously jsut having a Hyper-V desktop can do this too for SMBs. That might just be the right answer.
-
@JaredBusch said in 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!
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.
They asked for non ad joined management...
-
@matteo-nunziati said in Managing Hyper-V:
@JaredBusch said in 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!
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.
They asked for non ad joined management...
Even so, Jared is right.
-
@wirestyle22 said in Managing Hyper-V:
@matteo-nunziati said in Managing Hyper-V:
@JaredBusch said in 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!
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.
They asked for non ad joined management...
Even so, Jared is right.
There ARE cases where you need or want to avoid AD joining. But I think that I agree, normally AD joining will be best and probably should happen here.
