Microsoft Windows Server 2008 R2: I certificati promuovono la sicurezza di Servizi Desktop remoto: seconda parte

L'utilizzo dei certificati costituisce una parte importante della protezione delle comunicazioni per Servizi Desktop remoto. Ecco il resto della storia su come installarli su ognuno dei server.

Kristin Griffin

Certificati di svolgono un ruolo importante nelle distribuzioni Remote Desktop Services (RDS). Essi fornire protezione alle comunicazioni tra client e server. Essi confermare l'identità del server o del sito Web a cui si sta collegando. Essi inoltre segno file Remote Desktop Protocol (RDP) per assicurarvi they're da una fonte attendibile.

È consigliabile utilizzare i certificati con ogni servizio ruolo RDS. Ecco ciò che vi serve sapere per installare i certificati su ogni server di ruolo usando strumenti locali o criteri di gruppo. In primo luogo, configurare tutti i Host sessione desktop per server connessione impostazioni di protezione dalla scheda Generale del proto­col ascoltatore dialogo Proprietà dello strumento di configurazione RD. Per arrivarci, andare a strumenti di amministrazione | Servizi Desktop remoto | Desktop Session configurazione Host remoto. Fare doppio clic nella sezione del riquadro centrale connessioni RDP-Tcp. Questo è anche dove aggiungere il certificato SSL del server.

È possibile configurare queste impostazioni in base al server. È inoltre possibile configurare queste impostazioni utilizzando criteri di gruppo, applicando la seguente serie di impostazioni oggetto Criteri di gruppo (GPO) all'Host sessione Desktop remoto server unità organizzativa (OU) da configurazione Computer | Politiche | Modelli amministrativi | Componenti di Windows | Servizi Desktop remoto | Host sessione Desktop remoto | Sicurezza:

• Impostare il client il livello di crittografia connessione
• Richiedono l'uso del livello di sicurezza specifiche per connessioni remote (RDP)
• Modello di certificato di autenticazione server
• Richiedono l'autenticazione dell'utente per le connessioni remote utilizzando l'autenticazione a livello di rete (NLA)

Autenticazione a livello di rete

NLA non è necessaria per impostazione predefinita. Per richiedere l'uso di NLA per la connessione al server Host sessione Desktop remoto, selezionare la tempestività­mangiato la casella di controllo. In questo modo impedirà qualsiasi client che non supportano NLA (qualsiasi client che eseguono RDC prima di versione 6. x e qualsiasi sistema operativo che non supporta Credential Security Support Provider o CredSSP) di connessione al server. Solo i client che eseguono Windows 7, Windows Vista e Windows XP SP3 supportano CredSSP.

Autenticazione server

Impostare il server le impostazioni di autenticazione dalla sezione Security Layer. Il valore predefinito è Nego­tiate, significato che client e server saranno entrambi utilizzano Transport Layer Security (TLS) per l'autenticazione server, se è sup­porting.

È possibile modificare questa impostazione per forzare l'autenticazione del server utilizza TLS. Se non è possibile eseguire l'autenticazione server, è possibile impostare il comportamento client dalle impostazioni nella scheda Avanzate del Client Desktop remoto:

• Non collegare se l'autenticazione ha esito negativo
• Avvisami se l'autenticazione ha esito negativo
• Connetti sempre, anche se l'autenticazione ha esito negativo

È possibile scegliere il certificato, che il server deve utilizzare per autenticarsi facendo clic su Seleziona nella parte inferiore dello schermo. Se fare clic su Seleziona, è possibile ottenere ulteriori dettagli sul certificato, tra cui quello che viene utilizzato, il nome dell'autorità di certificazione (CA), e quando esso scade.

Il certificato deve contenere il nome DNS del server Host sessione Desktop remoto. Questo sarà qualcosa di simile a rdsh1.domain.local, ad esempio. Se è stato implementato una server farm, il certificato deve contenere il nome DNS del server farm Host sessione Desktop remoto — ad esempio, farm.domain.local.

Il server Host sessione Desktop remoto è impostato per utilizzare un certificato auto-firmato, per impostazione predefinita. Questo certificato non è pensato per essere utilizzato in ambienti di produzione per tre motivi:

• Il autenticità di certificato non è controllato a tutti.
• Il certificato non è attendibile dai clienti, perché non è firmato da parte di fiducia (ad esempio, la soluzione di infrastruttura a chiave pubblica interna della vostra azienda o una CA pubblica).
• Se si sta implementando una fattoria, il nome il certificato predefinito non corrispondere il RD sessione server farm nome host, quindi verificare l'identità del server avrà esito negativo.

Firma nel pool e personali VMs

Può avere un pool e personali macchine virtuali (VM) firmato da l'installazione di un certificato SSL sul gestore connessione desktop remoto utilizzando RD Connection Manager (se Figura 1).

Figura 1 è possibile utilizzare RD Connection Manager per firmare nel pool o singole macchine virtuali.

Firma RemoteApps

Firmare RemoteApps utilizzando il certificato installato in Gestione RemoteApp sul server Host sessione Desktop remoto (vedere Figura 2).

Figura 2 si può firmare anche RemoteApps; utilizzare il certificato in Gestione RemoteApp.

Se si imposta una server farm Host sessione Desktop remoto, assicurarsi di installare il certificato stesso esatto su tutti i server Host sessione Desktop remoto nella farm e distribuire in qualsiasi altre aziende agricole. In questo modo Web single sign-on (SSO) lavoro tra tutti i membri della fattoria e tra tutte le aziende.

A tale scopo, esportare il certificato, tra cui la chiave privata, da un server. Importarlo in altri server utilizzando lo snap-in certificati in Microsoft Management Console (MMC) — aggiungere l'account del computer, non l'account utente.

Se si sta implementando Web SSO con accesso Web desktop remoto e si sta utilizzando gestore connessione desktop remoto, come la sorgente in accesso Web desktop remoto, quindi è necessario installare il certificato stesso nel gestore connessione desktop remoto come si fa su tutti i server Host sessione Desktop remoto (lo stesso certificato che utilizzare per firmare RemoteApps). Questo può essere fonte di confusione per due motivi:

1. La sezione dove installare il certificato sul gestore connessione desktop remoto viene chiamata "Virtual Desktop: Risorse e configurazione,"che è fuorviante. Il certificato installato qui non viene utilizzato solo per la firma di VMs virtual desktop infrastructure (VDI), è anche usato nel processo di Web SSO per la firma di RemoteApps quando è coinvolto il gestore connessione desktop remoto. I certificati di firma nel gestore connessione desktop remoto e Host sessione Desktop remoto server Gestione RemoteApp devono corrispondere o Web SSO avrà esito negativo.
2. Quando si inizia un RemoteApp e il certificato installato sul gestore connessione desktop remoto è diverso da quello installato sui server Host sessione desktop, Web SSO non funzionerà. Non c'è alcuna indicazione, tuttavia, il certificato è in realtà diverso sul gestore connessione desktop remoto. La finestra a comparsa mostra solo il certificato impostato in Gestione RemoteApp, quindi è difficile dire che esiste un problema di certificato.

Controllare il blog "Introducing Web Single Sign-On per RemoteApp e Desktop Connections" per ulteriori informazioni sulla creazione di Web SSO.

Assicurare il sito Web di accesso RD

Protezione di un sito Web non è specifico RDS. Per proteggere il sito Web di accesso Web RD, aggiungere un certificato con il nome DNS del sito Web in IIS (vedere Figura 3).

Figura 3 aggiungendo un certificato con il nome DNS può garantire un sito di accesso Web.

I certificati installati al deposito di Personal Computer del server che hanno la chiave privata inclusa appariranno come opzioni nella casella a discesa corrispondente nel menu Modifica.

Configurazione del Gateway Desktop remoto con un certificato

L'installazione di Gateway Desktop remoto richiede un certificato per crittografare le comunicazioni tra client e server, specialmente su Internet. Il certificato SSL deve contenere il nome DNS del server TS Gateway che gli utenti esterni possono risolvere (nome DNS esterno, ad esempio: rdgateway.domain.com).

Installare il certificato di Gateway Desktop remoto tramite la scheda certificato SSL nelle proprietà di gestione Gateway RD (vedere Figura 4). Ulteriori informazioni, vedere su TS Gateway certificati nella libreria TechNet.

Figura 4 installare il certificato Gateway RD.

È possibile impostare certificati nella distribuzione per comunicazioni protette e autenticare il client e il server RDS. Ci sono requisiti certificato specifico per ogni servizio di ruolo. Questo dovrebbe aiutare a capire perché bisogno di certificati nelle implementazioni di RDS e su come e dove implementare i certificati con ogni servizio ruolo RDS.

Kristin Griffin è un MVP per Servizi Desktop remoto. Lei moderati un forum Microsoft dedicato ad aiutare la comunità informatica basata su server (servizi di Desktop remoto) e mantiene un blog RDS a blog.kristinlgriffin.com. Lei è un collaboratore di "Mastering Windows Server 2008" di Mark Minasi (Sybex, 2008) e "Mastering Windows Server 2008 R2" (Sybex, 2010). Lei anche coautore di "Microsoft Windows Server 2008 Terminal Services Resource Kit" (Microsoft Press, 2008) e "Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit" (Microsoft Press, 2010) con Christa Anderson.

Contenuto correlato

• Microsoft Windows Server 2008 R2: Certificati auto RDS sicurezza
• Windows Server 2008 R2: Servizi di Desktop remoto - un manuale del proprietario
• Microsoft Windows Server 2008 R2: Capire il gestore connessione desktop remoto

Utilizzo di certificati con RDS Q & A

**D:**Come aggiungere certificati al mio server modo posso utilizzare nei miei servizi ruolo Remote Desktop Services (RDS)?

**R:**Certificati situati nell'archivio personale del tuo server Computer Account saranno disponibili consentono di aggiungere alle implementazioni di RDS. Per aggiungere certificati al computer archivio Account personale:

1. Creare uno snap-in Microsoft Management Console (MMC) (tipo MMC nella finestra Esegui o cerca)
2. Aggiungere lo snap-in certificati (File, Aggiungi/Rimuovi Snap-in)
3. Scegliere Account Computer, Aggiungi, quindi fare clic su OK
4. Passare alla cartella personale, poi in cartella certificati
5. Pulsante destro del mouse e scegliere Import per importare il certificato che avete ricevuto dal vostra CA

Gestione Gateway RD è più facile, a questo proposito perché ti dà un pulsante Import nell'interfaccia quindi non bisogna creare manualmente uno snap-in MMC.

**D:**Come a reprimere eventuali messaggi di avviso quando un utente avvia un file firmato Remote Desktop Protocol (RDP)?

**R:**Attivare l'impostazione politica. Specifica identificazioni personali di Secure Hash Algorithm (SHA1) dei certificati che rappresentano gli editori attendibili con estensione rdp. Quando si attiva questo criterio, si specifica dei certificati che il client si vedrà come attendibile. Quando dici che il client fida di un certificato, qualsiasi file RDP firmato da tale certificato è attendibile. Così, non riceverai alcun pop-up di avviso chiedendo di verificare che si fiducia l'editore. Controllare qui per ulteriori informazioni su questa impostazione.

Q: ho i certificati corretti in posto sul mio server Host sessione Desktop remoto, ma ancora sto avendo problemi di connessione.

**R:**Ci sono alcuni problemi noti di certificati e implementazioni di RDS:

1. Utilizzo di certificati Server Gated Cryptography (SGC) sembra causare problemi. Assicurarsi che i certificati non sono certificati SGC. Per ulteriori informazioni, vedere il thread del Forum RDS qui e qui.
2. Se i vostri clienti collegamento ottengano l'errore, "il certificato non è valido per questo utilizzo," la catena dei certificati per il certificato sul server Host sessione Desktop remoto può essere troppo lungo. Vedi questo thread del Forum RDS per ulteriori informazioni.

**D:**Posso utilizzare un certificato jolly o un certificato di Storage Area Network (SAN) con mia implementazione RDS?

**R:**Sì, può. Un certificato di SAN è un certificato contenente più di un nome host. Poiché un certificato SAN contiene più nomi di oggetto, è possibile utilizzare un certificato in più posizioni che richiedono un certificato. Un esempio di un certificato di SAN potrebbe essere uno che contiene il tuo Gateway Desktop remoto e i vostri nomi DNS di accesso Web RD, come pure il nome che utilizzi per firmare i file RemoteApp:

• rdgateway.domain.com
• RDWeb.domain.com
• Sign.domain.com

Utilizzando un certificato jolly, avete bisogno di appena due certificati per implementare una distribuzione tipica piccola fattoria. La fattoria di Host sessione Desktop remoto deve ancora fare riferimento al nome DNS della fattoria, e questo nome è in genere un nome DNS interno (domain.local). Che non è la stessa di vostra zona DNS esterno (domain.com), quindi avrete bisogno di avere un certificato separato per questo.

**D:**Ho più servizi ruolo installati su un server. Ho ancora bisogno di installare i certificati in tutti i servizi di ruolo che ho ho utilizzato?

**R:**Sì. Ogni servizio ruolo utilizza certificati per scopi specifici. Anche se i servizi di ruolo possono essere combinati su un unico server, pensare di loro come entità separate quando si implementano i certificati.

— K.G.