• Guide, Sicurezza, Sistemi Operativi
• 6 Ottobre 2018

In un’infrastruttura RDS, ma più in generale nelle connessioni in RDP, la sicurezza è più che mai importante, il fatto di poter identificare in modo univoco un server previene attacchi di tipo Man-in-the-Middle, e permette un accesso più lineare all’infrastruttura evitando all’utente una serie di fastidiose conferme per completare il logon.

In un perimetro Aziendale dove è disponibile una PKI configurata in modo da emettere certificati automaticamente secondo precisi template, è possibile definire una serie di impostazioni tramite Group Policy che automatizzano il processo di richiesta e rilascio dei certificati utilizzati dai vari server Session Host.

In questo articolo si assume che nel dominio in cui vengono installati i server RDS (Session Host) sia presente una PKI attivata secondo gli articoli che propongono le Best Practice di installazione e disponibili su ICTPower.

• Deploy PKI in Windows Server 2016 – Parte 1 Architettura di una PKI Two-Tier
• Deploy PKI in Windows Server 2016 – Parte 2 Installazione e configurazione di una Root CA Offline
• Deploy PKI in Windows Server 2016 – Parte 3 Installazione Subordinate CA

In un’installazione in cui il server RDS (Session Host) non è configurato per utilizzare una PKI Enterprise viene utilizzato un certificato autosegnato che è immagazzinato nello store macchina nel container Remote Desktop

Figura 1 Certificato Per RDS Session Host

All’atto della connessione, all’utente, è presentato un warning in quanto il certificato non è stato rilasciato da una Certification Authority attendibile, dove per attendibile in questo contesto si intende riconosciuta nell’ambito del perimetro del dominio aziendale.

Figura 2 Warning Client

È tuttavia possibile permettere il salvataggio locale di un hash del certificato in modo che per le successive sessioni di collegamento non venga riproposto il warning, questa impostazione ha valore esclusivamente nel contesto dell’utente che esegue la connessione.

Gestione automatizzata dei certificati RDS

L’ambiente Remote Desktop Services può essere configurato in modo da utilizzare un certificato pubblico per la cifratura delle connessioni, oppure può essere richiesto in modo automatico ad una CA interna, ed in questa modalità, tramite la configurazione di una GPO apposita l’intero processo può essere automatizzato in modo che il servizio RDS gestisca in autonomia richiesta e rinnovo del certificato stesso.

Creazione di un Template per RDS

Dopo aver installato e configurato la struttura PKI come descritto sopra, è necessario a partire da un template esistente crearne uno nuovo per l’utilizzo con RDS.

• Dalla console di management della Issuing CA nel ramo Templates è necessario duplicare un oggetto esistente e configurarne le proprietà in modo da essere utilizzato dal ruolo Session Host di RDS per la gestione dei certificati.

Facendo un click-destro su Certificate Template e selezionando Manage si apre l’intero elenco dei Template esistente

Figura 3 Gestione Template

• È da notare che l’elenco proposto posizionandosi sul ramo Certificate Template non è l’elenco completo di tutti gli oggetti di questo tipo presenti, ma solamente l’elenco di quelli che sono stati autorizzati al rilascio tramite l’opzione New/Certificate Template to Issue della console della PKI

Figura 4 Autorizzazione alla CA per Rilascio di Particolari Template

Procedendo con l’accesso alla gestione dei vari certificati tramite l’opzione Manage viene visualizzato l’elenco completo dei Template disponibili da cui, selezionato il Template Computer, si procede alla duplicazione.

Figura 5 Scelta e duplicazione del Certificato

• Il template di cui eseguire la copia non è vincolante, in generale è utile selezionarne uno che abbia già al suo interno una serie di impostazioni da non dover ridichiarare ex-novo. , in questa soluzione si propone di duplicare il Template Computer.
  

A questo punto è necessario procedere con la personalizzazione modificando via via i vari Tab necessari allo scopo

Compatibility TAB

La scelta della compatibilità dovrà essere coerente con la versione minima di CA del sistema operativo con cui verrà rilasciato e la versione minima di Sistema Operativo con cui potrà essere utilizzato.

Figura 6 Compatibilità del Template/Certificato

General TAB

Questo Tab permette l’impostazione del nome del nuovo template e della validità del certificato richiesto (ovviamente in coerenza con la validità massima impostata nella proprietà della PKI) è importante definire anche il Renewal Period ossia il tempo prima che scada il periodo di validità, cioè quanto la funzione di Auto Enroll richiedere nuovamente un certificato.

Figura 7 Definizione delle Proprietà Generali

Extension TAB

Nel nuovo Template dovremo anche modificare le opzioni di gestione delle estensioni disponibili in Extensions.

Le estensioni definiscono in modo puntuale come un certificato deve essere usato, secondo la RFC 5280

Nel Template che stiamo costruendo per RDS dovremo editare l’Extension Application Policy e rimuovere il riferimento a Client Authentication, in quanto questa estensione non verrà utilizzata.

Figura 7 Modifica dell’Extension Application Policy

Figura 8 Rimozione del Riferimento a Client Authentication

e successivamente aggiungere una nuova Application Policy con il riferimento all’OID 1.3.6.1.4.1.311.54.1.2 questo OID è specifico per gli scopi di autenticazione di RDS come è anche descritto nell’OID repository http://www.oid-info.com/

Figura 9 Descrizione OID relativo a RDS

Figura 10 Creazione dell’Application Policy Per RDS Authentication

Security TAB

Queste impostazioni relative alla sicurezza definiranno con precisione chi o cosa potrà utilizzare il Template dovremo quindi specificare quale gruppo di computer, normalmente questo permesso è concesso a tutti i computer che partecipano in join al dominio, ma a seconda delle esigenze è possibile ridurne l’accesso.

Figura 11 Verifica delle Sicurezza del Template

Dopo aver salvato il Template, si autorizza la CA alla pubblicazione di certificati in coerenza con i permessi di richiesta definiti sopra.

Figura 12 Abilizazione al Rilascio di Certificati

Figura 13 Selezione del Template Creato

A questo punto la parte relativa alla CA ed al template di gestione automatizzata è completata, è quindi necessario configurare una GPO affinché i server RDS utilizzino il template appena creato.

Configurazione della Group Policy per l’utilizzo del Template

Le impostazioni relative all’uso del Template per le connessioni RDS sono in

Computer Configuration -> Policies -> Administrative Template -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security,

è quindi necessario creare una GPO ed applicarla ai server RDS

Figura 14 Creazione GPO Dedicata

I settaggi da modificare saranno quindi la scelta del Template di certificato e la forzatura all’uso di uno specifico layer di sicurezza per le connessioni RDP.

Figura 15 Impostazione per l’uso di SSL

L’impostazione successiva prevede che si forzi RDS ad usare uno specifico template per la richiesta del certificato, il template sarà quello che è stato creato in precedenza

Figura 16 Definizione del Template nella GPO

Verifica delle configurazioni

Se le impostazioni sono corrette possiamo verificarne il funzionamento accedendo alle diverse componenti coinvolte

• Certification Authority
• Session Host
• Client

Controllo sulla CA

Collegandosi sulla Issuing-CA dovremmo trovare, nell’elenco dei certificati emessi, il corrispondente richiesto dal server RDS con il ruolo di Session Host.

Figura 17 Issuing-CA Verifica

E’ possibile notare che il certificato ha la validità specificata nel Template

In secondo luogo è possibile verificare che il server RDS Session HOST ha effettivamente il certificato rilasciato dalla CA nel proprio store di Macchina

Figura 18 Verifica del certificato sul server RDS

L’ultima componente che è possibile verificare è la sessione RDS client che dovrebbe riportare l’autenticazione tramite il certificato emesso.

La sessione risulta verificata anche tramite il certificato ed aprendone le proprietà si può rilevare il template da cui è stato generato il certificato stesso

Utilizzo di un nome differente dall’Host Name per la raggiungibilità del server RDS

La configurazione vista fin qui è indicata per un ambiente totalmente automatizzato e dove sono presenti uno o più RDS Session Host acceduti in modo diretto ognuno con il proprio FQDN.

In un ambiente dove sono comunque presenti più RDS Session Host acceduti con un nome FQDN unico o comunque differente dall’Host Name, la configurazione vista sopra non può essere utilizzata.

E’ il caso ad esempio dell’impiego del DNS come Sistema di bilanciamento di tipo Round Robin in cui un unico nome ha più di un indirizzo corrispondente.

La richiesta automatizzata dei singoli server, secondo quanto visto fin qui, avviene puntualmente secondo l’host name quindi verrebbe originato comunque un warning all’accesso.

Supponiamo di avere un Session Host che è raggiungibile oltre che con il proprio nome rdsh01srv.ictpower.local anche con un ulteriore CNAME ts.ictpower.local . Questa configurazione richiede che il certificato al suo interno disponga anche di un SAN (Subjetc Alternative Name) corrispondente alla CNAME, altrimenti all’accesso verrà visualizzato questo messaggio.

Figura 19 Warning per nome host non corrispondente

Tramite la soluzione vista sopra che mette assieme la PKI enterprise ed i relativi template è possibile creare un certificato che può essere utilizzato da RDS anche quando richiamato tramite una CNAME.

In uno scenario di questo genere non è possibile mantenere la totale automazione, ma si dovrà agire manualmente su ogni RDS server ed effettuare una richiesta “manuale” di certificato

Creazione del Template adatto per la definizione di SAN

Partendo dal Template duplicato in precedenza è necessario effettuare una nuova duplicazione (in modo da mantenere le impostazioni principali) avendo cura di modificare il tab Subject Name che dovrà essere variato, a differenza del Template creato in precedenza, impostandolo in modo da richiedere il nome host all’utente che genererà la richiesta.

Figura 20 Modifica del Tab apposito

Richiesta manuale del Certificato

Modificato il template è necessario impostare la CA in modo da emettere i certificati anche secondo questo nuovo modello seguendo i passi riportati in Fig. 12 e 13

Terminato questo secondo passaggio è necessario aprire lo store certificati macchina del Session HOST come in figura 18, e dal ramo Personal, si dovrà selezionare All Task/Request New Certificate

Figura 21 Richiesta Manuale

Confermando poi i passi successivi fin quando non vengono presentate le opzioni relative ai due Template creati, uno per il rilascio automatizzato ed un secondo per il rilascio manuale.

Dovremo selezionare quest’ultimo, che nel nostro esempio è stato creato con il nome di RdsSessionHostTemplate-SAN

Figura 22 Visualizzazione Template

In questa videata è anche indicato che sono richieste informazioni ulteriori per il rilascio del certificato, selezionando questa opzione verrà proposta una pagina dove potremo inserire manualmente i nomi alternativi, compreso il nome host nativo, per cui il certificato viene rilasciato.

Figura 23 Dichiarazione dei Nomi a Dominio

Terminata questa impostazione sarà sufficiente effettuare l’enroll del certificato che verrà sottoposto alla CA.

Al termine nello Store di macchina sarà disponibile il certificato richiesto, che sarà valido per entrambe i nomi specificati in precedenza

Figura 24 Certificato con i nomi richiesti tramite Template

Configurazione del Servizio RDS per l’uso del Certificato

Contrariamente a quanto è avvenuto nell’esempio precedente, dove tramite GPO è stato dichiarato il Template da Utilizzare, con questa procedura, si dovrà impostare manualmente il certificato nella configurazione del registry all’interno del ramo

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Dovrà essere creata una chiave di tipo BINARY con nome SSLCertificateSHA1Hash contenente il valore del Thumbprint del certificato emesso, valore che è rilevabile nelle proprietà del certificato stesso come illustrato nella figura successiva

Figura 25 Thumbrint del Certificato

Ottenuto il valore Esadecimale è necessario ripulirlo degli spazi ed impostarlo nella chiave di registro indicata sopra

Create the following registry value containing the certificate’s SHA1 hash to configure this custom certificate to support TLS instead of using the default self-signed certificate.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp
Value name:  SSLCertificateSHA1Hash
Value type:  REG_BINARY
Value data:  <certificate thumbprint>

Per impostare questo valore è possibile creare la chiave manualmente oppure per mezzo del seguente comando VMIC

wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash=”thumbrint del certificato“

prima di procedere con il riavvio del servizio RDS è utile controllare gli accessi alla chiave privata del certificato, di norma il servizio RDS è avviato con “Network Service” quindi questo servizio dovrà poter accedere alla lettura della chiave.

Figura 26 Accesso alla Chiave Privata

Verificata questa ultima impostazione è possibile eseguire il riavvio di RDS

net stop “Remote Desktop Services” && net start “Remote Desktop Services”

A questo punto la configurazione è terminata e richiamando il server RDS sia con il proprio nome host che con la CNAME vedremo che l’accesso è verificato tramite il certificato richiesto e configurato sopra.

Figura 27 Verifica del Funzionamento

Controllo del certificato in uso su RDS

Genericamente se si vuole verificare quale certificato è in uso dal servizio RDS è possibile utilizzare questo comando powershell che ne riporta il Thumbrint

Get-WmiObject -class “Win32_TSGeneralSetting” -Namespace root\cimv2\terminalservices -Filter “TerminalName=’RDP-tcp'”

Nota: l’intera procedura presentata qui è realizzata su un ambiente omogeneo CA-DC-RDS server di versione 2016, tuttavia è stata verificata anche in ambiente di produzione con CA di versione 2012R2-ed RDS server di versione 2008 R2.

Considerazioni

Apparentemente l’impiego di una CA configurata secondo i canoni presentati nelle guide riportate sopra, e la configurazione descritta qui, possono apparire superflue.

Tuttavia la realizzazione di un ambiente dove gli utenti non devono quotidianamente confermare inutili messaggi, da un lato fa si che, anche se di poco, l’accesso diventi più rapido, ma soprattutto nel momento in cui si presenti realmente il caso di una compromissione (di qualunque tipo) l’utente non sia assuefatto e abbia un atteggiamento più critico nei confronti di avvisi che non è abituato a considerare usuali.

Vedremo in un prossimo articolo, a completamento dell’intero sistema di firma e certificazione delle sessioni RDP come è possibile, sempre utilizzando una PKI firmare un file RDP in modo da fornire assoluta garanzia all’utente della sicurezza della connessione di lavoro.