Pubblicare Remote Desktop Services e RemoteApp utilizzando Azure AD Application Proxy
Nell’attuale ambiente di lavoro digitale gli utenti lavorano ovunque con più dispositivi e app. L’unica costante è l’identità utente. La protezione degli accessi è un fattore determinante per poter preservare le nostre informazioni e per poter essere sicuri che non siano accessibili da persone non autorizzate. Azure Active Directory da molto tempo ci offre la possibilità di accedere in maniera sicura alle risorse Cloud, utilizzando l’autenticazione a due fattori (multi-factor authentication) e la nuovissima autenticazione passwordless.
In più è anche possibile pubblicare applicazioni aziendali con Azure Active Directory Application Proxy, un servizio che si lega in modo stretto con Azure Active Directory e che in maniera concettualmente del tutto nuova permette in modo semplice la fruizione delle applicazioni ad utenti esterni all’azienda. Dopo aver effettuato l’accesso ad Azure AD, gli utenti possono accedere sia alle applicazioni nel cloud che a quelle locali tramite un URL esterno.
In questo articolo vi voglio mostrare come pubblicare i servizi di Desktop remoto utilizzando Azure Active Directory Application Proxy, senza che sia necessario aprire alcuna porta in ingresso sul firewall della nostra infrastruttura e utilizzando l’autenticazione di Azure Active Directory.
Le distribuzioni standard di Remote Desktop Services richiedono connessioni in ingresso aperte, mentre la distribuzione di questi servizi tramite Azure AD Application Proxy crea una connessione in uscita permanente dal server che esegue il servizio Azure Active Directory Application Proxy connector. In questo modo è possibile ridurre la superficie di attacco ed è possibile utilizzare anche l’accesso condizionale e l’autenticazione a due fattori.
Il diagramma seguente illustra in generale come i servizi di autenticazione di Azure AD interagiscono con Application Proxy per offrire agli utenti finali l’accesso Single Sign-On alle applicazioni locali.
Figura 1: Funzionamento di Azure AD Application Proxy
Azure AD Application Proxy è stato progettato come alternativa a una soluzione con VPN o proxy inverso (reverse proxy) per gli utenti mobili o remoti che devono accedere alle risorse interne dell’azienda. Non è destinato agli utenti interni alla rete aziendale. Il servizio consente di pubblicare un endpoint pubblicato nel cloud di Azure, che si connette all’URL di un server applicazioni all’interno dell’organizzazione.
Prerequisiti
Per poter realizzare l’accesso ai Remote Desktop Services utilizzando Azure AD Application Proxy è necessario avere:
- Active Directory interna
- Servizi di desktop remoto interni
- Certificati digitali pubblici
- Sincronizzazione degli utenti con Azure AD
- Azure AD Application Proxy Connector
Darò per scontato che abbiate già creato un’infrastruttura basata sui Remote Desktop Services e che abbiate anche delle Remote App. Potete seguire la mia guida Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016 e Windows Server 2019
Eventualmente potete fare riferimento alla pagina ufficiale https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-deploy-infrastructure
In più è necessario che abbiate distribuito Azure Active Directory Application Proxy connector, come spiegato alla pagina https://docs.microsoft.com/it-it/azure/active-directory/manage-apps/application-proxy
NOTA: La configurazione presentata è valida solo se avrete installato il Remote Desktop Gateway ed il Remote Desktop Web Access sulla stessa macchina!
Nella mia infrastruttura è stato realizzato un dominio interno chiamato home.nicolaferrini.com e ho installato i servizi di desktop remoto su una macchina chiamata rds.home.nicolaferrini.com
Figura 2: Infrastruttura realizzata
Configurazione dell’applicazione necessaria all’accesso al portale di Remote Desktop Web Access
Per utilizzare la funzionalità di Azure AD Application Proxy è necessario creare una Azure enterprise application per pubblicare il Portale RDS. Create una nuova applicazione da Azure Active Directory > Enterprise Applications > Add an Application > On-Premises application
L’applicazione va configurata con i seguenti parametri:
- Internal URL: URL interno da cui è raggiungibile il portale (nel mio caso è https://rds.home.nicolaferrini.com/rdweb/ , poiché il server RDS è joinato il dominio interno home.nicolaferrini.com)
- External URL: URL pubblico da cui sarà raggiungibile il portale (nel mio caso è https://portalerds.nicolaferrini.com/rdweb/)
Pre Authentication : Azure Active Directory - Translate URLs In Headers: No
Quando si pubblicano i Remote Desktop Services è consigliabile usare lo stesso FQDN interno ed esterno. Se gli FQDN interni ed esterni sono diversi è necessario disabilitare il Translate URLs In Headers per evitare che il client riceva collegamenti non validi.
Figura 3: Creazione di una Enterprise Application in Azure AD per l’accesso al Remote Desktop Web Access portal
Poichè ho utilizzato un nome DNS pubblico, diverso dal dominio msappproxy.net che mi è stato proposto, ho creato il records CNAME come suggerito nella schermata e ho caricato un certificato digitale pubblico per il nome portalerds.nicolaferrini.com . Per generare il certificato (per comodità l’ho creato wildcard) mi sono servito della certification authoritty gratuita Let’S Encrypt, di cui abbiamo avuto modo di parlare in numerosi articoli apparsi su questo sito.
Figura 4: Configurazione del certificato per il nome di dominio personalizzato
Aggiungete all’applicazione gli utenti a cui volete concere l’accesso alla portale RDS.
Figura 5: Aggiunta degli utenti a cui è concesso l’accesso al Portale RDS
Configurazione dell’applicazione necessaria all’utilizzo del Remote Desktop Gateway
Per accedere alle applicazioni utilizzando il Remote Desktop gateway è necessario creare una ulteriore enterprise application. Create una nuova applicazione da Azure Active Directory > Enterprise Applications > Add an Application > On-Premises application
L’applicazione va configurata con i seguenti parametri:
- Internal URL: ULR interno da cui è raggiungibile il server Remote Desktop Gateway (nel mio caso è https://rds.home.nicolaferrini.com/ , poiché il server RDS è joinato il dominio interno home.nicolaferrini.com)
- External URL: URL pubblico da cui sarà raggiungibile il portale (nel mio caso è https://rdsgateway.nicolaferrini.com/)
- Pre Authentication : Passthrough
- Translate URLs In Headers: No
Figura 6: Creazione di una Enterprise Application in Azure AD per l’utilizzo del Remote Desktop Gateway
Ricordatevi anche in questo caso di caricare il certificato corretto, che punti al nome pubblico che avere scelto per il Remote Desktop Gateway.
Aggiungete all’applicazione gli utenti a cui deve essere consentito l’accesso.
Figura 7: Aggiunta degli utenti all’applicazione RDS Gateway
A questo punto è necessario configurare la vostra infrastruttura interna per poter utilizzare l’indirizzo che avete scelto per la Azure AD Enterprise Application come server Remote Desktop Gateway. Dal Server Manager > Remote Desktop Services > Overview cliccate su Edit Deployment e modificate l’indirizzo del Remote Desktop Gateway (nel mio caso rdgateway.nicolaferrini.com). Assicuratevi di utilizzare la Password Authentication e lasciate il segno di spunta su Use RD Gateway Credentials for remote computer, come mostrato in figura:
Figura 8: Configurazione dei Remote Desktop Services per l’utilizzo del Remote Desktop Gateway corretto
Configurazione del Single Sign-On
Per configurare il Single Sign-On e fare in modo che gli utenti accedano al Portale RDS utilizzando le loro credenziali di Azure AD è necessario andare nell’app che avere configurato per accedere al portale RDS e dal nodo Single sign-on scegliere Windows Integrated Authentication
Figura 9: Configurazione del Single sign-on con la Windows Integrated Authentication
Configurate i due parametri richiesti inserendo:
- Internal Application SPN: http/rds.home.nicolaferrini.com (utilizzate il nome interno del vostro server)
- Delegated Login Identity: User Principal Name
Attenzione all’inserimento del Service Principal name (SPN) che deve essere nella forma Protocollo/nomeserver
Figura 10: Configurazione della Integrated Windows Authentication (IWA)
Sul server RDS è necessario creare il Service Principal Name che Kerberos utilizzerà per l’autenticazione e che ci permetterà di effettuare il Single Sign-On.
Lanciate sul server RDS il comando:
1 |
setspn -s http/rds.home.nicolaferrini.com rds |
Figura 11: Creazione del Service Principal Name per il server RDS
Sul Domain Controlelr sarà invece necessario configurare la Client Impersonation and Delegation, che permetterà all’Azure AD Application Proxy di potersi autenticare con le credenziali fornite dall’utenet
Sul DC lanciate i comandi:
1 2 3 4 5 6 7 |
#Configurazione SPN per il server RDS $ImpersonatingAccount = Get-ADComputer -Identity “serverrds” Set-ADComputer “rds” -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount #Configurazione SPN per l'AppProxyConnectorServer $ImpersonatingAccount = Get-ADComputer -Identity “AppProxyConnectorServer” Set-ADComputer “rds” -PrincipalsAllowedToDelegateToAccount $ImpersonatingAccount |
Nel mio caso coincidono il server RDS e l’Azure AD Application Proxy coincidono perchè ho installato l’AppProxyConnectorServer sul server RDS/RG
Figura 12: Client Impersonation and Delegation
Configurazione della Integrated Windows Authentication per il server RDS
Per permettere al Remote Desktop Web Access di poter utilizzare la Integrated Windows Authentication è necessario effettuare delle modifiche al file web.config e alla pagina web default.aspx
Modificate il file web.config che trovate in C:\Windows\Web\RDWeb\Pages rimuovendo il commento (simboli <!— e –>) dalla parte relativa a <authentication mode=”Windows”/> e aggiungetelo alla parte <authentication mode=”Forms”>
Il risultato sarà:
1 2 3 4 5 6 7 8 |
<authentication mode="Windows"/> <!-- <authentication mode="Forms"> <forms loginUrl="default.aspx" name="TSWAAuthHttpOnlyCookie" protection="All" requireSSL="true" /> </authentication> --> |
Figura 13: Modifica del file web.config sul Remote Desktop Web Access server
Modificate anche la parte relativa al <modules runAllManagedModulesForAllRequests=”true”> in questo modo:
1 2 3 4 5 6 7 8 9 10 11 12 13 |
<!-- <modules runAllManagedModulesForAllRequests="true"> <remove name="FormsAuthentication" /> <add name="RDWAFormsAuthenticationModule" type="Microsoft.TerminalServices.Publishing.Portal.FormAuthentication.TSDomainFormsAuthentication" /> </modules> <security> <authentication> <windowsAuthentication enabled="false" /> <anonymousAuthentication enabled="true" /> </authentication> </security> --> |
Figura 14: Modifica del modulo <modules runAllManagedModulesForAllRequests=”true”> in web.config
Nel percorso C:\Windows\Web\RDWeb\Pages\en-US\ modificate il file default.aspx modificando il valore del parametro bPrivateMode da false a true
1 |
public bool bShowPublicCheckBox = false, bPrivateMode = true, bRTL = false; |
Figura 15: Modifica della pagina default.aspx del Remote Desktop Web Access
Verifica di funzionamento
Collegandosi all’URL pubblico dell’applicazione di Azure AD che avete creato (nel mio caso https://portalerds.nicolaferrini.com/RDWeb/) vi verrà chiesto di autenticarvi con le vostre credenziali di Azure AD. Se avrete abilitato la multi-factor authentication per il vostro account oppure avete abilitato la passwordless authentication, l’accesso sarà molto più sicuro. Nelle immagini sotto sono mostrate le schermate di accesso dell’utente.
Figura 16: Effettuando l’accesso alla propria applicazione si viene reindirizzati verso la pagina di logi dei Azure AD
Figura 17: Utilizzo della passwordless authentication per l’accesso ad Azure AD
Dopo aver effettuato il login vi verrà mostrato il portale interno dei Remote Desktop Services. In questo modo avrete effettuato il Single Sign-on alla vostra applicazione interna utilizzando le credenziali di Azure AD.
Figura 18: Portale dei Remote Desktop Services
Figura 19: Lancio dell’applicazione Word tramite Remote Desktop Services
Figura 20: Inserimento delle credenziali di autenticazione all’applicazione
Figura 21: Certificato presentato dal Remote Desktop Session Host
Figura 22: L’applicazione Word viene eseguita
Conclusioni
Il modo di lavorare e gli strumenti di lavoro sono in rapida evoluzione. Poiché sempre più dipendenti portano i propri dispositivi al lavoro e fanno ampio uso di applicazioni SaaS (Software as a Service), anche il modo in cui le organizzazioni gestiscono e proteggono i propri dati deve evolversi. Grazie ad Azure AD Application Proxy possiamo pubblicare app locali all’esterno della nostra azienda, senza i costi associati alla gestione di una VPN tradizionale o di altre soluzioni per la pubblicazione di applicazioni web. In più possiamo sfruttare la maggiore sicurezza offerta dall’autenticazione di Azure AD, grazie alla multi-factor authentication e alla passwordless authentication, con in più l’accesso single sign-on alle applicazioni cloud e alle applicazioni on-premises.