• Guide, Sistemi Operativi
• 26 Gennaio 2018

Abbiamo visto nell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016 come creare una Session Collection di RemoteApp e come configurare un’infrastruttura basata sui Remote Desktop Services di Windows Server 2016. In questa guida vedremo come rendere disponibile l’accesso alle applicazioni anche da Internet in maniera sicura tramite il ruolo Remote Desktop Gateway.

Il Remote Desktop Gateway è uno dei ruoli dell’infrastruttura di Remote Desktop per consente agli utenti remoti di connettersi a qualsiasi risorsa interna alla LAN da Internet, utilizzando una connessione crittografata, senza dover configurare connessioni VPN (Virtual Private Network) verso l’azienda. Il server trasmette il traffico RDP attraverso la porta 443, utilizzando un tunnel HTTP over TLS/SSL (Transport Layer Security/Secure Sockets Layer). Questo siginifica che , indipendentemente dai server remoti che vogliamo raggiungere, è sufficiente avere un unico server Remote Desktop Gateway (o più di uno per avere alta disponibilità) esposto ad Internet ed un’unica porta aperta (TCP 443) per poterci connettere a tutta l’infrastruttura aziendale.

Inoltre questo ruolo consente di configurare i criteri di autorizzazione (policy) per definire le condizioni che gli utenti remoti devono rispettare per connettersi alle risorse di rete interne. È possibile, ad esempio, specificare:

• Utenti o gruppi autorizzati a connettersi alle risorse di rete interne
• Risorse di rete, o gruppi di computer, a cui possono connettersi gli utenti.
• Se i computer client debbano o meno essere membri di gruppi di sicurezza di Active Directory.
• Se è consentito il reindirizzamento dei dispositivi (stampanti, porte USB, dischi locali del client).

Potete approfondire l’utilità di questo ruolo leggendo l’articolo Overview of Remote Desktop Gateway, che anche se un po’ datato vi darà un’idea ben chiara di tutte le funzionalità ed i vantaggi offerti dal Gateway.

Figura 1: Principio di funzionamento del Remote Desktop Gateway

Installazione del Remote Desktop Gateway (RDGW)

Per installare il Remote Desktop Gateway è sufficiente lanciare il wizard per l’aggiunta e la rimozione dei ruoli. Se volete creare delle policy di accesso al server che utilizzino i gruppi di Active Directory vi conviene aggiungere il server RDGW a dominio. Nel mio caso ho chiamato la macchina RDGW01 e l’ho aggiunta al dominio demo.lab

Figura 2: Aggiunta del ruolo Remote Desktop Services

Proseguite con il wizard fino ad arrivare alla scheda dei Role Services dei Remote Desktop Services e mettete il segno di spunta su Remote Desktop Gateway. Verranno automaticamente aggiunti tutti i ruoli e le feature necessarie al funzionamento del RDGW. Come potete notare verrà aggiunto anche il ruolo di Network Policy Server, il web server IIS e la funzione RPC over HTTP, che si occuperà di incapsulare il traffico RDP in un tunnel protetto HTTPS.

Figura 3: Aggiunta del role service e di tutte le funzionalità necessarie

Dopo pochi istanti verranno installati tutti i ruoli e le funzionalità per permettere il funzionamento del Remote Desktop Gateway.

Figura 4: installazione del ruolo Remote Desktop Gateway completata

Per poter configurare il RDGW è sufficiente lanciare la console RD Gateway Manager da Server Manager–>Tools–>Remote Desktop Services–> RD Gateway Manager

Figura 5: Console di gestione RD Gateway Manager

Per poter permettere che il traffico del vostro server RDGW sia sicuro è necessario importare ed installare nel server un certificato digitale. Sicuramente il server RDGW sarà quello che esporrete ad Internet ed è quindi necessario che il certificato digitale sia rilasciato da una Certification Authority pubblica, se volete permettere anche ad utenti non del vostro dominio di poter accedere alle applicazioni. Aprite le proprietà del server cliccando col tasto destro sul suo nome e dalla scheda SSL Certificate importate il certificato che vi site procurati preventivamente, come mostrato in figura:

Figura 6: Importazione del certificato nel RDGW

Nel mio caso ho utilizzato il certificato wildcard *.nicolaferrini.it, ma è sufficiente utilizzare un certificato che coincida con il nome del RDGW che darete ai vostri utenti.

Il certificato pubblico può essere richiesto alla certification gratuita Let’s encrypt. Vi invito a leggere il mio articolo Generazione di certificati digitali pubblici utilizzando la Certification Authority gratuita Let’s Encrypt e PowerShell per procurarvene uno valido ed in maniera rapida!

Figura 7: Installazione del certificato completata

Per permettere ai vostri utenti di accedere al server RDGW è necessario creare una nuova Authorization Policy, che indicherà sia chi è autorizzato ad accedere alla rete interna sia a quali server specifici (risorse) è possibile accedere. Lanciate quindi il wizard come mostrato in figura:

Figura 8: wizard di creazione della Authorization Policy

Date un nome alla Remote Desktop Connection Authorization Policy (RD CAP) e cliccate su Next

Figura 9: Nome della Remote Desktop Connection Authorization Policy (RD CAP)

Decidete se gli utenti devono utilizzare per il login una password o anche una smart card e aggiungete un gruppo di utenti che avranno le autorizzazioni ad accedere al RDGW. I gruppi di utenti possono essere locali al RDGW oppure possono essere gruppi di sicurezza del vostro dominio (se il server RDGW è joinato ad un dominio):

Figura 10: Scelta del gruppo di utenti autorizzati ad accedere al RDGW

Proseguite nel wizard indicando se abilitare o disabilitare la possibilità da parte degli utenti di portare in sessione remota le risorse locali ed i dispositivi

Figura 11: Abilitazione della Device Redirection

È anche possibile specificare un limite alla durata della sessione (session timeout) oppure un limite di tempo (idle timeout) prima che la sessione utente venga chiusa, quando l’utente si disconnette invece che fare logoff.

Figura 12: Scelta di eventuali timeout per le sessioni utente

Ricontrollate le configurazioni della vostra policy Connection Authorization Policy (RD CAP) e proseguite con il wizard cliccando su Next

Figura 13: Configurazioni della Remote Desktop Connection Authorization Policy

Il wizard procede con la creazione di una Resource Authorization Policy (RD RAP), che indica quali risorse possono essere utilizzate dagli utenti che si connettono in remoto utilizzando il Remote Desktop Gateway. Potete dare alla RD RAP lo stesso nome che avete dato alla RD CAP.

Figura 14: Nome delle Remote Desktop Resource Authorization Policy (RD RAP)

Aggiungete i gruppi di utenti che dovranno essere associati alla Resource Authorization Policy (RD RAP). In genere sono gli stessi gruppi che avete indicato nella Connection Authorization Policy (RD CAP).

Figura 15: Gruppi che devono utilizzare la Resource Authorization Policy (RD RAP)

Nella schermata successiva del wizard potete scegliere a quali risorse interne alla rete (a quali computer) gli utenti potranno collegarsi in Desktop remoto. Se non avete particolari restrizioni potete anche permettere l’accesso a tutte le risorse.

Figura 16: Definizione delle risorse interne alla rete a cui è possibile accedere tramite RDGW

Scegliete a questo punto quali porte volete consentire per le connessioni. La porta RDP di default è la TCP 3389 ma se avete cambiato le porte interne dei vostri terminal server è possibile specificarle.

Figura 17: Scelta della porte su cui autorizzare le connessioni RDP

Terminate il wizard verificando di aver inserito in maniera corretta tutte le informazioni richieste per creare la Resource Authorization Policy (RD RAP).

Figura 18: Configurazione della RD RAP completata

Terminata la creazione delle due policy (RD CAP e RD RAP) potete fare clic su Close.

Figura 19: Creazione delle due policy completata

Adesso che avete terminato la configurazione del vostro Remote Desktop Gateway siete pronti per testare le vostre connessioni verso le risorse aziendali.

EDIT del 24/03/2021 . Francesco Gatti (che ringrazio per la segnalazione e per gli screenshot prodotti!) mi fa notare che in Windows Server 2019 build 17763.1817 il server NPS non si è automaticamente registrato in Active Directoy e che è stato necessaio farlo a mano. Nessun errore è apparso nel wizard di configurazione nè tantomeno sono apparsi errori relativi alla registrazione nel registro eventi.

Il problema si presenta nel momento in cui gli utenti cercano di entrare e c’è l’impossibilità da parte della componente NPS (Network Policy Server) di autenticare gli utenti al dominio. Nella figura sotto è mostrato l’errore che appare nel registro eventi.

Errore di connessione del NPS al dominio

Di conseguenza le sessioni non vengono autenticate quando c’è un tentativo di connessione tramite RDS Gateway

Sessione non autenticata per impossibilità di connettersi al dominio

Per risolvere questo problema è necessario aprire la console di NPS e dal menu selezionare la voce per registrare il server in Active Directory. Questa operazione consente al NPS di verificare gli utenti in Active Directory..

Registrazione del server NPS in AD

Connessione riuscita da NPS verso il dominio

 

Verifica della connessione tramite client RDP

Per testare la connessione tramite client RDP di Windows basta aprire il Remote Desktop Connection client (mstsc.exe) e dalla scheda Advanced configurare la sezione Connect from anywhere, cliccando su Settings e configurando il client con le impostazioni visibili in figura:

Figura 20: configurazione del Remote Desktop gateway nel Connection client

Nel momento in cui cercherete di connettervi vi verrà chiesto di fornire le credenziali di accesso al server RDGW e successivamente le credenziali per connettervi al server di destinazione. Le credenziali da inserire possono coincidere oppure posso differire. Tutto dipende da come avete impostato le regole di connessione. Ad esempio, supponiamo che vogliate connettervi, da Internet e attraverso il vostro RDGW, al domain controller. Per connettervi al RDGW potreste usare le credenziali di un utente locale del RDGW o di un utente del dominio, mentre per accedere al domain controller potreste utilizzare le credenziali di un utente privilegiato.

Figura 21: inserimento delle credenziali di accesso a Remote Desktop Gateway

Figura 22: Inserimento delle credenziali di accesso al computer di destinazione

Se le credenziali saranno state inserite correttamente avrete il warning relativo al certificato presentato dal server di destinazione (nel mio caso DC01.demo.lab) e potrete accedere al suo desktop.

Figura 23: connessione effettuata al server di destinazione

Per verificare che effettivamente siate collegati al server remoto (nel mio caso il domainc ontroller) utilizzando il Remote desktop gateway potete utilizzare il comando netstat –na | find “443” | find “ESTABLISHED”, che vi mostrerà tutte le connessioni riuscite che utilizzando la porta indicata

Figura 24: Utilizzo del comando Netstat per la verifica della connessione attraverso al porta 443

Configurazione del Remote Desktop Gateway in una infrastruttura di Remote Desktop Services esistente

Per aggiungere il Remote Desktop Gateway appena creato ad una infrastruttura esistente, come ad esempio quella presentata nell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016, in cui abbiamo realizzato un Session-based deployment, è sufficiente aggiungere al server Manager il server di Connection Broker in modo tale da poterlo amministrare da remoto. Maggiori informazioni su come amministrare un serve remoto sono reperibili leggendo l’articolo add Servers to Server Manager

Dal Server Manager selezionate il nodo dei Remote Desktop Service e dalla scheda Overview cliccate col tasto destro sull’icona RD Gateway e scegliete Add RD Gateway Servers, come mostrato in figura:

Figura 25: Aggiunta del server RDGW ad un’infrastruttura esistente

Nel wizard che si aprirà selezionate dall’elenco il server corretto e aggiungetelo, tramite il simbolo a forma di freccia, ai server selezionati.

Figura 26: Selezione del server RDGW da aggiungere al deployment

Nel passaggio successivo scegliete con quale nome il server dovrà essere individuato dagli utenti Internet. Verrà generato un certificato di tipo Self-Signed, che potrete successivamente sostituire con uno comprato da una Certification Authority pubblica.

Figura 27: Nome del certificato self-signed

Dopo qualche secondo la configurazione è completata.

Figura 28: aggiunta del server RDGW al deployment esistente completata

Vi consiglio di modificare subito il certificato esibito dal vostro server RDGW. Cliccate sul link Configure certificate che è apparso alla fine del wizard e approfittate per importare il certificato corretto. Nel mio caso ho utilizzato il wildcard *.nicolaferrini.it. Il certificato può essere modificato in qualsiasi momento dal Server Manager, Nodo Remote Desktop Services, selezionando Overview e da Tasks scegliendo Edit Deployment Properties.

Figura 29: Importazione e configurazione del certificato corretto per il RDGW

Rimanendo nella stessa finestra di Deployment Properties, cliccate su RD Gateway e aggiungete il server di Remote Desktop Gateway al vostro deployment. Selezionate l’opzione Use these RD Gateway Settings e configurate come mostrato in figura:

Figura 30: Il Deployment adesso utilizzerà il serve di Remote Desktop Gateway

A questo punto la configurazione è terminata e non vi resta atro che testare il vostro deployment.

Connessione alle RemoteApp della Session Collection attraverso il Remote Desktop Gateway

Loggatevi all’indirizzo del vostro Web Access. Nel mio caso l’host si chiama rds01.demo.lab, ma l’ho anche pubblicato esternamente con il nome apps.nicolaferrini.it. L’indirizzo completo a cui collegarvi è quindi https://apps.nicolaferrini.it/rdweb. Avendo installato un certificato valido non ottengo nessun messaggio di errore. Dalla schermata di login inserite le credenziali di un utente che avete aggiunto al gruppo autorizzato ad accedere alla vostra Session Collection, come mostrato in figura:

Figura 31: Connessione al Web Access

Dopo aver inserito le credenziali vi appariranno le icone delle applicazioni (RemoteApp) che sono disponibili nella vostra Session Collection. Cliccate su una delle icone per lanciare il programma.

Figura 32: RemoteApp disponibili nella Session Collection

Dopo aver lanciato la connessione verso l’applicazione, vi apparirà un messaggio in cui vi verrà chiesto se considerare attendibile il Publisher dell’applicazione. In più vi verranno date indicazioni anche sul computer remoto a cui vi state connettendo (rds01.demo.lab). Come potete notare dalla figura sotto, la connessione avverrà attraverso un Gateway server chiamato rdgw01.nicolaferrini.it

Figura 33: Connessione alla RemoteApp utilizzando il Remote Desktop Gateway

Inserite le credenziali richieste e finalmente sarete connessi alla vostra applicazione, ma questa volta attraverso un tunnel HTTPS:

Figura 34: Apertura della RemoteApp di Word 2016

Aumentare le sicurezza utilizzando la Multi-Factor Authentication

Per rendere ancora più sicuro l’accesso all’infrastruttura è possibile utilizzare la Multi-Factor Authentication unita all’utilizzo del Remote Desktop Gateway. Per conoscere la modalità di implementazione vi rimando alla lettura dela guida Utilizzare la Azure Multi-Factor Authentication con Remote Desktop Gateway in Windows Server 2016

Modifica della porta utilizzata da Remote Desktop Gateway

Il Remote Desktop Gateway utilizza la porta HTTPS 443 per effettuare le connessioni. Se volete modificare questa porta potete utilizzare RD Gateway Manager e nella scheda Transport Settings inserite la porta desiderata. Prestate attenzione al fatto che il servizio verrà riavviato e che le connessioni attive verranno chiuse.

Figura 35: Modifica della porta di default utilizzata da Remote Desktop Gateway

È anche possibile operare tramite registro di sistema di Windows (ringrazio Federico Filiberti per la super dritta!) modificando la chiave di registro:

 

Figura 36: Modifica della porta di default utilizzata da Remote Desktop Gateway utilizzando il registro di Windows

Conclusioni

Il Remote Desktop Gateway è un ruolo molto importante dei Remote Desktop Services che permette l’accesso alle nostre applicazioni aziendali attraverso Internet. È possibile accedere ai desktop remoti e alle RemoteApp semplicemente utilizzando un unico server ed un’unica porta di connessione esposti ad Internet, con un vantaggio enorme in termini di configurazione e soprattutto con la sicurezza che le nostre connessioni saranno sempre cifrate. Davvero un bel vantaggio!