Hyper-V 2012 R2 delega amministrativa

Nel post Hyper-V: Backup di una VM come utente non amministratore avevo indicato come delegare ad un utente non amministratore lo svolgimento di alcune operazioni.

La procedura si basava sullo snap-in Windows Authorization Manager (AzMan.msc) che è disponibile fino a WS2012.

Infatti, come indicato in Features Removed or Deprecated in Windows Server 2012 R2, Windows Authorization Manager (AzMan) è stato deprecato in WS2012 e rimosso in WS2012 R2:

“Windows Authorization Manager (AzMan) has been removed. You might need to use new management tools for virtual machines or redesign the authorization model.”

Per la precisione Azman.msc in WS2012 R2 esiste ancora, ma le configurazioni impostate non vengono considerate da Hyper-V.

Nativamente in WS2012 è stato introdotto un gruppo locale i cui membri possono amministrare Hyper-V come indicato in What’s New in Hyper-V for Windows Server 2012:

“The Hyper-V Administrators group is introduced and is implemented as a local security group.

What value does this change add?

This group can reduce the number of users that belong to the local Administrators group while providing users with access to Hyper-V.

What works differently?

The Hyper-V Administrators group is a new local security group. Add users to this group instead of the local Administrators group to provide them with access to Hyper-V. Members of the Hyper-V Administrators have complete and unrestricted access to all features of Hyper-V.”

In WS2012 R2 sono poi stati introdotti in cmdlet PowerShell Get-VMConnectAccess, Grant-VMConnectAccess e Revoke-VMConnectAccess che consentono di gestire il diritto di accedere in console a specifiche VM per determinati utenti.

Se si desidera un controllo più granulare di Hyper-V che non sia l’accesso in console o l’amministrazione completa è possibile gestire la cosa tramite System Center Virtual Machine manager (SCVMM),  tool di terze parti oppure tramite PowerShell avviando uno script con privilegi amministrativi.

L’idea è quella di utilizzare Runas con il parametro /savecred (avevo già discusso questa tecnica in questo vecchio post Usare Internet Explorer come nonadmin, mentre per una panoramica delle gestione delle password salvate si veda Gestione delle password di rete)

Per gestire ad esempio il caso di un utente non amministratore locale che deve poter avviare una specifica VM sara possibile creare un file .ps1 per l’avvio dell VM:

C:\Scripts\AvvioVMSample.ps1

Start-VM –Name VMSample

Quindi creare uno script DOS che avvii tramite Runas lo script PowerShell ad esempio con le credenziali dell’amministratore locale:

C:\Scripts\AvvioVMSample.cmd

runas /user:Administrator /savecred “%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe “C:\Scripts\AvvioVMSample.ps1“

Alla prima esecuzione dello script DOS verrà richiesta la password e memorizzata nello store delle credenziali locale dell’utente.

Sebbene leggermente più laborioso, l’approccio tramite PowerShell risulta comunque estremamente flessibile in quanto permette non solo di delegare specifiche operazioni, ma anche di automatizzare ad esempio interventi di manutenzione periodica sul VM e di demandarli a utenti con bassi priviliegi (si pensi ad esempio alla compattazione periodica dei VHD di talune VM).

[Update 01]

Si noti che l’opzione savecred di Runas implica che qualsiasi esecuzione di RUNAS (per qualsiasi altro processo) potrà sfruttare la credenziale salvata.

Quindi come best practices di sicurezza conviene creare un utente ad hoc, per esempio HVAdmin e aggiungerlo al gruppo locale Hyper-V Administrators ed utilizzare le credenziali di tale utente e non quelle dell’Administrator locale per evitare che un malware possa fare privilege escalation tentando un Runas sull’utente Administrator (a riguardo si veda questo il post Sicurezza, runas, savecred e smart card di Marco Russo).