Hyper-V en toegang beperken tot VMs

[Blokker_1999]

We zijn voor een project aan het kijken of we hier gebruik kunnen gaan maken van Hyper-V in plaats van vSphere/ESXi. 1 van de vereisten die we wel hebben is dat we kunnen gaan bepalen wie toegang krijgt tot welke VM. Evenwel kent Hyper-V zelf niet direct een vorm van access control.

Dit kan wel met VMM, maar dat is enkel nog verkrijgbaar als onderdeel van System Center en net 1 van die producten die we zelf nooit in gebruik genomen hebben en wat we voor dit project alleen ook niet snel zullen gaan aankopen.

Volgens verschillende bronnen die ik online gevonden heb moet het mogelijk zijn om met behulp van PowerShell en het cmdlet Grant-VMConnectAccess toegang te geven aan 1 of meerdere VMs voor 1 of meerdere gebruikers, evenwel wanneer ik een gebruiker toevoeg aan een VM en dan vmconnect.exe opstart met die gebruiker krijg ik een melding dat ik niet geauthoriseerd ben om te verbinden met de hypervisor.

Is er toevallig iemand die dit wel werkende heeft gekregen en weet wat er ontbreekt? Of zijn er mensen die alternatieven kunnen aanbevelen? Ik kwam al HvManager tegen als mogelijk alternatief, en een fractie van de kost van System Center in dit geval, maar krijg er voor de rest ook niet zo veel over gevonden.

[Semt-x]

Zijn RDP/SSH permissies naar VMs voor specifieke users geen optie?

[Microkid]

Semt-x schreef op zaterdag 30 november 2024 @ 12:38:
Zijn RDP/SSH permissies naar VMs voor specifieke users geen optie?

Ik denk dat @Blokker_1999 eerder bedoelt: hoe scherm ik via de Hyper-V manager af wie bij welke VM's mag komen. Via RDP is het inderdaad al mogelijk om dit met AD/Groups permissies te doen. Maar de standaard Hyper-V manager heeft geen enkele mogelijkheid om gedelegeerd beheer van VM's mogelijk te maken.

[Blokker_1999]

@Microkid, dat klopt. Op deze VMs is console toegang nodig, zeg maar, tot de virtuele monitor die er op hangt vanwege het doel van deze systemen. met vSphere heb je de VMRC waarmee het kan, en vroeger kon het op Hyper-V ook met azman, maar dat is sinds 2012r2 niet meer aanwezig omdat Microsoft iedereen naar VMM wenst te duwen wat men dan later weer exclusief aan System Center heeft verbonden wat de kosten ongelooflijk hoog maakt als je enkel maar VMM nodig hebt.

[Zwelgje]

Andere hypervisor kiezen waarmee het wel kan, in the end maakt het ook niet uit welke hypervisor je gebruikt het gaat om de VM's en de Apps.

en je wilt iets wat HyperV niet kan dus daar kan een streep door.

proxmox dan maar

[Sebazzz]

Blokker_1999 schreef op vrijdag 29 november 2024 @ 16:15:
Volgens verschillende bronnen die ik online gevonden heb moet het mogelijk zijn om met behulp van PowerShell en het cmdlet Grant-VMConnectAccess toegang te geven aan 1 of meerdere VMs voor 1 of meerdere gebruikers, evenwel wanneer ik een gebruiker toevoeg aan een VM en dan vmconnect.exe opstart met die gebruiker krijg ik een melding dat ik niet geauthoriseerd ben om te verbinden met de hypervisor.

Klopt, want je moet sowieso local admin zijn op de Hyper-V host om dat te kunnen doen. Compleet idioot.

[Gr4mpyC3t]

En wat als je het beheer niet via de console regelt, maar via zoiets als een CI/CD pipeline?

Dan bouw je het beheer mooi op in code, maak je er templates van/voor en staat het netjes in Git repository dat met checks en balances veilig blijft.

Er zijn zat PowerShell cmdlets voor Hyper-V en tools zat die pipelines kunnen draaien.

[Blokker_1999]

Het gaat niet om het beheer, zij moeten met de software kunnen werken op die VM, en dat mag niet via RDP omdat RDP verbindingen de consistentie kunnen breken door bijvoorbeeld de schermresolutie aan te passen.

@Zwelgje, we zijn hier net bezig met een evaluatie te doen om te zien welke opties we hebben voor welke toepassingen in de toekomst en welke uitdagingen er bij komen kijken. Nagaan welke oplossingen er daarvoor zijn. Zo werd er intern al gesproken over bijvoorbeeld VNC te gaan gebruiken omdat dat je ook op die console dropt, maar ook daar hebben we weer minder controle over wie aan welke VM kan, want wachtwoorden zijn dan zo door te geven.

[Sebazzz]

Blokker_1999 schreef op zaterdag 30 november 2024 @ 16:21:
Het gaat niet om het beheer, zij moeten met de software kunnen werken op die VM, en dat mag niet via RDP omdat RDP verbindingen de consistentie kunnen breken door bijvoorbeeld de schermresolutie aan te passen.

Dat is waar, maar je kan wel een policy toepassen waarbij RDP verbindingen pas na X uur worden opgeruimd.

Andere creatieve oplossing wellicht: VNC server installeren op de VM, en dan via RDP op de server VNC client starten en daarop inloggen?

[Gr4mpyC3t]

Blokker_1999 schreef op zaterdag 30 november 2024 @ 16:21:
Het gaat niet om het beheer, zij moeten met de software kunnen werken op die VM, en dat mag niet via RDP omdat RDP verbindingen de consistentie kunnen breken door bijvoorbeeld de schermresolutie aan te passen.

Excuses, dan heb ik dat verkeerd gelezen/begrepen.

[ElCondor]

Blokker_1999 schreef op zaterdag 30 november 2024 @ 16:21:
Het gaat niet om het beheer, zij moeten met de software kunnen werken op die VM, en dat mag niet via RDP omdat RDP verbindingen de consistentie kunnen breken door bijvoorbeeld de schermresolutie aan te passen.

@Zwelgje, we zijn hier net bezig met een evaluatie te doen om te zien welke opties we hebben voor welke toepassingen in de toekomst en welke uitdagingen er bij komen kijken. Nagaan welke oplossingen er daarvoor zijn. Zo werd er intern al gesproken over bijvoorbeeld VNC te gaan gebruiken omdat dat je ook op die console dropt, maar ook daar hebben we weer minder controle over wie aan welke VM kan, want wachtwoorden zijn dan zo door te geven.

Niet om het een of ander en uiteraard kan ik me vergissen, maar is de console die vanuit Hyper-V manager wordt opgestart niet gewoon een RDP onder de motorkap? Het is in ieder geval met die sessies ook zo dat als je ze windowed of maximized draait de resolutie zal meeschalen.
Daarnaast weet ik niet of het licentie-wise toegestaan is om user via de console te laten draaien. Los van of het technisch mogelijk is. Je kunt dan in ieder geval maar één user per VM toegang geven (dat is mogelijk ook wat je wil).

Is het nu dan de bedoeling dat medewerkers een eigen Hyper-V installatie op hun machine gaan draaien en dan connectie maken met de daarop draaiende VM-s? Of wil je ze alleen de Hyper-V manager geven op hun werkstations en daarmee laten connecten? (Dan nog is het, meen ik, RDP onder de motorkap).
Is er wellicht een additioneel PowerShell mdlet welke je moet gebruiken om eerst een gebruiker toegang te geven tot de Hyper-V service op de Hyper-V host? Als ze Hyper-V Manager opstarten op hun werkstation kunnen ze dan wel een lijst met VM's zien? Zien ze alleen hun eigen VM (waar jij ze toegang op hebt gegeven via bovengenoemd cmdlet)?

-- UPDATE 1 --
Ohw ja, wat me net nog te binnen schiet: heb je geprobeerd de users Local Admin te maken op de Hyper-V host? Let wel: dit is een suggestie, géén oplossing. Als het werkt met users als local admin, dan is het in ieder geval een credential issue. Je moet dan gaan kijken welke additionele rechten een user nodig heeft op de host om te connecten naar VM's. Ik zou in géén geval de users local admin laten blijven.

-- UDPATE 2 --
Heb je ook geprobeerd om met Get-VMConnectAccess te checken of de user inderdaad toegang heeft tot de betreffende VM?

[ Voor 12% gewijzigd door ElCondor op 03-12-2024 08:27 ]

[Blokker_1999]

Neen, de console is enkel een RDP sessie als je kiest voor de enhanced features. Als je die uit zet in VMconnect, dan krijg je het virtuele scherm van de virtuele PC te zien ipv een RDP sessie. Dit merk je zeer hard wanneer je als gebruiker geen rechten hebt om RDP te doen En bij een console sessie gaat de resolutie net niet meeschalen. Als je in Windows gaat kijken zul je zien dat je bij een console sessie netjes zelf de resolutie in settings kunt opgeven terwijl dit bij een RDP sessie niet mogelijk is.

Het doel is dat we enkele tientallen VMs gaan draaien op 1 server, maar dat niet iedereen aan alle VMs kan, maar enkel aan die VMs waar zij hun testen op moeten uitvoeren, en dat moet dan weer met een vaste schermresolutie waardoor we op de console moeten zijn ipv RDP net om dat herschalen te voorkomen.

Ze kunnen Hyper-V manager dan ook niet opstarten omdat ze geen admin zijn op Hyper-V, iets wat ze ook zouden zijn als we ze admin zouden maken op de host, iets wat je in een bedrijf absoluut niet wenst te doen. En als ze admin zijn kunnen ze opnieuw alle VMs zien, wat dus net niet de bedoeling is.

Of de gebruiker toegang heeft tot een VM is niet eens relevant, je moet de console kunnen opstarten en ermee verbinden. Het kan even goed zijn dat er met een andere, lokale account bijvoorbeeld wordt aangemeld, Hyper-V is zich daar niet bewust van en hoort zich daar ook niet bewust van te zijn. Ik heb wel reeds geprobeerd om de user toegang te geven tot de host, om zo na te gaan of dat het probleem zou oplossen, maar zelfs vanop localhost blijft VMconnect zeggen dat de gebruiker geen rechten heeft. Er ontbreekt dus nog iets anders.

[ElCondor]

Dus de Hyper-V manager wordt opgestart vanaf het werkstation van een gebruiker en als hij in de Manager kiest om te connecten naar de Hyper-V host, dan krijg je een foutmelding.

Heb je de exacte text van die foutmelding of een screenshot?

-- UPDATE --
Had je dit al gezien? Dus je users aan de Hyper-V Administrators of Readers groep op de Hyper-V Host toevoegen?

Wel een heeeeel specifieke use-case dit..

[ Voor 37% gewijzigd door ElCondor op 03-12-2024 10:30 ]

[Magnum1982]

Digging....

Heb je hier iets op gevonden @Blokker_1999 ?
Ik vind het helemaal niet zo'n rare use case eerlijk gezegd...

[Blokker_1999]

Nope, niets op gevonden. Het lijkt simpelweg niet mogelijk te zijn. We zijn op dit moment Azure Local aan het evalueren waarbij je meer mogelijkheden hebt.

[Rhannie]

Blokker_1999 schreef op dinsdag 3 december 2024 @ 09:56:
Neen, de console is enkel een RDP sessie als je kiest voor de enhanced features. Als je die uit zet in VMconnect, dan krijg je het virtuele scherm van de virtuele PC te zien ipv een RDP sessie. Dit merk je zeer hard wanneer je als gebruiker geen rechten hebt om RDP te doen En bij een console sessie gaat de resolutie net niet meeschalen. Als je in Windows gaat kijken zul je zien dat je bij een console sessie netjes zelf de resolutie in settings kunt opgeven terwijl dit bij een RDP sessie niet mogelijk is.

Het doel is dat we enkele tientallen VMs gaan draaien op 1 server, maar dat niet iedereen aan alle VMs kan, maar enkel aan die VMs waar zij hun testen op moeten uitvoeren, en dat moet dan weer met een vaste schermresolutie waardoor we op de console moeten zijn ipv RDP net om dat herschalen te voorkomen.

Ik heb dit net getest, maar de werkelijkheid lijkt het tegenovergestelde te zijn van wat je hier zegt? Als ik in Hyper-V de console van een server open, dan schaalt de inhoud gewoon mee met de grootte van het venster, ondanks dat Hyper-V bij het verbinden om een resolutie vraagt. Als ik in mstsc een resolutie op geef en een RDP-verbinding op zet met een server, krijg ik een venster dat ik niet kan resizen.

Als mstsc je niet de resolutie geeft die je wil, kan je de RDP-koppeling zelf ook aanpassen met iets als notepad en de volgende 2 regels toevoegen/wijzigen:

code:

desktopwidth:i:1280
desktopheight:i:720

Als er nog andere redenen zijn waarom directe toegang tot de console nodig is, dan gaat dit niet op natuurlijk, maar aan de posts in het topic te zien lijkt dit de enige reden te zijn om geen RDP te gebruiken.