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

  • Articolo

Certificati giocano un grande ruolo nella protezione di connessioni tra client e host di Servizi Desktop remoto.

Kristin Griffin

Chiedendo i ruoli utilizzano certificati è il tipo di una domanda trabocchetto. La vera risposta è "tutti di loro". È importante capire dove è necessario utilizzare certificati nelle distribuzioni Remote Desktop Services (RDS), e perché usare con ogni particolare servizio ruolo RDS.

La maggior parte dei ruoli che è necessario configurare, ma alcuni di loro che non si (ad esempio il Server delle licenze RD). Per impostazione predefinita, voi avrete bisogno di certificati SSL (x. 509) in ogni fase di connessione a una sessione o ospitati virtual machine (VM). Userete questi per tre scopi principali: per garantire la comunicazione tra client e server, per confermare l'identità del server o del sito Web di cui il client si connette e di segno file Remote Desktop Protocol (RDP) così gli utenti di sapere file RDP proviene da una fonte attendibile e non è stato alterato.

Ecco alcuni esempi di come RDS utilizza certificati:

  • Server Host sessione desktop utilizzano i certificati per dimostrare la loro identità. Questo è chiamato l'autenticazione server.
  • Server Host sessione desktop e server Host di virtualizzazione desktop utilizzano certificati per impostare un collegamento sicuro tra client e server con TLS 1.0.
  • RD sessione server Host utilizzano i certificati per l'autenticazione client necessaria per l'autenticazione di livello rete (NLA), Single Sign-On (SSO) e d'applicazione Web SSO.
  • Server Host sessione desktop e gestore connessione desktop remoto utilizzare un certificato SSL per firmare il file RemoteApps e VM RDP, assicurando agli utenti che stanno lanciando un file attendibile.
  • TS Gateway Server utilizzano i certificati per crittografare le comunicazioni con i clienti tramite TLS 1.0.
  • È possibile proteggere il sito di accesso Web con un certificato SSL per assicurare che le persone stanno per un sito attendibile (HTTPS).

Abilitazione funzionalità RDS si basa su tecnologie specifiche per supportare l'utilizzo di certificati (vedere Figura 1).

Enabling RDS functionality brings into play certain security technologies

Figura 1 funzionalità RDS abilitazione porta in Gioca determinate tecnologie di sicurezza.

Garantire il canale

TLS è lo standard di Internet Engineering Task Force (IETF) basato su SSL versione 3, pubblicata da Netscape. Alcuni dei miglioramenti su TLS includono nuovi avvisi di messaggio, la capacità di certificati di catena a un intermediario certificato di autorità di certificazione (CA) anziché il certificato della CA principale e gli algoritmi di crittografia leggermente diversa da SSL.

Sebbene TLS è basata su SSL, i due sono incompatibili. TLS possono, tuttavia, implementare un meccanismo attraverso il quale può ripiegare a SSL versione 3 se necessario. Per stabilire un canale di comunicazione sicura tra un client e un server utilizzando TLS, il client e il server passare attraverso un processo di messaggistica, risposta e crittografia (vedere Figura 2).

The two-way encryption process for establishing a secure channel.

Figura 2 il processo di crittografia bidirezionale per stabilire un canale protetto.

Ci sono due requisiti per questo processo funzionare correttamente.

  • Il client deve considerare attendibile la CA che firma il certificato SSL del server.
  • La connessione tra server e client deve utilizzare ad alto livello (di default) o la crittografia di elaborazione Standard FIPS (Federal Information). Basso livello crittografia Crittografa solo il traffico proveniente dal client al server, non server al client, quindi non è un modo sicuro per inviare le funzionalità di sicurezza o segreti condivisi.

Se il livello di crittografia e connessione soddisfa tali due requisiti, il client e il server di stabilire una comunicazione come segue:

  1. Il client invia un messaggio hello insieme con un valore di lunghezza fissa casuale. Il server risponde con un valore di lunghezza fissa casuale. Durante questo scambio, il client indica al server i metodi di compressione, cifrari e gli hash che supporta. Invia anche la versione di protocollo e un ID di sessione al server. L'ID di sessione identifica il communi­canale catione — questo non è l'ID di sessione su un server Host sessione Desktop remoto.
  2. Il server sceglie il metodo di crittografia più alto che entrambi supportano e una funzione di crittografia e hash dall'elenco del client. Poi dice il client a cui uno essa ha cho­sen. Se c'è un livello minimo fissato per il server e il client non può soddisfare questo minimo, la connessione avrà esito negativo.
  3. Il server invia il proprio certificato digitale al client. Questo certificato contiene il nome del server, il CA attendibile che ha firmato il certificato e la chiave pubblica del server.
  4. Il client verifica che il certificato è valido e di fiducia. Il certificato utilizzato per firmare il certificato del server sarà in archivio di autorità di certificazione principale attendibili del client. Quindi crea un segreto pre-master, esegue la crittografia con chiave pubblica del server e lo invia al server.
  5. Il server riceve e decrittografa il segreto pre-master con la chiave privata. Questo server è l'unico che può fare questo, perché è l'unico server con la chiave privata corrispondente.
  6. Il server e il client hanno il segreto pre-master e scambiati all'inizio del processo di numeri casuali. Utilizzare questi valori per generare il master secret 48 byte (conosciuto anche come il segreto condiviso). Dopo la generazione il master secret, si elimina il segreto pre-master.
  7. Client e il server, quindi il master secret 48 byte di hash e usarlo per generare il segreto di MAC (la chiave di sessione utilizzato per l'hashing) e la chiave di scrittura (la chiave di sessione utilizzata per la crittografia). Queste chiavi di crittografare e decrittografare comunicazione per questa sessione. Dopo la sessione è finita, le chiavi sono eliminate.

Se ogni passo di questa sequenza non funziona, la connessione non è stato completamente protetto. Cosa succede quindi dipende dalle impostazioni nella scheda Avanzate sulle connessioni Remote Desktop­cliente tion (RDC). In caso di errore di autenticazione di un utente può scegliere di fare uno qualsiasi dei seguenti:

  • Comunque connettersi senza avvisare il cliente c'era un problema al server di autenticazione.
  • Avvertire il cliente, ma continua a consentire la connessione (impostazione predefinita).
  • Negare la connessione se esso non può essere verificata.

L'eccezione è se il server richiede un livello minimo di sicurezza. Se questo è il caso e il client non può soddisfare i requisiti minimi, la connessione avrà esito negativo. Per impostazione predefinita, il client e il server di negoziare e utilizzare le impostazioni di connessione più sicure, che entrambi supportano.

Credenziale di memorizzazione nella cache con CredSSP

Credenziale di memorizzazione nella cache è stato introdotto con Windows Vista e Windows Server 2008. In questo modo due caratteristiche — uno che aiuta l'utente e uno che consente di proteggere il server.

Memorizzazione nella cache di credenziali aiuta gli utenti memorizzando le credenziali per una particolare connessione così essi non hanno bisogno di fornire loro ogni volta che si collegano al server (questo è il Single Sign-on). Questo accelera la connessione. In caso contrario una connessione brokered deve essere controllata ad ogni passo.

Sul lato server, credential cache fornisce le credenziali al server prima che esso stabilisce una sessione. Questo consente di evitare il sovraccarico di una sessione se l'utente non è autorizzato (questo è NLA).

Il pezzo che rende la credenziale lavoro di memorizzazione nella cache è Credential Security Service Provider (CredSSP). Questo è supportato da Windows 7, Windows Vista, Windows Server 2008 e Windows XP SP3. Esso non è collegato alla versione di RDC utilizzato perché CredSSP è parte del sistema operativo. CredSSP svolge le seguenti funzioni:

  • Per NLA, CredSSP fornisce il quadro che autentica un utente a un server Host sessione Desktop remoto prima di completamente stabilire la connessione.
  • Per la riconnessione a una sessione all'interno di una fattoria, CredSSP accelera il processo di passaggio la connessione al server corretto lasciando il server Host sessione Desktop remoto a vedere chi è l'accesso senza dover creare un'intera sessione. Questo utilizza NLA in uno scenario leggermente diverso.
  • Per SSO, CredSSP memorizza le credenziali dell'utente e li passa al server Host sessione Desktop remoto per automatizzare l'accesso.

CredSSP consente l'autenticazione reciproca dei server e client (vedere Figura 3).

Authenticating both the server and client requires a secure channel.

Figura 3 l'autenticazione del server e il client richiede un canale sicuro.

Questo processo di autenticazione accetta i seguenti passaggi.

  1. Il client invia un canale protetto con il server tramite TLS. Il server passa indietro il certificato con nome, CA e chiave pubblica. Viene identificato solo il server. A questo punto, il client rimane anonimo.
  2. Quando viene stabilita la sessione e una chiave di sessione creata, CredSSP utilizza il protocollo semplice e protetto GSS-API negoziazione (SPNEGO) a reciprocamente Autentic­cate il server e client. Fondamentalmente, questo meccanismo consente di client e server d'accordo su un meccanismo di autenticazione che entrambi supporta, ad esempio Kerberos o Windows NT LAN Manager (NTLM).
  3. Dopo l'autenticazione reciproca è finito, CredSSP sul lato client consente di crittografare il certificato del server con la chiave di sessione creata durante la fase 2 e la invia al server. Il server riceve il certificato crittografato, esegue la decrittografia con la chiave privata e quindi aggiunge uno per il bit più significativo del numero di certificato. Esso quindi crittografa il risultato e la invia al client. Quest'ultimo assicura che nessuno può intercettare lo scambio tra client e server e lo spoofing server.
  4. Il client cliente il certificato crittografato ricevuto dal server e com­pares esso per il proprio certificato.
  5. Supponendo che i risultati corrispondano, CredSSP sul lato client invia le credenziali dell'utente al server.

Autenticare l'identità del Server

Un pericolo di comunicare con un computer remoto che richiede di fornire le proprie credenziali è che il server potrebbe non essere quello che pensi. Se si tratta di un server di canaglia impersonando un uno attendibile, è possibile digitare le vostre credenziali inavvertitamente al server sbagliato. Questo darebbe attaccanti tutto il che necessario per connettersi al proprio dominio o un server.

RDP include crittografia, ma il protocollo non ha alcun mezzo per autenticare il server. Ecco dove TLS e CredSSP vengono in. L'autenticazione server controlla il nome che immesso nella RDC client (o file RDP) contro il nome rilasciato il certificato specificato nello strumento di configurazione RD sul server Host sessione Desktop remoto a cui esso è connesso.

Firma file RDP

È possibile utilizzare i certificati per firmare digitalmente i file RemoteApp, così come file RDP utilizzati per connettersi a un pool o personali VM (VDI). Questi file di firma assicura l'utente che furono creati da una fonte attendibile. Protegge anche i file RDP da manomissioni.

È anche necessario per l'implementazione di Web SSO RemoteApp file di firma. Ciò consente agli utenti di firmare in una volta per il sito Web di accesso Web RD. Quindi essi possono lanciare RemoteApps da qualsiasi azienda senza dover fornire le proprie credenziali ancora una volta.

CredSSP non può passare le credenziali di accesso Web desktop remoto. L'utente deve innanzitutto Accedi al sito Web per archiviare le proprie credenziali. Quindi non è necessario autenticare nuovamente per avviare programmi RemoteApp. Per questo lavoro, il RemoteApps deve essere firmata e l'utente deve convalidare il certificato utilizzato per firmare il RemoteApp.

RDP file creati quando un utente avvia una connessione RDP dalla scheda RD Web Access desktop vengono creati al volo. I file non sono firmati. Pertanto, Web SSO non funziona quando si collega ai desktop. L'utente dovrà accedere all'endpoint una volta stabilita la connessione. Web SSO non funzionerà anche per le connessioni a macchine virtuali nel pool o personali.

Garantire connessioni

TS Gateway utilizza TLS 1.0 per comunicazioni sicure tra Gateway Desktop remoto e client desktop remoto, in genere si trova all'esterno della rete azienda (su Internet). TLS, come descritto in precedenza, è necessario un certificato SSL. È inoltre possibile protezione delle comunicazioni tra i client e il server di accesso Web desktop remoto utilizzando un certificato digitale per crittografare le sessioni del sito Web (HTTPS).

I certificati sono una parte essenziale di una distribuzione di RDS. RDS utilizza certificati per garantire le comunicazioni e le funzionalità che consentono. Il mese prossimo, occuperò istituire servizi ruolo RDS di utilizzare tali certificati.

Raymond Chen

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