DevAdmin Blog

Blog di Ermanno Goletto (Microsoft MVP Directory Services - MCSE - MCSA - MCITP - MCTS)
posts - 1026, comments - 598, trackbacks - 8

My Links

News

Il blog si è trasferito al seguente link:

www.devadmin.it

Avatar

Visualizza il profilo di Ermanno Goletto su LinkedIn

Follow ermannog on Twitter


Il contenuto di questo blog e di ciascun post viene fornito “così come é”, senza garanzie, e non conferisce alcun diritto. Questo blog riporta il mio personale pensiero che non riflette necessariamente il pensiero del mio datore di lavoro.

Logo Creative Commons Deed


Logo SysAdmin.it SysAdmin.it Staff


Logo TechNet Forum TechNet Italia @ForumTechNetIt Follow TechNet Forum on Twitter


Logo MVP

Article Categories

Archives

Post Categories

Blogs

Friends

Knowledge Base

MVP Sites

Resources

Windows Server 2008 R2/Hyper-V Server 2008 R2 e connessioni WMI

La console di gestione di Hyper-V (virtmgmt.msc) utilizza per connettersi al server Hyper-V la tecnologia WMI, questo comporta determinate configurazioni a seconda che client e server appartengano allo stesso dominio o a domini in trust o meno (per esempio scenari di client e/o server in workgroup).

Per comprendere il motivo di queste configurazioni e quando queste devono essere eseguite occorre comprendere come si sviluppa la comunicazione tramite WMI.

Le connessioni WMI possono essere di 3 tipi: sincrone, semisincrone e asincrone. Le prime due eseguono una connessione dal client verso il server (Connection 1 in Figura 1), mentre nelle connessioni asincrone le callbacks genereranno anche una connessione dal server verso il client (Connection 2 in Figura 1).

image Figura 1

Esempio di connessione sincrona:

Set objSvc = GetObject("winmgmts:")
Set objSet = objSvc.ExecQuery("Select * From Win32_NtLogEvent Where LogFile = 'Application'")
For Each obj in objSet
  count = count + 1
Next

Il ciclo For Each non verrà eseguito fino a che tutti i dati richiesti dalla chiamata ExecQuery non saranno restituiti.

Esempio di connessione asincrona:

Set objSvc = GetObject("winmgmts:")
Set sink = wscript.CreateObject("WbemScripting.SWbemSink","SINK_")
retVal = objSvc.ExecQueryAsync( sink,"Select * From Win32_ntLogEvent Where LogFile = 'Application'")

'Esecuzione di altre elaborazioni nell’attesa.
Sub SINK_OnObjectReady(objObject, objAsyncContext)
  count = count + 1
End Sub

Sub SINK_OnCompleted(iHResult, objErrorObject, objAsyncContext)
  wscript.echo "The Asynchronous operation has finished"
End Sub

E’ possibile eseguire altre elaborazioni mentre si attende la ricezione dei dati richiesti dalla chiamata ExecQueryAsync i quando l’oggetto SWBEMSINK agirà da intermediario ricevendo gli eventi OnObjectReady e OnCompleted).

Esempio di connessione semisincrona

Set objSvc = GetObject("winmgmts:")
Set objSet = objSvc.ExecQuery("Select * From Win32_NtLogEvent Where LogFile = 'Application'",,48)

For Each obj in objSet
  count = count + 1
Next

E’ un metodo migliore sia rispetto al metodo sincrono (perché più performante) che al metodo asincrono (perché richiede una minor allocazione di memoria).

L’esecuzione della ExecQuery è più rapida perché specificando i due flag WbemFlagReturnImmediately (16) e WbemFlagForwardOnly (32) in AND (16 AND 32 = 48) verrà subito ritornato il primo oggetto è poi durante il For Each saranno richiesti gli altri dati.

Per ulteriori informazioni sulle chiamate WMI si veda Calling a Method.

Requisiti necessari per l’esecuzione di comunicazioni WMI remote

Per consentire l’esecuzione delle Connection 1 dal computer A (client) verso il computer B (server) della Connection 2 dal computer B (server) verso il computer A (client) occorre:

  • Configurare il firewall del computer B.
  • Configurare il firewall del computer A.
  • Nel caso in cui i due computer non appartengano allo stesso dominio o a domini in trust (per esempio scenari di client e/o server in workgroup) occorre configurare DCOM per l’accesso anonimo sul computer A.

La UAC prevede un meccanismo di access token filtering, ovvero vi sono due access token per i local admin (standard e administrator).

Nelle connessioni remote tra computer in dominio la UAC access token filtering non influisce se l’account utilizzato su computer A (client) è un account di dominio con privilegi di admin locale sul computer B (server).

Nel caso in cui i due computer non appartengano allo stesso dominio o a domini in trust (per esempio scenari di client e/o server in workgroup) occorre specificare nella connessione WMI un account con privilegi di admin locale sul computer B (è possibile specificare le credenziali nel codice, oppure impostando una password di rete sul computer A o ancora creando sul computer B un account con privilegi di admin locale avente lo stesso username e password dell’account utilizzato sul computer A).

Configurazione del firewall sul computer B (server)

image Figura 2

Affinché sia possibile stabilire connessioni WMI sul computer B è necessario abilitare le seguenti regole di connessione sul Windows Firewall con sicurezza avanzata (wf.msc), di seguito si ipotizza che il computer B abbia come sistema operativo Windows Server 2008 R2 in modalità d’installazione Full o Core oppure Hyper-V Server 2008 R2.

  • Regole Inbound
    • Strumentazione gestione Windows (DCOM-In)
      svchost.exe Servizio: rpcss – TCP 135
    • Strumentazione gestione Windows (WMI-In)
      svchost.exe Servizio: winmgmt – TCP Any
    • Strumentazione gestione Windows (ASync-In)
      unsecapp.exe - TCP Any
  • Regole Outbound
    • Strumentazione gestione Windows (WMI-Out)
      svchost.exe Servizio: winmgmt – TCP Any

In realtà se sul computer B (server) è presente il ruolo Hyper-V sono abilitate per default alcune regole di connessione sul Windows Firewall con sicurezza avanzata che consentono le connessioni WMI.

  • Regole Inbound
    • Hyper-V - WMI (DCOM-In) le cui impostazioni coincidono con Strumentazione gestione Windows (DCOM-In)
    • Hyper-V - WMI (TCP-In) le cui impostazioni coincidono con Strumentazione gestione Windows (WMI-In)
    • Hyper-V - WMI (Async-In) le cui impostazioni coincidono con Strumentazione gestione Windows (ASync-In)
  • Regole Outbound
    • Hyper-V - WMI (TCP-Out) le cui impostazioni coincidono con Strumentazione gestione Windows (WMI-Out)

In ogni caso anche se sul computer B (server) non è presente il ruolo Hyper-V le connessioni WMI di tipo sincrono e semisincrono (solo Connection 1 in Figura 2) sono consentite dalle regole di connessione sul Windows Firewall con sicurezza avanzata relative al DFS che in Windows Server 2008 R2 / Hyper-V Server 2008 R2 sono abilitate per default.

  • Regole Inbound
    • Gestione DFS (DCOM-In) le cui impostazioni coincidono con Strumentazione gestione Windows (DCOM-In)
    • Gestione DFS (WMI-In) le cui impostazioni coincidono con Strumentazione gestione Windows (WMI-In)

Inoltre nel caso sia necessario esporre su firewall le connessioni WMI è possibile configurarle per utilizzare una porta TCP fissa oltre alla porta TCP 135 relativa alla connessione RPC DCOM, a riguardo si veda Setting Up a Fixed Port for WMI.

Si noti anche che sempre le regole di connessione sul Windows Firewall con sicurezza avanzata relative a DFS, abilitate per default su Windows Server 2008 R2 / Hyper-V Server 2008 R2, consentono l’accesso remoto alle share amministrative, al registry e ai servizi. Infatti tra le regole relative al DFS vi è la Gestione DFS (SMB-In) che consente il traffico SMB per System sulla porta TCP 445 e le cui configurazioni coincidono con la Condivisione file e stampanti (SMB-In).

Per esaminare le regole abilitate per default è possibile utilizzare in comando netsh advfirewall firewall, a riguardo si veda Gestione di Windows Firewall da riga di comando.

Configurazione del firewall sul computer A (client)

image Figura 3

Affinché sia possibile avviare connessioni WMI sul computer A e ricevere le callbacks è necessario abilitare le seguenti regole di connessione sul Windows Firewall con sicurezza avanzata (wf.msc), di seguito si ipotizza che il computer A abbia come sistema operativo Windows Server 2008 R2 in modalità d’installazione Full o Windows 7.

  • Regole Outbound
    • Strumentazione gestione Windows (WMI-Out)
      svchost.exe Servizio: winmgmt – TCP Any
  • Regole Inbound
    • Strumentazione gestione Windows (DCOM-In)
      svchost.exe Servizio: rpcss – TCP 135
    • Strumentazione gestione Windows (WMI-In)
      svchost.exe Servizio: winmgmt – TCP Any
    • Strumentazione gestione Windows (ASync-In)
      unsecapp.exe - TCP Any

Installando sul client gli strumenti di amministrazione remota (RSAT) e abilitando la funzionalità degli Strumenti di Hyper-V vengono abilitate le seguenti regole di connessione che consentono le connessioni WMI.

  • Regole Outbound
    • Client di gestione Hyper-V - WMI (TCP-Out) le cui impostazioni coincidono con Strumentazione gestione Windows (WMI-Out)
  • Regole Inbound
    • Client di gestione Hyper-V - WMI (DCOM-In) le cui impostazioni coincidono con Strumentazione gestione Windows (DCOM-In)
    • Client di gestione Hyper-V - WMI (TCP-In) le cui impostazioni coincidono con Strumentazione gestione Windows (WMI-In)
    • Client di gestione Hyper-V - WMI (Async-In) le cui impostazioni coincidono con Strumentazione gestione Windows (ASync-In)

Si noti anche che dal momento che per default il Windows Firewall con sicurezza avanzata è impostato per consentire le connessioni Outbound su tutti i profili (Privato, Dominio e Pubblico) le connessioni WMI di tipo sincrono e semisincrono (solo Connection 1 in Figura 3) sono comunque consentite.

Conclusioni

In conclusione per consentire le comunicazioni WMI al fine di utilizzare la console di gestione di Hyper-V (virtmgmt.msc) remotamente o altre applicazioni WMI (per esempio Hyper-V Guest Console) in sintesi sono necessarie le seguenti:

  • Consentire l’accesso remoto anonimo a DCOM sul computer A (client)
  • Autenticarsi sul computer B (server) con un account con privilegi di amministratore locale
    • Se il client e il server appartengono allo stesso dominio o a domini in trust è possibile utilizzare una delle seguenti soluzioni:
      • Connetteri al client con un account di dominio con privilegi di amministratore locale sul server
      • Specificare sul client una password di rete relativa ad un account con privilegi di amministratore locale sul server
      • Creare sul server un account con privilegi di admin locale avente lo stesso username e password dell’account utilizzato sul client
    • Se il client e il server non appartengono allo stesso dominio o a domini in trust (per esempio scenari di client e/o server in workgroup) è possibile utilizzare una delle seguenti soluzioni:
      • Specificare sul client una password di rete relativa ad un account con privilegi di amministratore locale sul server
      • Creare sul server un account con privilegi di admin locale avente lo stesso username e password dell’account utilizzato sul client
  • Sul client non è necessaria alcuna impostazione relativa al firewall dal momento che la funzionalità degli Strumenti di Hyper-V (disponibile installando gli RSAT) configura le regole di connessione necessarie sul Windows Firewall con sicurezza avanzata
  • Sul server non è necessaria alcuna impostazione relativa al firewall dal momento che il ruolo Hyper-V configura le regole di connessione necessarie sul Windows Firewall con sicurezza avanzata

Per eseguire le configurazioni necessarie è possibile utilizzare lo script HVRemote sviluppato da J. Howard Senior PM HV team.

Per un approfondimenti su questi temi si veda il post Hyper-V Remote Management: You do not have the required permission to complete this task. Contact the administrator of the authorization policy for the computer ‘COMPUTERNAME di J. Howard suddiviso in 5 parti:

Print | posted on Wednesday, October 26, 2011 10:30 AM | Filed Under [ Links Tips Security IT ]

Powered by:
Powered By Subtext Powered By ASP.NET