Creare una farm di Remote Desktop Services in Microsoft Azure

Sicuramente tutti in questi anni avete avuto a che fare con i Remote Desktop Services (RDS), una delle soluzioni migliori per poter ospitare desktop e applicazioni e per poter permettere l’accesso da remoto alle informazioni aziendali.

Oggi voglio farvi vedere con quanta semplicità è possible creare un ambiente di test basato su RDS in Windows Server 2012 R2 o in Windows Server 2016 utilizzando delle macchine virtuali ospitate in Microsoft Azure.

Sia utilizzando la soluzione dell’Azure Marketplace, sia utilizzando i QuickStart template, potete creare un’infrastruttura RDS completa di:

  • 1 Domain Controller
  • 1 RD Web Access
  • 1 RD Gateway
  • 1 RD Connection Broker
  • 2 o più RD Session Host

Per quanti di voi si stiano avvicinando per le prime volte ai Remote Desktop Services consiglio fortemente la lettura dell’articolo https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/Welcome-to-rds, in modo tale che abbiate una panoramica dei diversi ruoli da cui è composta un’infrastruttura RDS.

Figura 1: Infrastruttura RDS creata in Azure

La soluzione presentata è decisamente interessante per un Proof-of-Concept (POC) oppure per un Lab. Se volete mettere in produzione un’infrastruttura RDS vi consiglio di seguire quelle che sono le best practices per la creazione di una farm RDS performante e ridondata, leggendo le guide che potete trovate alla pagina https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-plan-high-availability.

Non dimenticate anche di dare un’occhiata alla pagina https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-supported-config per una panoramica sulle configurazioni supportate.

Figura 2: In produzione è necessario avere un’infrastruttura ridondata

Creazione del Proof of Concept e della farm RDS

La creazione del POC è molto semplice. Collegatevi al portale Azure e create una nuova risorsa scegliendo Remote Desktop Services (RDS) – Basic – Dev/Test. Dal blade che si aprirà seguite le poche semplici indicazioni richieste per creare l’infrastruttura.

Figura 3: Scelta della soluzione Remote Desktop Services (RDS) – Basic – Dev/Test dal Marketplace di Azure

Nel primo passaggio inserite le informazioni relative al nome utente per l’amministratore, alla password, alla sottoscrizione da utilizzate, al resource group e alla location dove verrà creata l’infrastruttura RDS:

Figura 4: Inserimento di nome utente per l’amministratore, password, sottoscrizione da utilizzate, resource group e location

Nel secondo passaggio definite il nome per l’indirizzo IP pubblico, che verrà assegnato alla VM che avrà il ruolo di Remote Desktop Gateway e Remote Desktop Web Access, il nome DNS per l’IP pubblico e il nome di dominio da utilizzare. Il deployment infatti prevede che venga creato anche un domain controller per il nome di dominio scelto.

Figura 5: Indirizzo IP pubblico, nome esterno con cui raggiungere il Remote Desktop Gateway e nome di dominio da creare

Nel terzo passaggio scegliete se volete utilizzare Windows Server 2012 R2 oppure Windows Server 2016, scegliete il numero delle VM che ospiteranno il ruolo Remote Desktop Session Host e scegliete le dimensioni per le macchine virtuali.

Figura 6: Configurazione delle dimensioni delle VM e del sistema operartivo da utilizzare

Verificate quindi di aver inserito tutte le informazioni correttamente e procedete alla creazione dell’ambiente Remote Desktop Services (RDS) – Basic – Dev/Test.

Figura 7: Verifica dell’inserimento delle corrette informazioni per la creazione del POC

Mettetevi comodi perché il deployment dura più di un’ora 🙂

Dopo che saranno state create le macchine virtuali, una macchina verrà promossa a domain controller e le altre verranno aggiunte al dominio. Successivamente verranno installati e configurato tutti i ruoli della farm RDS.

Potete seguire tutte le operazioni che vengono effettuate direttamente dal blade che si aprirà.

Figura 8: Stato del deployment del POC

Volendo è anche possibile selezionare il resource group che avete scelto per il deployment e dalla voce Deployments seguire lo stato e la durata delle operazioni. Questa visualizzazione potrebbe tornarvi comoda anche in futuro, per verificare le informazioni che avete inserito nelle variabili, come la username utilizzata e la password, nel caso non ve lo ricordiate. È anche possibile effettuare il Redeploy o scaricare il template JSON per poterlo modificare a proprio piacimento.

Figura 9: Visualizzazione del Deployment dal Resource Group

Uso dei Quickstart Template per la creazione del POC

Un’alternativa all’utilizzo del Marketplace è utilizzare i template JSON già creati. I template per la creazione dell’ambiente Remote Desktop Services (RDS) – Basic – Dev/Test sono disponibili al link https://azure.microsoft.com/en-us/resources/templates/?term=RD

Nella pagina troverete la possibilità di realizzare 5 scenari diversi:

Nel mio caso ho utilizzato per la creazione della farm RDS il template Basic RDS farm deployment.

Figura 10: Quickstart Templates disponibili per Remote Desktop Services

Cliccate quindi su Basic RDS farm deployment e successivamente sul pulsante Deploy to Azure.

Figura 11: Template per la creazione di una farm RDS

Autenticatevi nel portale Azure e seguite le indicazioni presenti nel blade. Inserite tutte le informazioni richieste e iniziate il deployment con Purchase. Come già detto prima, mettetevi comodi perché il deployment dura oltre un’ora.

Figura 12: Utilizzo del Quickstart Template per la creazione della farm RDS

Verifica del deployment

Terminata la creazione della farm potete collegarvi in desktop remoto alla macchina che ha il ruolo di Remote Desktop Gateway e Remote Desktop Web Access (chiamata gw-vm), l’unica a possedere un indirizzo IP pubblico. Successivamente potete collegarvi in desktop remoto agli indirizzi IP interni delle diverse VM (domain controller, session host, ecc.) per effettuare le operazioni di gestione, per installare le applicazioni sui Session Host, ecc.

Per accedere al portale RD web vi basterà digitare il nome che avete scelto per l’IP pubblico in fase di creazione della farm RDS. Nel mio caso ho digitato https://rdsnic.westeurope.cloudapp.azure.com/rdweb

Figura 13: Connessione al portale RD Web

Creazione delle RemoteApp

I 3 RD Session Host che sono stati creati non hanno applicazioni pubblicate. Per testare il corretto funzionamento potete pubblicare delle RemoteApp. Se non sapete come fare potete leggere il mio articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016

Collegatevi in desktop remoto ad uno dei 3 RD Session Host e dal Server Manager aggiungete tutti i server che compongono l’infrastruttura RDS, come mostrato in figura:

Figura 14: Aggiunta di tutti i server dell’infrastruttura RDS al Server Manager

Cliccate sul nodo Remote Desktop Services e verificate come è stata configurata la farm RDS.

Figura 15: Configurazione della farm RDS

Cliccate su Desktop Collection e aggiungete le RemoteApp alla collection (che è l’insieme di applicazioni che volete rendere disponibili ai vostri utenti). Per brevità ho aggiunto alcune applicazioni già presenti (calcolatrice, paint e wordpad), ma vi ricordo che è necessario installare PRIMA le applicazioni su TUTTI i server RD Session Host, come ho già scritto nella guida Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016. Per installare qualsiasi applicazione su un RD Session Host è necessario andare nel pannello di controllo e scegliere la voce Install Application on Remote Desktop Server. Prima di installare qualsiasi applicazione, infatti, il server Session Host deve essere posto in una speciale modalità (Install Mode) per assicurarsi che l’applicazione possa essere eseguita in un ambiente multi-utente.

Figura 16: Selezione delle applicazioni da rendere disponibili tramite RemoteApp

Figura 17: Le applicazioni aggiunte alla collection sono visibili nel Server Manager

Quando gli utenti si collegheranno alla pagina https://rdsnic.westeurope.cloudapp.azure.com/RDWeb vedranno le applicazioni che ho aggiunto alla collection. Potete creare collection diverse e potete consentire l’utilizzo delle diverse Remote App filtrando i gruppi di accesso.

Figura 18: Le applicazioni aggiunte alla collection sono disponibili tramite RD WEB

Cliccando sull’icona dell’applicazione vi verrà chiesto di collegarvi alla RemoteApp. Come potete vedere dalla figura sotto, la connessione verrà effettuata al Remote Desktop Connection Broker e passerà tramite il Remote Desktop Gateway. Riceverete un messaggio di avviso relativo al publisher della RemoteApp che non ha presentato un certificato valido. I Remote Desktop Services utilizzano i certificati digitali per firmare il traffico e le comunicazioni che avvengono tra i computer. Quando un client si connette al server, l’identità del server viene verificata tramite certificato. Maggiori informazioni sui certificati da utilizzare con I remote Desktop Services possono essere reperite al link Using certificates in Remote Desktop Services.

Figura 19: Connessione alla RemoteApp ed errore del certificato

Inserite le credenziali per accedere al Connection Broker. Da Windows Server 2012 è stata anche inserita la possibilità di effettuare il Web Single Sign-On (web SSO), che riduce il numero di volte che l’utente deve inserire le proprie credenziali quando accede ad una RemoteApp utilizzando il Remote Desktop Web Access.

Figura 20: Inserimento delle credenziali per accedere alla RemoteApp

Dopo aver inserito le credenziali per accedere alla RemoteApp, riceverete un messaggio di errore relativo al certificato presentato dal Remote Desktop Gateway (su cui è installato anche il Remote Desktop Web Access). Poiché il certificato è autofirmato e non è presente nelle Trusted Root Certification Authority del client da cui sto effettuando la connessione, la connessione NON può avvenire e la finestra delle RemoteApp si chiuderà, impedendovi di accedere all’applicazione.

Per potervi connettere esportate manualmente il certificato dal Remote Desktop Gateway e installatelo nelle Trusted Root Certification Authorities di tutti i client da cui volete effettuare la connessione.

In produzione è ovviamente preferibile utilizzare un certificato emesso da un Certification Authority pubblica.

Figura 21: Il certificato presentato dal Remote Desktop Gateway non è attendibile per il client da cui ho effettuato la connessione

Gestione del certificato

Poiché la gestione e l’esportazione del certificato utilizzato dal Remote Desktop Gateway e dal Remote Desktop Web Access può risultare difficoltosa, per agevolare la fase di test Microsoft mette a disposizione uno script PowerShell appositamente creato per questo scopo, che potete scaricare dal link https://gallery.technet.microsoft.com/Azure-Resource-Manager-4ea7e328

Eseguite lo script sulla macchina di test da cui volete effettuare la connessione alle RemoteApp. Lo script vi chiederà di collegarvi alla vostra sottoscrizione Azure e si occuperà di trovare tutti gli ambienti in cui c’è una connessione RDP pubblica oppure c’è un sito ospitato da un RD Web Access.

Eseguite lo script con privilegi amministrativi ed utilizzate la Execution Policy corretta (digitate Set-ExecutionPolicy RemoteSigned -Force per configurare la Execution Policy). Per la sicurezza degli script PowerShell vi rimando alla lettura della guida Gestione delle policy di sicurezza in PowerShell

Poiché lo script utilizza i moduli di AzureRM, nel caso i moduli non fossero presenti verranno installati in maniera automatica dallo script, come si può vedere dalla figura sotto:

Figura 22: Esecuzione dello script ed installazione dei moduli PowerShell per AzureRM

Terminata l’installazione dei moduli mancanti, vi verrà chiesto di autenticarvi alla sottoscrizione Azure e verranno enumerati tutti i resource group presenti nella sottoscrizione. Scegliete il resource group che ospita la farm RDS.

Figura 23: Login alla sottoscrizione Azure

Figura 24: Enumerazione e scelta del Resource Group dove è ospitata la farm RDS

A questo punto lo script enumera tutti gli indirizzi IP pubblici che trova nel resource group e chiede di scegliere quale vogliamo utilizzare. In verde ci evidenzia anche quale sito RD WEB è riuscito a trovare.

Figura 25: Lo script ha trovato il sito ospitato da RD WEB

Dopo aver scelto il sito RD WEB, lo script di occuperà di esportare il certificato e di installarlo nella macchina client da cui abbiamo eseguito lo script. Al termine, in maniera automatica, si aprirà il browser che punterà direttamente alla pagina dell’RD WEB https://rdsnic.westeurope.cloudapp.azure.com/web ed il browser questa volta non ci segnalerà nessun errore del certificato. Fantastico!

Figura 26: La connessione al sito RD Web avviene senza errori del certificato

Dalla macchina client potrete verificare, lanciando il comando Start > Esegui > certlm.msc che il certificato è stato installato dallo script nelle Trusted Root Certification Authorities della macchina.

Figura 27: Il certificato è stato installato nelle Trusted Root Certification Authorities della macchina

Riusciremo quindi, dopo esserci loggati nuovamente al Connection Broker, a collegarci alla RemoteApp.

Figura 28: La connessione alla RemoteApp viene effettuata con successo

Implementare la Multifactor Authentication (MFA) con il Remote Desktop Gateway

Il Remote Desktop Gateway garantisce che le comunicazioni tra Internet e le risorse della rete aziendale siano sicure, grazie all’utilizzo del protocollo HTTPS per incapsulare il traffico RDP.  Gli utenti tendono spesso  a salvare le credenziali di connessione e perdere i dispositivi da cui si connettono. Per questo motivo per aumentare il livello di sicurezza degli accessi è opportuno utilizzare la multi-factor authentication. Utilizzando Microsoft Azure Multi-Factor Authentication Server, l’utente per potersi autenticare dovrà inserire le proprie credenziali e una one-time password (oppure un PIN, rispondere ad un SMS, rispondere ad una telefonata, utilizzare token hardware, ecc…). Nella guida Utilizzare la Azure Multi-Factor Authentication con Remote Desktop Gateway in Windows Server 2016 vi spiego come implementarla per proteggere l’accesso alla farm RDS.

Conclusioni

Remote Desktop Services (RDS) sono una piattaforma di presentation virtualization che permette agli utenti di poter accedere in desktop remoto alle applicazioni, senza che queste vengano installate sulle proprie machine. La creazione di una farm RDS utilizzando Azure è enormemente semplificata, richiede pochi clic e ci permette di poter testare facilmente l’infrastruttura RDS in pochissimo tempo. Ben fatto!