Pubblicato per la prima volta su TECHNET il gen 24, 2014
Buongiorno AskPerf! Kiran qui con una domanda per te: Perché abbiamo bisogno di certificati? Bene, i certificati vengono utilizzati per firmare la comunicazione tra due macchine. Quando un client si connette a un server, l’identità del server che riceve la connessione e, a sua volta, le informazioni dal client, viene convalidata utilizzando i certificati.
Questo viene fatto per prevenire possibili attacchi man-in-the-middle. Quando viene impostato un canale di comunicazione tra il client e il server, l’autorità che emette/genera il certificato garantisce che il server sia autentico.
Quindi, finché il client si fida del server con cui sta comunicando, i dati inviati da e verso il server sono considerati sicuri. Questo mi porta alla prossima domanda:
Che tipo di certificato è richiesto per RDS?
Il seguente blog contiene informazioni riguardanti il tipo di certificati e come è possibile crearli utilizzando la CA interna del dominio.
http://blogs.msdn.com/b/rds/archive/2010/04/09/configuring-remote-desktop-certificates.aspx
Requisiti di base per i certificati di desktop remoto:
- Il certificato viene installato nell’archivio certificati “Personale” del computer.
- Il certificato ha una chiave privata corrispondente.
- L’estensione ” Enhanced Key Usage “ha un valore di” Server Authentication “o” Remote Desktop Authentication ” (1.3.6.1.4.1.311.54.1.2). È possibile utilizzare anche certificati senza estensione “Enhanced Key Usage”.
Come suggerisce la funzione che svolge, abbiamo bisogno di un certificato di autenticazione del server. Questo certificato può essere generato utilizzando il modello ‘Workstation Authentication’ (se necessario).
Ecco il processo esatto:
- Aprire CERTSRV.MSC e configurare i certificati.
- Apri Autorità di certificazione.
- Nel riquadro Dettagli, espandere il nome del computer dell’istruttore.
- Fare clic con il pulsante destro del mouse su Modelli di certificato e selezionare Gestisci. Fare clic con il pulsante destro del mouse su Autenticazione workstation e fare clic su Duplica modello.
- Nella scheda Generale, modificare il nome visualizzato del modello in Autenticazione client-server e selezionare Pubblica certificato in Active Directory.
- Nella scheda Estensioni, fare clic su Criteri applicazione e quindi su Modifica. Fare clic su Aggiungi, quindi selezionare Autenticazione server. Fare clic su OK fino a tornare alla finestra di dialogo Proprietà nuovo modello.
- Fare clic sulla scheda Sicurezza. Per i computer di dominio, fare clic sulla casella di controllo “Consenti registrazione automatica”. Fare clic su OK. Chiudere la console Modelli di certificato.
- Nello snap-in certsrv, fare clic con il pulsante destro del mouse su Modelli di certificato e selezionare Nuovo modello di certificato da emettere.
- Selezionare Autenticazione client-server e quindi fare clic su OK.
Questo sarà visibile quando si visualizza il certificato nello snap-in MMC “Certificati”, come di seguito:
Quando si apre il certificato, la scheda “Generale” conterrà anche lo scopo di questo certificato come “Autenticazione server”, come mostrato di seguito:
un Altro modo per convalidare questo, sarebbe quello di passare per la “sezione” dati del certificato e la ‘Utilizzo Avanzato Chiave di proprietà:
Il modo più semplice per ottenere un certificato, se si controllano le macchine client che si connettono, è quello di utilizzare Servizi Certificati Active Directory. È possibile richiedere e distribuire i propri certificati e saranno attendibili da ogni macchina nel dominio.
Se si intende consentire agli utenti di connettersi esternamente e non faranno parte del dominio, è necessario distribuire i certificati da una CA pubblica. Esempi inclusi, ma non limitati a: GoDaddy, Verisign, Entrust, Thawte, DigiCert
Ora che sai di che tipo di certificato hai bisogno, parliamo del contenuto del certificato.
In Windows 2008/2008 R2, ci si connette al nome della farm, che come da DNS round robin, viene prima indirizzato al redirector, accanto al broker di connessione e infine al server che ospiterà la sessione.
In Windows 2012, ti connetti al Broker di connessione e ti indirizza alla raccolta utilizzando il nome della raccolta.
I certificati distribuiti devono avere un nome soggetto o un nome soggetto alternativo che corrisponda al nome del server a cui l’utente si sta connettendo. Ad esempio, per la pubblicazione, il certificato deve contenere i nomi di tutti i server RDSH nella raccolta. Il certificato per RDWeb deve contenere l’FQDN dell’URL, in base al nome a cui gli utenti si connettono. Se si dispone di utenti che si connettono esternamente, questo deve essere un nome esterno (deve corrispondere a ciò a cui si connettono). Se si dispone di utenti che si connettono internamente a RDweb, il nome deve corrispondere al nome interno. Per Single Sign On, di nuovo il nome dell’oggetto deve corrispondere ai server nella raccolta.
Per il nostro esempio, consideriamo la mia distribuzione RDS per contenere le seguenti macchine:
RDSH1.RENDER.COM Host di sessione con applicazioni remote configurate
RDSH2.RENDER.COM Host di sessione con applicazioni remote configurate
RDVH1.RENDERE.COM host di Virtualizzazione con VDI VMs configurato
RDVH2.RENDER.COM host di Virtualizzazione con VDI VMs configurato
RDCB.RENDER.COM Broker di Connessione
RDWEB.RENDER.COM RDWeb e il Gateway del server
Quando il mio client si connette internamente, egli immettere il nome di dominio completo del server che ospita la pagina web, io.e,: RDWEB.RENDER.COM.
Il nome del certificato deve essere in questo nome, l’URL che l’utente avvia la connessione. Ma dobbiamo ricordare che la connessione non finisce qui. La connessione scorre quindi dal server Web a uno degli host di sessione o host di virtualizzazione e anche al broker di connessione.
Il certificato può essere comune su tutti questi server. Per questo motivo è consigliabile che il nome alternativo soggetto del certificato contenga i nomi di tutti gli altri server che fanno parte della distribuzione.
In breve, il certificato per il mio ambiente sarebbe il seguente:
Tipo: Autenticazione server
Nome: RDWEB.RENDER.COM
SAN: RDSH1.RENDER.COM; RDSH2.RENDER.COM; RDVH1.RENDER.COM RDVH2. RENDERE.COM; RDCB.RENDER.COM
Questo è tutto ciò di cui hai bisogno finché hai 5 o meno server nella distribuzione. Ma abbiamo un problema quando abbiamo più server nella distribuzione. Questo perché, in base alla progettazione, la SAN (Subject Alternate Name) su un certificato può contenere solo 5 nomi di server. Se ne hai più, dovrai ottenere un certificato jolly rilasciato per coprire tutti i server nella distribuzione. Qui il mio certificato cambia come segue:
Tipo: Autenticazione server
Nome: RDWEB.RENDER.COM
SAN: *.RENDERE.COM
Incontriamo ancora alcune sfide quando si tratta del seguente scenario. Si noti che questo è vero solo quando si dispone di utenti esterni che accedono alla distribuzione.
Nome esterno: RDWEB.RENDER.com
Nome interno: RDWEB.RENDERE.locale
Qui, se si ottiene un certificato con RDWEB.RENDER.COM nel nome, vengono comunque visualizzati gli errori del certificato. Questo perché il certificato dovrebbe convalidare un server con l’FQDN:’ RDWEB.RENDER.COM’. Tuttavia, il tuo server è ‘ RDWEB.RENDERE.LOCALE ‘e il’. com ‘a’.la magia locale avviene solo sul tuo firewall/router pubblico usando il port forwarding (scenario più comune).
In tali scenari, è stato precedentemente raccomandato che il nome sul certificato contenga il nome ‘.com’ e la SAN contenga il ‘.nome locale.
Recentemente, tutti i provider di certificati pubblici stanno interrompendo l’emissione di certificati con ‘.LOCALE ‘ in loro. A partire da Windows 8 e Windows Server 2012, non è più necessario che i nomi esterni e interni siano contenuti nel certificato.
In scenari in cui si hanno client esterni che si connettono e si dispone di un suffisso di dominio interno privato (DOMINIO.LOCALE), è possibile ottenere un certificato da una CA pubblica con l’esterno (RDWEB.DOMAIN.COM) denominarlo e associarlo ai ruoli RD Web Access e RD Gateway, poiché questi sono gli unici ruoli esposti a Internet. Per RD Connection Broker – Publishing e RD Connection Broker – Enable Single Sign On, è possibile utilizzare un certificato interno con il ‘ DOMINIO.C’e’ sopra un nome LOCALE. Questo tuttavia, come accennato in precedenza, funzionerà solo con i client che si connettono tramite RDC 8.0 o superiore.
Il gateway RD e il client desktop remoto versione 8.0 (e versioni successive) forniscono agli utenti esterni una connessione sicura alla distribuzione. Una volta collegato alla distribuzione, il certificato interno con il ‘.local ‘ nome si prenderà cura di App remote firma (pubblicazione)e Single Sign-On.
Ora, diamo un’occhiata a dove configuriamo il certificato che abbiamo:
Aprire Server Manager sul server Connection Broker e fare clic su Servizi desktop remoto nel riquadro più a sinistra.
Una volta qui, vedrai la tua distribuzione mostrata come nell’illustrazione seguente. Fare clic su Attività e selezionare “Modifica proprietà distribuzione”
Questo farà apparire il foglio delle proprietà della distribuzione. Selezionare l’opzione Certificati nel riquadro di sinistra:
Ora, come discusso in precedenza, è possibile selezionare il certificato che è stato creato utilizzando il pulsante ‘Seleziona certificato esistente’ nella parte inferiore dello schermo.
Basta puntare al ‘.pfx ‘ e consentono di importare il certificato per il ruolo.
È possibile utilizzare un singolo certificato per tutti i ruoli, se i client sono interni solo al dominio, generando un semplice certificato jolly (*.RENDERE.LOCALE) e legandolo a tutti i ruoli.
Si noti che, anche se si dispone di più server che fanno parte di questa distribuzione, Server Manager importerà il certificato su tutti i server nella distribuzione, li inserirà nella radice attendibile delle macchine e li assocerà ai rispettivi ruoli.
-Kiran Kadaba
