Archivi categoria: remote desktop services

Joinare computer Windows 10 ad Azure AD ed effettuare connessioni in RDP

Facebooktwittergoogle_plusredditlinkedin

Dalla versione di Windows 10 Anniversary Update (Professional oppure Enterprise) è possibile aggiungere il sistema operativo client di casa Microsoft ad Azure Active Directory (Azure AD), la directory basata sul cloud multi-tenant usata come servizio di gestione delle identità, che combina i servizi di directory, la gestione dell’accesso delle applicazioni e la protezione delle identità in un’unica soluzione.

Per avere un’idea dei possibili vantaggi e degli scenari di utilizzo di un computer Windows 10 joinato ad Azure AD vi consiglio di leggere prima l’articolo Usage scenarios and deployment considerations for Azure AD Join

In ogni caso potete joinare ad Azure AD solo un computer in Workgroup. Se avete un computer già joinato al dominio locale e volete approfittare delle funzionalità di Single Sign-On, potete invece Connettere un computer in dominio ad Azure AD (Workplace Join). Si tratta quindi di due funzionalità completamente diverse. Per completezza vi inserisco una tabella che riassume le differenze:

Figura 1: tabella riassuntiva delle differenze di funzionalità tra Azure AD Join e Workplace Join

In questo articolo mi occuperò solo di Azure AD Join

Gli utenti possono joinare i propri dispositivi Windows 10 sia durante la first-run experience, il momento in cui si accende il dispositivo per la prima volta ed è necessario inserire le prime informazioni per completare l’installazione, sia dall’app Settings, dove si può decidere se connettere il sistema operativo ad Azure AD oppure joinarlo. Se joinate Windows 10 ad Azure AD potete utilizzare le credenziali di Azure AD per potervi loggare al PC ed utilizzare la funzionalità di Single Sign-On (SSO) quando accedete alle applicazioni SaaS basate sul cloud ed ad Office 365.

È anche possibile impedire agli utenti ed ai gruppi creati in Azure AD la possibilità di joinare i propri dispositivi o limitarne il numero, oltre a forzare l’uso della multi-factor authentication. Dopo che un utente ha joinato il proprio dispositivo in Azure AD è possibile controllarne il comportamento, è possibile cancellarlo, bloccarlo oppure gestirlo con un software di Mobile Device Management (come Microsoft Intune).

Se decidete di joinare Windows 10 durante la first-run experience, i passaggi da seguire cambiano in base alla release di Windows 10 che state utilizzando e sono descritti nell’articolo Aggiungere un nuovo dispositivo Windows 10 con Azure AD in fase di completamento dell’installazione. In sintesi, i passaggi da effettuare sono i seguenti:

  1. Quando si accende il nuovo dispositivo e viene avviato il processo di installazione, viene visualizzato il messaggio Preparazione . Seguite le istruzioni per configurare il dispositivo.
  2. Iniziate personalizzando il paese e la lingua. Quindi accettate le Condizioni di licenza software Microsoft.
  3. Selezionate la rete che desiderate usare per la connessione a Internet.
  4. Fate clic su Questo dispositivo appartiene all’organizzazione.
  5. Immettete le credenziali di Azure AD e quindi fate clic su Accedi.
  6. Il dispositivo individua un tenant in Azure AD. Se si è in un dominio federato, si verrà reindirizzati al server del servizio token di sicurezza locale, ad esempio Active Directory Federation Services (AD FS). Se si è in un dominio non federato, immettete le credenziali direttamente nella pagina ospitata da Azure AD.
  7. Vi viene richiesto di effettuare l’autenticazione a più fattori (non obbligatoria).
  8. Windows registra il dispositivo nella directory dell’organizzazione in Azure AD

Nel mio caso invece, ho deciso di joinare ad Azure AD una macchina virtuale con Windows 10 Professional che ho creato nel Cloud Azure. Non potendo accedere alla schermata della first-run experience, mi sono prima loggato a Windows 10 con le credenziali amministrative in mio possesso e successivamente ho lanciato l’applicazione Settings, che mi permette di gestire gli Accounts. Dalla funzionalità Access Work or School ho cliccato su Connect e poi sul link Join this device to Azure Active Directory, come mostrato in figura:

Figura 2: Schermata iniziale per l’aggiunta di un computer Windows 10 ad Azure AD

Nella schermata successiva ho inserito le credenziali di un utente di Azure AD (non serve che sia un utente privilegiato nel vostro tenant di Azure, può essere un utente qualsiasi).

Figura 3: Inserimento delle credenziali dell’utente a cui associare il dispositivo Windows 10

Figura 4: Inserimento password

Figura 5: L’account che ho usato utilizza la multi-factor authentication (non obbligatoria)

Dopo aver inserito le credenziali, un avviso vi dirà che l’account di Azure AD verrà aggiunto al gruppo Administrators locali della macchina Windows 10 e che alcune policy potrebbero essere applicate alla macchina.

Figura 6: Avviso riguardo l’applicazione di policy sulla macchina Windows 10 dopo il join ad Azure AD

Figura 7: Conferma dell’avvenuto join ad Azure AD

Nella scheda Access work or School adesso appare l’utente che avete utilizzato, a fianco del simbolo di una borsa di lavoro.

Figura 8: Informazioni sull’utente connesso

Se accedete al Pannello di controllo e verificate i membri del gruppo Administrators, vedrete che è stato aggiunto un account con il nome AzureAD\NicolaFerrini, come mostrato in figura.

Figura 9: L’utente di Azure AD è stato aggiunto al gruppo Administrators

Dal portale di Azure è anche possibile verificare in Azure Active Directory che un nuovo dispositivo è stato aggiunto alla directory dove si trova l’utente che avete utilizzato per joinare Windows 10.

Figura 10: Il nuovo dispositivo Windows 10 aggiunto ad Azure AD

Cliccando sul dispositivo sarà possibile ricevere maggiori informazioni, sarà possibile disabilitarlo o anche rimuoverlo.

Figura 11: Proprietà del dispositivo aggiunto ad Azure AD

Connessione in RDP ad un computer joinato ad Azure AD

Per testare la funzionalità di Single Sign-On (SSO) è necessario loggarsi al computer con le credenziali di Azure AD (in genere AzureAD\NomeCognome). Nel mio caso però, poiché la macchina è ospitata su Azure, non ho la possibilità di connettermi in console e devo necessariamente farlo in Desktop Remoto (RDP). Ho quindi fatto logoff con l’utente che stavo utilizzando e ho provato a loggarmi con le credenziali di Azure AD. Infatti l’utente di Azure AD fa parte del gruppo Administrators locali della macchina, che possono accedere di default in RDP. Dopo aver inserito username e password invece ho ottenuto il seguente errore:

Figura 12: Connessione in RDP alla macchina Windows 10 utilizzando le credenziali di Azure AD

Figura 13: Errore di login in RDP usando le credenziali dell’utente di Azure AD

L’accesso in RDP alle macchine Windows 10 è possibile a partire da Windows 10 versione 1607. Entrambi i PC (locale e remoto) devono eseguire Windows 10 versione 1607 o versioni successive. È necessario però che il  Remote Credential Guard, una nuova funzionalità di Windows 10 versione 1607, sia disattivata nel PC client che utilizzate per connettervi al PC remoto.

Ovviamente è un’opzione che NON consiglio, visto che poi esporrebbe il vostro client alla perdita di credenziali per tutte le connessioni RDP e ad attacchi di tipo Pass The Hash.

In alternativa è possibile effettuare queste operazioni:

  • Disabilitare nel computer remoto Windows 10 joinato ad Azure AD la Network Level Authentication
  • Modificare il file .RDP utilizzato per la connessione aggiungendo i valori:
    • enablecredsspsupport:i:0
    • authentication level:i:2

Per disabilitare la Network Level Authentication vi basta andare nel Pannello di controllo e dalle proprietà del Sistema, utilizzate il tab Remote per rimuovere il segno di spunta dalla abilitazione della Network Level Authentication come mostrato in figura:

Figura 14: Disabilitazione della Network Level Authentication

Per modificare il file .RDP vi basta aprirlo con Notepad++ (o con un altro editor di testo a vostra scelta) e aggiungere le due righe sopra indicate, come mostrato in figura:

Figura 15: Modifica del file .RDP

A questo punto, se lanciate la connessione remota utilizzando il file .RDP modificato, il processo di autenticazione sarà diverso. Prima vi apparirà il messaggio di errore del certificato presentato dal client Windows 10 e successivamente vi verrà chiesto di inserire le credenziali di Azure AD

Figura 16: Connessione al computer remoto effettuata

Figura 17: Inserimento delle credenziali di Azure AD

Nonostante l’utente utilizzando abbia la Multi-factor authentication abilitata, per le connessioni RDP non verrà richiesta.

Figura 18: Verifica dell’utente connesso in RDP

Adesso che l’utente è connesso con il suo account di Azure AD potrà approfittare della funzionalità di Single Sign-On (SSO) per loggarsi al portale di Azure o al portale di Office 365, senza che gli vengano chieste le credenziali di autenticazione, utilizzando il browser Edge. Altri browser alternativi, come Google Chrome o Mozilla Firefox non sono compatibili con l’SSO.

Figura 19: L’accesso al portale di Office 365 con l’account di Azure AD e con il browser Edge non richiede l’inserimento delle credenziali di accesso

Conclusioni

Numerosi sono i motivi per cui potrebbe essere utile joinare un computer ad Azure AD. Tra i tanti, è possibile configurare utenti e dipendenti in modo che usino i dispositivi Windows personali (BYOD, Bring Your Own Device) per accedere alle App e alle risorse aziendali (applicazioni SaaS). Gli utenti possono aggiungere i propri account Azure AD (account aziendali o account scolastici) a un dispositivo personale Windows per accedere alle risorse ed alle applicazioni in totale sicurezza e conformità. I dispositivi possono anche essere assoggettati ad alcune policy di sicurezza e possono essere gestiti da remoto con software di Mobile Device Management. Rimane a mio avviso ancora difficile e poco sicuro connettersi in RDP a questi dispositivi e spero che ben presto venga innalzato il livello di sicurezza e non sia necessario effettuare dei workaround.

Buon lavoro!

Nic

Impossibile connettersi via RDP a macchine on-premises o alle Azure Virtual Machine: Errore CredSSP Encryption Oracle Remediation

Facebooktwittergoogle_plusredditlinkedin

A partire dall’ 8 Maggio 2018, a seguito del rilascio da parte di Microsoft degli aggiornamenti mensili ed in particolar modo della KB4103727, diversi utenti stanno ricevendo una serie di errori nei collegamenti RDP dovuti alla CredSSP Encryption Oracle Remediation.

Le connessioni Desktop remoto (RDP) sono infatti soggette ad una vulnerabilità di “Remote Code Execution” che è stata descritta nella CVE-2018-0886. Già dal 18 Marzo 2018 Microsoft aveva rilasciato una patch per poter gestire questa vulnerabilità e aveva introdotto una Group Policy per mitigarne i rischi. Se volete conoscere l’evoluzione degli aggiornamenti per questa vulnerabilità potete leggere l’articolo CredSSP updates for CVE-2018-0886

Con le patch contenute nel Cumulative Update di Maggio 2018, la Group Policy è stata modificata ed il valore è passato da Vulnerable Mitigated. Il parametro lo trovate in Computer Configuration -> Administrative Templates -> System -> Credentials Delegation

Questa modifica al parametro della Group Policy obbliga la connessione RDP ad essere instaurata solo se dall’altra parte risponde una macchina che abbia ricevuto l’aggiornamento della KB4103727

Per maggiori informazioni sui diversi valori che il parametro può avere potete fare riferimento all’articolo https://support.microsoft.com/en-us/help/4093492/credssp-updates-for-cve-2018-0886-march-13-2018

Figura 1: Policy utilizzata per la gestione della vulnerabilità di CredSSP Encryption

Per verificare che abbiate installato la KB “incriminata” (KB4103727) potete lanciare un prompt di PowerShell con privilegi elevati ed eseguire il comando Get-Hotfix

Figura 2: Aggiornamenti installati sul sistema operativo client

Problema

Sul mio client Windows 10 ho installato la KB4103727 e quando ho tentato di connettermi ad una macchina dove la patch non era installata ho ricevuto il seguente messaggio di errore:

Figura 3: Impossibile collegarvi via RDP su una macchina non aggiornata

Anche controllando il Registro Eventi l’errore appare chiaro:

Figura 4: Errore nel Registro Eventi relativo al fallimento della negoziazione sicura della connessione

Il comportamento delle macchine può essere riassunto in questo modo:

  • se sia il client che la VM o il PC hanno la patch, la connessione avverrà in maniera sicura
  • se il client ha la patch ma la VM o il PC non ce l’hanno, apparirà un messaggio di errore e non sarà possibile connettersi
  • se il client non ha la patch ma la VM o il PC ce l’hanno, sarà possibile collegarsi via RDP ma la connessione non sarà sicura

Soluzione

Per ovviare al problema è possibile modificare la Policy che vi ho indicato prima (mettendo il valore su Vulnerable) o disinstallare la KB4103727 oppure modificare il registro utilizzando il comando

REG ADD HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters\ /v AllowEncryptionOracle /t REG_DWORD /d 2

Io sconsiglio queste soluzioni. La cosa migliore da fare è aggiornare tutte le VM ed i PC installando gli aggiornamenti di sicurezza consigliati. Per aggiornare un PC o una VM potete utilizzare Windows Update oppure un server WSUS.

Figura 5: Aggiornamenti di Maggio 2018 su Windows Server 2016

Figura 6: Aggiornamenti di Maggio 2018 su Windows 10

Connessione ad una VM in Microsoft Azure e installazione della patch mancante

Se tentate di connettervi ad una VM in Azure in cui non avete installato la patch KB4103727, allora ricevete l’errore descritto prima e sarà necessario aggiornarla o mitigare la vulnerabilità.

Nel mio caso però la VM non è in dominio e non ho la possibilità di accedervi in console. Per installare la patch mi sono servito della funzionalità di Azure Update Management, una soluzione che vi permette di eseguire gli aggiornamenti per le macchine Windows e per le macchine Linux direttamente dal portale di Azure e tramite un Automation Account.

Figura 7: Abilitazione della soluzione Azure Update Management

Il principio di funzionamento di Azure Update Management è molto semplice e può essere riassunto dal seguente diagramma:

Figura 8: Principio di funzionamento di Azure Update Management

Tipi di client supportati:

La tabella seguente elenca i sistemi operativi supportati:

Sistema operativo Note
Windows Server 2008, Windows Server 2008 R2 RTM Supporta solo le valutazioni degli aggiornamenti
Windows Server 2008 R2 SP1 e versioni successive Sono richiesti .NET Framework 4.5 e WMF 5.0 o versioni successive per Windows Server 2008 R2 SP1
CentOS 6 (x86/x64) e 7 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
Red Hat Enterprise 6 (x86/x64) e 7 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
SUSE Linux Enterprise Server 11 (x86/x64) e 12 (x64) Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.
Ubuntu 12.04 LTS e versioni x86/x64 più recenti Gli agenti Linux devono avere accesso a un repository degli aggiornamenti.

Dopo pochissimi minuti dall’abilitazione della soluzione, la macchina verrà testata e verranno mostrati gli aggiornamenti mancanti. Come è possibile vedere dalla figura, manca il Security Update KB4103723

Figura 9: Aggiornamenti mancanti sulla VM

Fate clic sul pulsante Schedule update deployment che vi appare nel blade del portale di Azure e programmate quando volete effettuare l’aggiornamento. L’aggiornamento non è programmabile prima di 30 minuti e potete scegliere di eliminare alcune patch dall’installazione.

Figura 10: Programmazione dell’aggiornamento della VM

Una volta che avete schedulato l’aggiornamento non vi resta che attendere. La programmazione sarà visibile cliccando su Scheduled update deployment, come mostrato in figura:

Figura 11: Aggiornamenti programmati

Conclusioni

Avere le macchine sempre aggiornate e lavorare con sistemi operativi sicuri è un prerequisito importante per non essere soggetti alle vulnerabilità dei software e dei sistemi operativi e non perdere i propri dati. Prima di aggiornare però assicuratevi di fare dei test sulla vostra infrastruttura e verificate che tutto continui a funzionare prima di distribuire in maniera massiva gli aggiornamenti.

Buon lavoro!

Nic

Utilizzare la Azure Multi-Factor Authentication con Remote Desktop Gateway in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

Come avete visto nella guida Configurare Remote Desktop Gateway in Windows Server 2016, l’accesso da Internet alle risorse aziendali, alle RemoteApp e al desktop remoto dei server è enormemente semplificato dall’installazione del Remote Desktop Gateway. RD Gateway inoltre 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.

Ma poiché la sicurezza non è mai troppa, poiché gli utenti possono salvare le credenziali di connessione e perdere i dispositivi da cui si connettono, poiché dobbiamo difendere le nostre risorse aziendali, in questa guida vi illustrerò come implementare la Multi-Factor Authenticazion con il Remote Desktop Gateway.

Utilizzando infatti 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…)

La procedura di autenticazione sarà quindi:

  1. L’utente si collega al portale web delle RemoteApp e inserisce le proprie credenziali
  2. L’utente fa doppio clic sull’icona dell’applicazione per lanciare la RemoteApp
  3. Se è stato abilitato il Web SSO sul Remote Desktop Web Access non verrà chieste all’utente di reinserire le credenziali di accesso alla RemoteApp
  4. L’utente riceve una telefonata oppure un SMS o una one-time password dal suo token (secondo fattore di autenticazione)
  5. L’utente è autenticato e la RemoteApp si apre

Come funziona la Multifactor Authentication (MFA) con il Remote Desktop Gateway

Il Remote Desktop Gateway utilizza un server NPS (Network Policy Services) per poter autenticare ed autorizzare gli accessi. Il servizio NPS è installato quando installate il ruolo RD Gateway e dovete creare una Remote Desktop Connection Authorization Policy (RD CAP) ed una Remote Desktop Connection Authorization Policy (RD CAP) per permettere agli utenti di potersi loggare e accedere alla rete interna.

Il processo di autenticazione infatti funziona in questo modo:

  1. Le credenziali dell’utente vengono inviate al RD Gateway
  2. Il server NPS installato sull’RD Gateway controlla le credenziali e verifica se l’utente è abilitato ad entrare controllando le Remote Desktop Connection Authorization Policy (RD CAP)
  3. Se le credenziali sono valide, il server RD Gateway controlla le Remote Desktop Connection Authorization Policy (RD CAP) per capire verso quali risorse della rete interna permettere l’accesso all’utente

Se invece aggiungete un Multi-Factor Authentication Server (MFA) il processo di autenticazione sarà diverso e seguirà queste fasi:

  1. Le credenziali dell’utente vengono inviate al RD Gateway
  2. Il server NPS controlla le credenziali e vede se l’utente è abilitato ad entrare controllando le Remote Desktop Connection Authorization Policy (RD CAP)
  3. Se le credenziali sono valide, il server NPS invia la richiesta di login al server MFA
  4. Il server MFA invia un sms o telefona all’utente (dipende da come avete deciso di impostare voi il controllo)
  5. Il server MFA riceve dall’utente la risposta (ad esempio il PIN corretto)
  6. Il server MFA comunica al server NPS che l’utente può/non può accedere
  7. Il server RD Gateway controlla Remote Desktop Connection Authorization Policy (RD CAP) per capire verso quali risorse della rete interna permettere l’accesso all’utente

Figura 1: Sequenza dell’autenticazione effettuata tramite un Multi-Factor Authentication Server (MFA)

In questa guida utilizzerò il Microsoft Azure Multi-Factor Authentication Server (MFA) installato nella infrastruttura aziendale, quindi on-premises. Sul server MFA ho installato Windows Server 2016 e l’ho aggiunto al mio dominio demo.lab.

Prerequisiti

I prerequisiti per implementare la Multi-Factor Authentication con il Remote Desktop Gateway sono:

Installazione del server Microsoft Azure Multi-Factor Authentication Server (MFA)

Per quanti di voi non avessero dimestichezza sul funzionamento della Multi-Factor Authentication e su quale tipo di autenticazione utilizzare (Server MFA on-premises, server MFA nel Cloud) consiglio di leggere l’articolo Choose the Azure Multi-Factor Authentication solution for you.

Loggatevi al portale di Microsoft Azure e selezionate Azure Active Directory e successivamente MFA Server. Dalla scheda Overview lanciate la versione di prova di Azure Active Directory Premium che vi permetterà di utilizzare la Multi-Factor Authentication, come mostrato in figura. Azure Multi-Factor Authentication è disponibile come servizio da acquistare singolarmente, che offre la possibilità di fatturare per utente e per ogni autenticazione effettuata, oppure insieme ad Azure Active Directory PremiumEnterprise Mobility Suite e Enterprise Cloud Suite.

Figura 2: Attivazione della versione di prova di Azure Multi-Factor Authentication

Cliccando sul nodo Providers, dopo aver cliccato sul pulsante Add, inserite il nome di riferimento del vostro server MFA (io ho scelto RDGW-MFA), il tipo di utilizzo e di tariffazione (per utente o per singola autenticazione) e la sottoscrizione, come mostrato in figura:

Figura 3: Creazione del Provider di autenticazione

Terminata la creazione del Provider, selezionate il server RDGW-MFA creato e dal nodo Server settings efefttuate il download del software (che installerete sulla vostra macchina on-premises) e create le credenziali di attivazione del server MFA.

Figura 4: Download del software e creazione delle credenziali di attivazione del server MFA

Dopo aver scaricato il software nella macchina che volete utilizzare come server MFA (la mia si chiama mfa01.demo.lab) lanciate il setup ed installate i prerequisiti, come mostrato in figura:

Figura 5: Installazione dei prerequisiti per il server MFA

Subito dopo l’installazione dei prerequisiti si avvierà il setup del Multi-Factor Authentication Server. Procedete all’installazione seguendo le indicazioni delle figure sotto:

Figura 6: scelta della cartella in installazione del server MFA

Figura 7: Installazione del server MFA completata

Dopo l’installazione vi verrà chiesto se volete lanciare il wizard di configurazione. Mettete il segno di spunta per poterlo saltare e fate clic su Next

Figura 8: Attivazione e configurazione manuale del server MFA

Procedete quindi all’inserimento delle credenziali di attivazione che avete generato sul portale di Azure. Prestate attenzione perché le credenziali sono valide solo per 10 minuti, quindi se non dovessero funzionare ricreatele dal portale Azure.

Figura 9: attivazione del server MFA

È possibile configurare il server MFA in modo tale che utilizzi gli utenti di Active Directory. Selezionate il pulsante Users e importate gli utenti da vostro dominio, seguendo le indicazioni mostrate nella figura sotto:

Figura 10: Importazione degli utenti di Active Directory nel vostro server MFA

Dopo aver importato gli utenti, è possibile configurarli in modo tale da scegliere per ognuno di loro un metodo di autenticazione (chiamata telefonica, SMS, PIN, App per il cellulare, ecc,.) come mostrato in figura:

Figura 11: Scelta del fattore di autenticazione per ogni utente

Adesso il vostro server Azure Multi-Factor Authentication è pronto per poter essere utilizzato.

Configurazione del Remote Desktop Gateway, del server NPS e del server MFA

Il prossimo passaggio da eseguire è configurare il Remote Desktop Gateway, il NPS ed il server MFA in modo tale che possano parlare tra di loro.

Configuriamo il server RD Gateway in modo tale che usi come server di autenticazione non più il server NPS installato sulla stessa macchina, bensì il server MFA. Sarà infatti d’ora in poi il server MFA ad essere interrogato per primo quando arriva una richiesta di connessione.

Dal Server Manager del vostro RD Gateway scegliete Tools–>Remote Desktop Services–> RD Gateway Manager. Aprite le proprietà del server RDGW e dalla scheda RD CAP Store indicate come server NPS l’indirizzo IP o il nome del vostro server MFA, come mostrato in figura:

Figura 12: Modifica del server che gestirà le policy RD CAP (Connection Authorization Policy)

Figura 13: Configurazione del nuovo server NPS completata

Configuriamo ora il server NPS che è installato sul RD Gateway in modo tale che parli con il server MFA. Entrambi utilizzeranno il protocollo RADIUS per potersi scambiare i messaggi di autenticazione. Pertanto, aggiungete come RADIUS client il vostro server MFA, configurandolo come mostrato in figura, in modo tale che possa accettare le autenticazioni RADIUS dal server MFA. Ho utilizzato come Friendly Name MFA01 (ci servirà in seguito).

Figura 14: Il server MFA diventa un RADIUS client per il server NPS

Nel momento in cui avete installato il ruolo RD Gateway si è installato anche il servizio NPS e nel nodo Remote RADIUS Server è stato creato automaticamente un gruppo di server chiamato TS GATEWAY SERVER GROUP. Dalle Proprietà selezionate il server MFA e dalla scheda Authentication/Accounting modificate le porte e lo shared secret (che dovrete poi configurare sul server MFA) come mostrato in figura:

Figura 15: Modifica delle porte e dello Shared Secret

Cliccate ora sulla scheda Load Balancing e aumentate il timeout ad almeno 60 secondi, come mostrato in figura. Questo timeout è necessario per permettere all’utente di avere il tempo di rispondere alla richiesta di seconda autenticazione (telefonata, sms, ecc…).

Figura 16: Timeout di risposta del server

Configurazione delle Policy di connessione

Sarà necessario modificare due Connection Request Policy nel server NPS: una servirà a inoltrare le richieste verso il server MFA e l’altra a ricevere le richieste che tornano dal server MFA.

Figura 17: Schema di funzionamento della verifica delle Connection Request Policy

Come prima operazione duplicate la policy di default TS GATEWAY AUTHORIZATION POLICY, come mostrato in figura:

Figura 18: Duplicazione della TS GATEWAY AUTHORIZATION POLICY

Cliccate col tasto destro sulla TS GATEWAY AUTHORIZATION POLICY originale e modificatene le condizioni. Aggiungete come Client Friendly Name il nome del RADIUS client che avete scelto prima (nel mio caso MFA01)

Figura 19: Modifica delle Conditions della TS GATEWAY AUTHORIZATION POLICY originale

Continuate a modificare la stessa policy andando nella scheda Settings e modificando l’Authentication in modo tale da scegliere Authenticate requests on this server, come mostrato in figura

Figura 20: Modifica dei Settings di Authentication della TS GATEWAY AUTHORIZATION POLICY originale

Nella scheda Settings della TS GATEWAY AUTHIRIZATION POLICY originale modificate l’Accounting, rimuovendo il segno di spunta da Forward accounting requests to this remote RADIUS server group

Figura 21: Modifica dei Settings di Accounting della TS GATEWAY AUTHORIZATION POLICY originale

Il risultato finale è quello mostrato nella figura sotto. Accertatevi che questa policy sia la prima ad essere processata!

Figura 22: Modifica delle policy originale completata

Non toccate nulla della policy che avete duplicato in precedenza (copy of TS GATEWAY AUTHIRIZATION POLICY) e assicuratevi che sia ordinata come seconda. Per chiarezza ho indicato in figura il significato delle due policy

Figura 23: Configurazione delle Network policy completata

Configurazione del server Multi-Factor Authentication

È arrivato il momento di configurare Azure Multi-Factor Authentication Server in modo tale che possa parlare con il server NPS. Spostatevi quindi sulla vostra macchina MFA e selezionate il pulsante RADIUS Authentication. Abilitate con un segno si punta la voce Enable RADIUS Authentication nella scheda Clients e aggiungete l’indirizzo IP o il nome del vostro RD Gateway (che è anche il server NPS), insieme allo Shared Secret che avete aggiunto nella Central CAP Store configuration del vostro RD Gateway Manager.

Figura 24: Configurazione del server NPS come RADIUS Client

Spostatevi nella scheda Target della stessa schermata e aggiungete lo stesso server anche come RADIUS Target, come mostrato in figura:

Figura 25: Configurazione del server NPS come RADIUS Target

La configurazione del nostro ambiente è completata. Non vi resta altro che testare il suo funzionamento.

Test di funzionamento

Per testare l’efficacia della configurazione fatta, collegatevi all’infrastruttura RDS utilizzando il portale web. Inserite le credenziali di login di un utente su cui avete abilitato la Multi-Factor Authentication e accedete al portale.

Figura 26: Login al portale web con le credenziali di un utente a cui abbiamo abilitato la Multi-Factor Authentication

Dopo aver effettuato il login, cliccate su una delle RemoteApp e lanciate la connessione.

Figura 27: Login al portale web effettuato e lancio della RemoteApp

Confermate che la connessione alla RemoteApp stia avvenendo utilizzando il Remote Desktop Gateway, come mostrato in figura:

Figura 28: Connessione alla RemoteApp attraverso il Remote Desktop Gateway

Reinserite le credenziali di login del vostro utente (se non avete abilitato il web Single Sign-on nella vostra infrastruttura RDS).

Figura 29: Reinserimento delle credenziali di login dell’ utente

A questo punto la connessione remota rimane in attesa che avvenga la verifica della vostra identità utilizzando il secondo fattore di autenticazione

Figura 30: Attesa di ricevere conferma dell’avvenuta verifica dell’identità del l’utente

Riceverete una telefonata al numero che avete inserito in Active Directory o sul server MFA. Rispondete alla telefonata e quando vi verrà chiesto confermate la vostra identità premendo il simbolo # (cancelletto – pound key) sul tastierino del telefono.

Figura 31: Telefonata per conferma dell’identità dell’utente

Finalmente la vostra identità è confermata e potrete cominciare ad utilizzare la vostra RemoteApp.

Figura 32: Apertura della RemoteApp di Word 2016

È possibile modificare il metodo di autenticazione dell’utente, scegliendolo dalla lista degli utenti presente sul Multi-Factor Authentication Server e modificandolo per esempio affinché inserisca un PIN durante la telefonata (invece che la semplice conferma alla risposta con il simbolo #) oppure risponda ad un SMS, inserendo il codice ricevuto tramite SMS più il suo PIN.

Figura 33: Inserimento di un PIN durante la telefonata di conferma

Figura 34: Inserimento di un codice + PIN tramite SMS

Figura 35: L’utente per verificare la propria identità deve rispondere all’SMS con un codice ricevuto ed il suo PIN personale

Conclusioni

La Multi-Factor Authentication ci aiuta a proteggere l’accesso ai nostri dati più importanti perché, oltre alla combinazione di username e password, richiede che venga fornita un’ulteriore prova della nostra identità. Moltissimi siti offrono la possibilità di utilizzarla (Microsoft, Facebook, Twitter, LinkedIn, Facebook, Google, Paypal per citarne solo alcuni) e adesso grazie a Azure Multi-Factor Authentication Server possiamo anche implementarla on-premises per le nostre applicazioni.

Configurare Remote Desktop Gateway in Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

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.

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.

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

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!

Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016

Facebooktwittergoogle_plusredditlinkedin

I Remote Desktop Services (RDS) sono una piattaforma di session virtualization che permette agli utenti di poter accedere in desktop remoto alle applicazioni, senza che queste vengano installate sulle proprie macchine. La tecnologia esiste fin da NT 4.0 ed è sicuramente una tecnologia matura, che offre il vantaggio di poter utilizzare le applicazioni e dati indipendentemente da dove si stia effettuando la connessione. È possibile collegarsi direttamente all’intero desktop remoto (jn questo caso si parla di VDI – Virtual Desktop Infrastructure) oppure è possibile visualizzare solo l’applicazione remota (RemoteApp – Session based virtualization).

In questa guida ci occuperemo di configurare proprio le RemoteApp, applicazioni installate ed eseguite in remoto in un server terminal, che quando vengono lanciate sembra che siano eseguite sul pc dell’utente come se fossero delle applicazioni locali, migliorando di molto l’esperienza utente visto che non c’è possibilità di confondersi come quando le connessioni terminal visualizzano due desktop (uno locale del pc da cui ci si connette ed uno remoto del server terminal).

Figura 1: Ruoli e server utilizzati dai Remote Desktop Services

Per creare un RDS Session-based deployment abbiamo bisogno di installare in Windows Server 2016 i seguenti ruoli dei Remote Desktop Services:

  • Remote Desktop Session Host – è il server in cui sono installate le applicazioni che vogliamo utilizzare
  • Remote Desktop Connection Broker – è il server che si occupa di gestire le connessioni verso i Session Host e verso le RemoteApp
  • Remote Desktop Web Access – consente agli utenti di accedere alla RemoteApp tramite un portale web ed un browser
  • Remote Desktop Licensing Server – è il server che controlla che abbiate le licenze per potervi collegare (RDS CAL)
  • Remote Desktop Gateway (opzionale) – questo server utilizza il Remote Desktop Protocol (RDP) su HTTPS per stabilire una connessione sicura e crittografata tra utenti remoti in Internet e i Session Host interni alla nostra rete in cui vengono eseguiti le applicazioni

Installazione dei Remote Desktop Services

Già in Windows Server 2012 è stata migliorata molto l’installazione dei servizi necessari a creare una RDS Farm. Nella nostra guida utilizzerò un solo server (chiamato RDS01), che ho aggiunto al dominio demo.lab, che ospiterà i ruoli di Session Host, Connection Server e Web Access. È possibile installare i ruoli su server diversi, anche per poterne moltiplicare il numero ed evitare i single point of failure. Se volete maggiori informazioni su come realizzare un’infrastruttura RDS altamente disponibile vi consiglio di leggere la guida Remote Desktop Services – High availability

Sul mio server RDS01, dopo averlo aggiunto al dominio, ho lanciato il wizard per l’aggiunta dei ruoli e ho scelto Remote Desktop Services installation, come mostrato in figura:

Figura 2: Scelta dell’installazione Remote Desktop Serrvices

Nel passaggio successivo vi verrà chiesto in che modo volete configurare il vostro deployment. La scelta si può fare utilizzando la modalità Quick Start, che installa tutti i ruoli su una sola macchina, la modalità Standard, che vi permette di differenziare i ruoli su macchine diverse (utile per l’alta disponibilità) e i servizi MultiPoint, una novità di Windows Server 2016. Scegliete Standard Deployment e fate clic su Next

Figura 3: Scelta della modalità Standard per la creazione dell’infrastruttura RDS

Nel passaggio successivo dovrete scegliere se volete utilizzare delle macchine virtuali (VDI) per accedere alle vostre applicazioni o se volete utilizzare dei Terminal Server che ospiteranno le vostre RemoteApp. Scegliete Session-based desktop deployment e fate clic su Next

Figura 4: Session-based deployment

Il wizard a questo punto vi confermerà quali ruoli sono necessari per la vostra infrastruttura. Come potete notate dalla figura sotto, dovrete installare 3 ruoli: Session Host, Connection Broker e Web Access.

Figura 5: Ruoli che sono necessari alla creazione della nostra infrastruttura RDS

NOTA: Se volete distribuire i ruoli su più server è necessario aggiungerli preventivamente al Server Pool che Windows Server potrà gestire. Maggiori informazioni sono reperibili leggendo l’articolo add Servers to Server Manager

Proseguite il vostro wizard e aggiungete quindi il server RDS01 alla lista dei server su cui installare il ruolo di Connecion Broker, come mostrato in figura:

Figura 7: Scelta dei server su cui installare il ruolo di Connection Broker

Nel passaggio successivo indicate su quali server installare il ruolo di Web Access. Io ho scelto di installare il Web Access sul Connection Broker server.

Figura 8: Scelta del server su cui installare il ruolo di Web Access

Terminate il wizard scegliendo su quali server installare il ruolo di Session Host. Avendo più server collegati al Server Manager le operazioni vengono enormemente semplificate, visto che non è necessario ripeterle per ogni server che deve far parte della nostra infrastruttura RDS.

Figura 9: Aggiunta del server su cui verrà installato il ruolo di Session Host

Nella pagina di conferma vi viene segnalato che per completare l’installazione del ruolo Session Host sarà necessario il riavvio del server. Mettete un segno di spunta nella casella se volete che dopo l’installazione del ruolo il riavvio del server avvenga in automatico.

Figura 10: Schermata finale del wizard di creazione dello standard deployment RDS

Dopo qualche minuto, l’installazione dei ruoli sarà completata e il server si riavvierà. Subito dopo il riavvio, loggatevi al server RDS01 e si riaprirà in automatico il wizard, che dopo aver completato le ultime operazioni di configurazione, vi segnalerà che il deployment è terminato.

Figura 11: Completamento del deployment

Installazione delle applicazioni su server Session Host

Procedete ad installare le applicazioni sul server Session Host. Io ho deciso di distribuire Office 2016. Per installare qualsiasi applicazione su un Terminal Server è 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. Scegliete l’eseguibile dell’applicazione utilizzando il pulsante Browse e fate clic su Next.

Figura 12: Il Session Host deve esser emesso in modalità Install Mode prima di installare qualsiasi applicazione

Dopo aver terminato l’installazione dell’applicazione fate clic su Finish nella finestra del Finish Admin install, che si illuminerà da solo. Installate tutte le altre applicazioni seguendo lo stesso metodo. Nella figura è mostrato il setup di Office 2016 che sta per iniziare e la schermata del Finish Admin Install, che vi invita a cliccare il pulsante Finish
solo al termine dell’installazione.

Figura 13: Installazione dell’applicazione e Finish Admin Install

Creazione della Session Collection

Una Session Collection è un insieme di applicazioni o di desktop che volete rendere disponibili ai vostri utenti. Gran parte delle operazioni di configurazione dei servizi RDS si fanno direttamente dal Server Manager. Cliccate sul nodo relativo ai Remote Desktop Services e dalla scheda Overview cliccate su Create session collection. Si aprirà immediatamente il wizard di creazione, come mostrato in figura:

Figura 14: Creazione della Session Collection

Nella schermata successiva date un nome indicativo alla vostra Session Collection

Figura 15: Nome della Session Collection

Nel passaggio successivo dovrete indicare quali server Session Host saranno aggiunti alla Collection e a cui gli utenti si collegheranno quando vorranno utilizzare le applicazioni.

Figura 16: aggiunta dei server Session Host alla Session Collection

Specificate quali sono gli utenti o i gruppi di utenti che dovranno accedere alla Session Collection. In genere io preferisco creare dei gruppi in Active Directory che abbiano il nome dell’applicazione (in questo caso Office2016Users), in modo tale da poter concedere l’accesso alle RemoteApp semplicemente aggiungendo l’utente al gruppo autorizzato.

Figura 17: Gruppo autorizzato all’accesso della Session Collection

Nel passaggio successivo vi verrà chiesto se volete abilitare gli User Profile Disks. Gli User Profile Disks, negli scenari RDS, sono un’alternativa ai Roaming Profile e alla Folder Redirection. Il profilo dell’utente (Desktop, Documenti, Application data, ecc.) viene inserito in un disco virtuale (con estensione .VHDX) che ha il nome UVHD-SIDutente e, quando un utente si connette in sessione remota, questo disco virtuale viene agganciato al Session Host dove l’utente si collega, facendo in modo che l’utente possa accedere sempre ai propri file indipendentemente a quale Session Host si sia collegato (se ne avete più di uno nel vostro deployment).

Figura 18: Aggiunta degli User Profile Disks

Completate il wizard di creazione della Session Collection facendo clic sul pulsante Create.

Figura 19: Completamento del wizard di creazione della Session Collection

Aggiunta delle applicazioni alla Session Collection

Per poter aggiungere le applicazioni alla Session Collection e permettere ai vostri utenti di utilizzare le RemoteApp è necessario selezionare la collection dal Server Manager e cliccare, nel riquadro RemoteApp Programs su Tasks e su Publish RemoteApp Programs, come mostrato in figura:

Figura 20: Aggiunta delle RemoteApp

Il wizard di pubblicazione delle RemoteApp andrà ad interrogare uno dei Session Host che avete precedentemente aggiunto alla Collection per sapere quali applicazioni sono installate. Se avete diversi Session Host aggiunti al vostro deployment assicuratevi ovviamente che tutti abbiano le stesse applicazioni installate!

Figura 21: Scelta delle applicazioni da esporre come Remote App

Confermate la scelta delle applicazioni cliccando sul pulsate Publish.

Figura 22: Conferma della scelta delle applicazioni

Aggiunta dei certificati digitali ai Remote Desktop Services

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

Io ho provveduto a comprare un certificato digitale di tipo wildcard valido per *.nicolaferrini.it e quindi utilizzabile per qualsiasi nome host. Se volete potete utilizzare una Certification Authority interna oppure utilizzare un certificato Self-Signed (anche se lo sconsiglio).

Per aggiungere un certificato al vostro deployment spostatevi nella scheda Overview e da Tasks scegliete Edit Deployment Properties, come mostrato in figura:

Figura 23: Modifica del deployment per l’aggiunta dei certificati digitali

In Configure the deployment provvedete ad installare i certificati per i diversi ruoli del vostro deployment (Connection Broker e Web Access). La procedura è mostrata in figura.

Figura 24: Aggiunta dei certificati digitali ai diversi ruoli RDS

Figura 25: Aggiunta dei certificati digitali completata

A questo punto il deployment è terminato. Siete pronti per verificarne il funzionamento.

Connessione alle RemoteApp della Session Collection

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 26: Connessione al Web Access

Dopo aver inserito le credenziali vi appariranno le icone delle applicazioni (RemoteApp) che avete deciso di aggiungere alla vostra Session Collection. Cliccate su una delle icone per aprire la connessione verso il Session Host e lanciare il programma.

Figura 27: RemoteApp disponibili per la connessione

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.

Figura 28: Avviso sull’attendibilità del Publisher dell’applicazione

Reinserite le credenziali di accesso alla RemoteApp e finalmente vi si aprirà una finestra con l’applicazione che avete lanciato.

Figura 29: Inserimento delle credenziali di accesso all’applicazione

Sulla barra delle applicazioni sarà visibile l’icona di Word 2016 con il simbolo dell’RDP e la finestra di Word sarà ridimensionabile e riducibile ad icona, come se l’applicazione fosse installata localmente. In realtà l’applicazione è eseguita in remoto sul Session Host.

Figura 30: La RemoteApp viene aperta ed è possibile lavorarci

Subito dopo la connessione viene anche visualizzato un popup che vi avvisa a quale computer siete connessi. Da questo momento in poi potete lanciare tutte le applicazioni che volete, anche più volte la stessa applicazione. Se volete disconnettervi da Remote Desktop Session Host è possibile cliccare col tasto destro sull’icona nella barra delle applicazioni e scegliere una delle opzioni, come mostrato in figura:

Figura 31: Disconnessione dal Remote Desktop Session Host

Se avete deciso di usare gli User Profile Disks potete anche visualizzare cosa è stato creato nella cartella condivisa dove avete deciso di posizionarli, come mostrato in figura:

Figura 32: User Profile Disks creati dopo le connessioni al Session Host

Invece di utilizzare un browser, per poter accedere alle RemoteApp è anche possibile far apparire l’elenco delle applicazioni direttamente nel menù avvio di Windows. Collegatevi al Pannello di Controllo del vostro client e cliccate sull’icona RemoteApp and Desktop Connections.

Figura 33: Aggiunta delle RemoteApp al menù avvio di Windows

Nel wizard di configurazione inserite l’indirizzo del vostro server Web Access, formattandolo come richiesto.

Figura 34: indirizzo del Web Access da contattare

Dopo la richiesta di autenticazione, che va fatta solo la prima volta, vi verrà mostrato il numero di applicazioni che siete abilitati ad eseguire.

Figura 35: Connessione al Web Access completata

Da questo momento in poi le applicazioni potranno essere lanciate direttamente dal menu avvio di Windows.

Figura 36: RemoteApp presenti nel menù avvio di Windows

Conclusioni

Le RemoteApp fanno in modo che i programmi a cui si accede in remoto tramite i Remote Desktop Services vengano visualizzati come se venissero eseguiti nel computer locale dell’utente. Questo offre un’esperienza utente notevole e facilita l’interazione con le applicazioni remote. La RemoteApp ha una finestra ridimensionabile, può essere spostata su più monitor e ha una propria icona sulla barra delle applicazioni. Davvero utile!