Console remota in System Center 2012 R2
Si applica a: System Center 2012 R2 Virtual Machine Manager
La console remota è una funzionalità introdotta in System Center 2012 R2 che consente ai tenant di accedere alla console delle relative macchine virtuali in scenari in cui altri strumenti remoti (o Desktop remoto) non sono disponibili. I tenant possono usare la console remota per accedere a macchine virtuali quando la macchina virtuale si trova in una rete isolata o non attendibile oppure è accessibile tramite Internet.
Per l'esecuzione della console remota è necessaria la presenza dei componenti seguenti:
Microsoft® Hyper-V® Server 2012 R2
System Center 2012 R2 Virtual Machine Manager
System Center 2012 R2 Service Provider Foundation
Windows Azure Pack per Windows Server
Nota
I tenant devono disporre di un computer client che supporta Remote Desktop Protocol 8.1. Gli utenti che eseguono Windows 8, ad esempio, dovranno effettuare l'aggiornamento a Windows 8,1. Inoltre, i clienti che usano Windows 7 SP1 devono installare KB2830477.
In questa versione la console remota supporta funzionalità limitate. Funzionalità quali gli Appunti, i suoni, il reindirizzamento della stampante e il mapping di unità non sono infatti supportate. La console remota funziona in modo simile a alla connessione tramite tastiera, video e mouse usata da computer fisici.
Autenticazione utente
Hyper-V in Windows Server 2012 R2 supporta l'autenticazione basata sui certificati, che viene usata per garantire che i tenant possano accedere solo alle macchine virtuali loro assegnate. Il portale Web di Windows Azure Pack per Windows Server, Service Provider Foundation e Virtual Machine Manager (VMM) autenticano e autorizzano l'accesso alle macchine virtuali e forniscono un token che l'host Hyper-V usa per concedere l'accesso a una singola macchina virtuale.
Il diagramma seguente illustra i componenti necessari per l'accesso da console remota quando i tenant accedono a una macchina virtuale tramite una rete non attendibile, ad esempio Internet. Gateway Desktop remoto viene omesso se l'ambiente viene distribuito in una rete aziendale.
.jpeg "Autenticazione basata su certificati della console remota")
Per stabilire una relazione di trust vengono usate le chiavi pubbliche e private di un certificato. Nelle sezioni seguenti viene descritto come creare i certificati richiesti.
Creazione di un certificato per l'accesso remoto
I certificati vengono usati per creare una relazione di trust tra il server Gateway Desktop remoto, gli host Hyper-V e VMM. Grazie ai certificati Gateway Desktop remoto e gli host Hyper-V possono accettare i token con attestazioni rilasciati da Gateway Desktop remoto di VMM. È possibile usare lo stesso certificato o certificati diversi per la convalida su Gateway Desktop remoto e sugli host Hyper-V. I certificati validi devono soddisfare i seguenti requisiti:
Il certificato non deve essere scaduto.
Il campo Utilizzo chiavi deve contenere una firma digitale.
Il campo Utilizzo chiavi avanzato deve contenere il seguente identificatore oggetto di Autenticazione client: (1.3.6.1.5.5.7.3.2)
I certificati radice per l'Autorità di certificazione che ha rilasciato il certificato devono essere installati nell'archivio certificati Autorità di certificazione radice attendibili.
Il provider del servizio di crittografia per il certificato deve supportare SHA256.
È possibile ottenere un certificato valido da un'Autorità di certificazione esterna, un'Autorità di certificazione aziendale oppure usando un certificato autofirmato.
Nota
È possibile ottenere un certificato valido da un'Autorità di certificazione esterna, un'Autorità di certificazione aziendale oppure usando un certificato autofirmato. Quando si usa un certificato autofirmato, è necessario inserire la chiave pubblica del certificato nell'archivio certificati Autorità di certificazione radice attendibili del Gateway Desktop remoto e degli host Hyper-V.
Utilizzo dello strumento MakeCert per creare un certificato di prova
A scopo di test, è possibile usare lo strumento MakeCert per creare un certificato autofirmato. MakeCert è incluso in Windows SDK.
Per scaricare l'SDK, vedere Microsoft Windows Software Development Kit.
Per altre informazioni, vedere MakeCert in Windows Dev Center.
Usare il codice seguente come esempio per creare un certificato autofirmato:
makecert -n "CN=Remote Console Connect" -r -pe -a sha256 -e <mm/dd/yyyy> -len 2048 -sky signature -eku 1.3.6.1.5.5.7.3.2 -ss My -sy 24 "<CertificateName>.cer"
dove:
| -sky firma | Utilizzato per la firma |
| -r | Consente di creare il certificato autofirmato |
| -n “CN=Remote Console Connect” | Nome del soggetto (Remote Console Connect) |
| -pe | La chiave privata è esportabile |
| -a sha256 | algoritmo |
| -len 2048 | Lunghezza della chiave |
| -e <mm/dd/yyyy> | Data di scadenza |
| -eku 1.3.6.1.5.5.7.3.2 | Utilizzo chiavi avanzato (identificatore oggetto di Autenticazione client) |
| -ss My | Archivia la chiave privata nell'archivio certificati My |
| -sy 24 | Tipo di provider di crittografia (supporta SHA256) |
| “<NomeCertificato>.cer” | Nome della chiave pubblica |
Utilizzo di un'Autorità di certificazione
Quando si richiede un certificato a un'Autorità di certificazione, è possibile usare con lo strumento Certreq un file con estensione inf del modello di certificato simile al seguente. Per altre informazioni, vedere Certreq.
[Version]
Signature="$Windows NT$"
[NewRequest]
; Change to your,country code, company name and common name
Subject = "C=US, O=Contoso, CN=wap-rdg.contoso.com"
; Indicates both encryption and signing
KeySpec = 1
; Length of the public and private key, use 2048 or higher
KeyLength = 2048
; Certificate will be put into the local computer store
MachineKeySet = TRUE
PrivateKeyArchive = FALSE
RequestType = PKCS10
UserProtected = FALSE
; Allow the key to be shared between multiple computers
Exportable = TRUE
SMIME = False
UseExistingKeySet = FALSE
; ProviderName and ProviderType must be for a CSP that supports SHA256
ProviderName = "Microsoft Enhanced RSA and AES Cryptographic Provider"
ProviderType = 24
; KeyUsage must include DigitalSignature. 0xA0 also includes Key Encipherment
KeyUsage = 0xa0
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2
Per convalidare la conformità di un certificato in un file con estensione pfx ai requisiti dell'algoritmo e di Utilizzo chiavi avanzato, eseguire il seguente script di Windows PowerShell:
$cert = Get-PfxCertificate <cert.pfx>
if ($cert.PrivateKey.CspKeyContainerInfo.ProviderName -ne "Microsoft Enhanced RSA and AES Cryptographic Provider")
{
Write-Warning "CSP may not support SHA256"
}
if (! (Test-Certificate $cert -EKU "1.3.6.1.5.5.7.3.2") )
{
Write-Warning "Certificate is not valid"
}
Installazione del certificato
Dopo avere creato il certificato, è necessario installarlo e configurare Virtual Machine Manager per usarlo al fine di rilasciare i token delle attestazioni. La chiave privata del certificato deve essere importata nel database di Virtual Machine Manager. A tale scopo, usare il cmdlet Set-SCVMMServer di Windows PowerShell, ad esempio:
PS C:\> $mypwd = ConvertTo-SecureString "password" -AsPlainText -Force
PS C:\> $cert = Get-ChildItem .\RemoteConsoleConnect.pfx
PS C:\> $VMMServer = VMMServer01.Contoso.com
PS C:\> Set-SCVMMServer -VMConnectGatewayCertificatePassword $mypwd -VMConnectGatewayCertificatePath $cert -VMConnectHostIdentificationMode FQDN -VMConnectHyperVCertificatePassword $mypwd -VMConnectHyperVCertificatePath $cert -VMConnectTimeToLiveInMinutes 2 -VMMServer $VMMServer
In questo esempio lo stesso certificato viene usato sia per il Gateway Desktop remoto che per gli host Hyper-V e la durata dei token è pari a due minuti. È possibile selezionare una durata per i token da 1 a 60 minuti.
Il server host viene identificato mediante il relativo nome di dominio completo (FQDN). In alternativa, gli host possono essere identificati in base all'indirizzo IPv4, all'indirizzo IPv6 e al nome host. L'identità dell'host è inclusa nel file RDP (Remote Desktop Protocol) che viene inviato ai tenant.
Nota
VMMServer01.Contoso.com viene usato come esempio di nome di server host. Sostituire questo nome con il server effettivo in uso.
%%78%%%
Quando ognuno degli host in Virtual Machine Manager viene aggiornato, questo installa il certificato nell'archivio dei certificati personali dell'host Hyper-V e configura tale host Hyper-V affinché convalidi i token mediante il certificato. Per forzare un aggiornamento di tutti gli host Hyper-V, è possibile usare il seguente comando di Windows PowerShell:
PS C:\> Get-SCVMHost -VMMServer "VMMServer01.Contoso.com" | Read-SCVMHost
Host Hyper-V
Durante l'autenticazione dei token Hyper-V accetta solo quelli firmati mediante certificati specifici e algoritmi hash. In Virtual Machine Manager viene eseguita la configurazione necessaria per gli host Hyper-V. La funzionalità di console remota è supportata solo in Hyper-V in Windows Server 2012 R2.
Quando si usa un certificato autofirmato, è necessario importare la chiave pubblica del certificato nell'archivio certificati Autorità di certificazione radice attendibili per l'host Hyper-V. Usare lo script seguente come esempio per importare la chiave pubblica con Windows PowerShell:
PS C:\> Import-Certificate -CertStoreLocation cert:\LocalMachine\Root -Filepath "<certificate path>.cer"
Se si installa un certificato dopo aver configurato Virtual Machine Manager, è necessario riavviare il servizio Virtual Machine Management Hyper-V.
È possibile verificare che l'host Hyper-V sia configurato correttamente per la console remota nel modo seguente:
Verificare che il certificato sia incluso nell'archivio certificati personali dell'host Hyper-V e che sia attendibile.
Controllare la configurazione hash del certificato dell'autorità emittente attendibile.
Usare lo script seguente come esempio per verificare che il certificato sia installato nell'archivio certificati personali dell'host Hyper-V usando Windows PowerShell:
PS C:\> dir cert:\localmachine\My\ | Where-Object { $_.subject -eq "CN=Remote Console Connect" }
Usare lo script seguente come esempio per verificare la configurazione hash del certificato dell'autorità emittente attendibile Windows PowerShell:
PS C:\> $TSData = Get-WmiObject -computername $Server -NameSpace "root\virtualization\v2" -Class "Msvm_TerminalServiceSettingData"
La matrice TrustedIssuerCertificateHashes deve contenere l'identificazione personale del certificato usata per la connessione alla console remota. La matrice AllowedHashAlgorithms deve essere vuota o contenere l'algoritmo SHA256. Quando la matrice è vuota, viene impostata automaticamente su SHA256 o SHA512.
Nota
Virtual Machine Manager genera i token SHA256.
Gateway Desktop remoto
Gateway Desktop remoto può essere usato solo per l'accesso da console a macchine virtuali. Quando si configura Gateway Desktop remoto, viene apportata una modifica alla configurazione che rende il gateway inutilizzabile per altri scopi. Durante la configurazione di Gateway Desktop remoto vengono eseguite le seguenti attività:
Distribuzione di Gateway Desktop remoto e installazione del plug-in di autenticazione.
Installazione del certificato.
Configurazione dei certificati dell'autorità emittente attendibile (tramite WMI).
Creazione di un certificato per Gateway Desktop remoto.
Per supportare l'autenticazione federata, è necessario installare il gateway di connessione della console di Microsoft System Center Virtual Machine Manager sul server Gateway Desktop remoto. Per iniziare creare una macchina virtuale, quindi abilitare Servizi Desktop remoto.
Installare il componente Gateway di connessione della console di System Center Virtual Machine Manager. I file binari di installazione per questo componente sono disponibili nella cartella dei supporti di installazione di Virtual Machine Manager seguente: CDLayout.EVAL\amd64\Setup\msi\RDGatewayFedAuth. Per una configurazione a elevata disponibilità, installare più Gateway Desktop remoto con il componente Gateway di connessione della console usando un servizio di bilanciamento del carico.
A questo punto, importare la chiave pubblica del certificato nell'archivio certificati personali di ogni server Gateway Desktop remoto. A tale scopo, è possibile usare Windows PowerShell, come illustrato nell'esempio seguente:
PS C:\> Import-Certificate -CertStoreLocation cert:\LocalMachine\My -Filepath "<certificate path>.cer"
Se si usa un certificato autofirmato, è necessario importare la chiave pubblica del certificato nell'archivio certificati Autorità di certificazione radice attendibili per l'account computer. A tale scopo, è possibile usare Windows PowerShell, come illustrato nell'esempio seguente:
PS C:\> Import-Certificate -CertStoreLocation cert:\LocalMachine\Root -Filepath "<certificate path>.cer"
Durante l'autenticazione dei token Gateway Desktop remoto accetta solo quelli firmati mediante certificati specifici e algoritmi hash. Per ottenere questa configurazione è necessario impostare le proprietà TrustedIssuerCertificateHashes e AllowedHashAlgorithms nella classe FedAuthSettings di WMI. Per impostare queste proprietà è necessario disporre di credenziali amministrative.
La proprietà TrustedIssuerCertificateHashes è una matrice di identificazioni personali del certificato che vengono archiviate nel server Gateway Desktop remoto. Per impostare la proprietà TrustedIssuerCertificateHashes, è possibile usare il seguente comando di Windows PowerShell:
$Server = "rdgw.contoso.com"
$Thumbprint = "95442A6B58EB5E443313C1B4AFD2665991D354CA"
$TSData = Get-WmiObject -computername $Server -NameSpace "root\TSGatewayFedAuth2" -Class "FedAuthSettings"
$TSData.TrustedIssuerCertificates = $Thumbprint
$TSData.Put()
L'ultimo passaggio consiste nel selezionare o nel creare un certificato autofirmato per Gateway Desktop remoto. A tale scopo, aprire Gestione Gateway Desktop remoto, fare clic con il pulsante destro del mouse su Gateway Desktop remoto, quindi scegliere Proprietà. Nella finestra di dialogo Proprietà fare clic sulla scheda Certificato SSL.
Questo certificato viene usato dai computer client dei tenant per verificare l'identità del server Gateway Desktop remoto. Il nome CN del certificato deve corrispondere al nome di dominio completo del server Gateway Desktop remoto. Aprire Gestione Gateway Desktop remoto e assegnare o creare un certificato autofirmato.
Nota
Usare un certificato autofirmato solo per scopi di testing. Un certificato autofirmato non deve mai essere usato in un ambiente di produzione. Se si usa un certificato autofirmato, è inoltre necessario che il certificato sia installato in ogni computer tenant che effettua la connessione tramite Gateway Desktop remoto.
Per verificare la configurazione di Gateway Desktop remoto, eseguire la procedura seguente:
Assicurarsi che Gateway Desktop remoto sia configurato in modo da usare il gateway di connessione della console per l'autenticazione e l'autorizzazione. A tale scopo, è possibile usare Windows PowerShell, come illustrato nell'esempio seguente:
PS C:\> Get-WmiObject -Namespace root\CIMV2\TerminalServices -Class Win32_TSGatewayServerSettingsVerificare che le proprietà AuthenticationPlugin e AuthorizationPlugin siano impostate su FedAuthorizationPlugin.
Assicurarsi che sia stato installato un certificato nell'archivio certificati personali per l'account computer. A tale scopo, è possibile usare Windows PowerShell, come illustrato nell'esempio seguente:
PS C:\> dir cert:\localmachine\My\ | Where-Object { $_.subject -eq "CN=Remote Console Connect" }Verificare la configurazione del gateway di connessione della console. A tale scopo, è possibile usare Windows PowerShell, come illustrato nell'esempio seguente:
PS C:\> Get-WmiObject -computername $Server -NameSpace "root\TSGatewayFedAuth2" -Class "FedAuthSettings"La matrice TrustedIssuerCertificates deve contenere l'identificazione personale del certificato per il gateway di connessione della console.
Microsoft Azure Pack per Windows Server per la console remota
È possibile abilitare l'accesso alla console remota in base a piani specifici tramite il servizio per cloud di macchine virtuali incluso in Microsoft Azure Pack per Windows Server. Nel dashboard del piano selezionare Cloud per macchine virtuali nei servizi del piano, quindi scegliere Connetti alla console delle macchine virtuali nelle impostazioni aggiuntive.
Se è stato installato un Gateway Desktop remoto, leggere la procedura Come configurare Microsoft Azure Pack in modo da usare il Gateway Desktop remoto.
Suggerimenti relativi alla sicurezza
Per garantire una maggiore sicurezza, è consigliabile eseguire le operazioni seguenti:
| Nome | Minaccia | Consiglio |
|---|---|---|
| Accesso ai token | È possibile usare l'accesso all'archivio certificati personali per generare token di accesso per qualsiasi macchina virtuale. | Usare i gruppi di sicurezza di Active Directory per limitare l'accesso al server Virtual Machine Manager che genera i token. |
| Durata dei token | Il file RDP (Remote Desktop Protocol) contiene il token EndpointFedAuth. Il possesso di tale file consente di accedere alla console di una macchina virtuale specifica. | Configurare una scadenza breve per il token. La scadenza consigliata è un minuto. Usare il cmdlet SetSCVMMServer di Windows PowerShell per impostare la durata del token. |
| Accesso condiviso | Quando un altro utente richiede l'accesso e accede alla sessione della console, la sessione esistente viene chiusa. Può trattarsi di un host che accede alla console di un utente che ha effettuato l'accesso e quindi accede alle risorse del tenant. Le sessioni della console sono simili alle sessioni KVM degli host fisici. Una sessione di macchina virtuale è disponibile a tutti gli utenti ai quali è stato concesso il privilegio per operazioni di lettura o lettura/scrittura sulla console nei criteri di autorizzazione. Per impostazione predefinita, questo privilegio è concesso a tutti gli amministratori. |
Utenti del tenant: non rimanere connessi a una sessione di console quando non si è attivamente impegnati. Assicurarsi che il sistema operativo si blocchi dopo un breve periodo di inattività. Provider di servizi di hosting: Usare i criteri di autorizzazione per limitare l'accesso in lettura e in scrittura. |
| Utenti malintenzionati | È possibile che utenti malintenzionati tentino di connettersi alle porte tramite il gateway RD senza essere autorizzati. Ad esempio, è possibile che un utente malintenzionato tenti di connettersi alla porta RDP in un host Hyper-V per provare delle combinazioni di nome utente e password. | Configurare i criteri di autorizzazione delle risorse di Desktop remoto nel server gateway RD per impedire agli utenti di connettersi direttamente alla porta 3389 nel server Hyper-V. Le connessioni sono necessarie solo per la porta 2179. Per altre informazioni, vedere Gestire i criteri di autorizzazione risorse Desktop remoto. |
| Attacco man-in-the-middle | Hyper-V è stato progettato per migliorare la protezione contro gli attacchi "man-in-the-middle" (definiti anche MITM). Usare i certificati trusted per identificare l'host Hyper-V può consentire una migliore protezione dagli attacchi MITM. Hyper-V usa un listener a porta singola che usa certificati trusted per l'autenticazione del server. In determinate circostanze, Hyper-V emette un certificato autofirmato che viene quindi usato per l'autenticazione del server. In alternativa, è possibile configurare Hyper-V per l'utilizzo di un altro certificato, come ad esempio un certificato emesso da un'Autorità di certificazione (CA). | Usare un certificato host Hyper-V con una catena di certificati validi connessa a un certificato radice trusted. Ciò impedisce la visualizzazione di un messaggio di errore che informa che è impossibile verificare l'identità del computer remoto. Per altre informazioni, vedere Configuring Certificates for Virtual Machine Connection (Configurazione di certificati per la connessione a macchine virtuali). |
| Analisi di sessioni | Quando è attiva una connessione alla console, il personale dell'host può eseguire uno snapshot della macchina virtuale ed esportarla in un altro server oppure raccogliere immagini di anteprima della console. | Usare i criteri di autorizzazione per limitare l'accesso in lettura e in scrittura. Comunicare ai tenant le situazioni in cui il personale può accedere alle sessioni della console. |
| Configurazione di rete | Un utente malintenzionato può usare le proprietà nel file RDP per ottenere informazioni sulla configurazione di rete. | Stabilire se il nome host o l’indirizzo IP deve essere utilizzato per connettersi a un server che esegue Hyper-V. Queste informazioni sono incluse nel file RDP inviato al consumer del servizio. Sono incluse anche nel certificato presentato dal server che esegue Hyper-V quando viene avviata la connessione alla console. Impostare la configurazione di rete per assicurarsi che i server che eseguono Hyper-V non siano direttamente accessibili da Internet o da una macchina virtuale dell'utente. Un indirizzo IP (in particolare un indirizzo IPv6) riduce la quantità di informazioni divulgate. |
Vedere anche
Come configurare Microsoft Azure Pack in modo da usare il Gateway Desktop remoto