Servizi Desktop remoto e smart card
Questo argomento per il professionista IT descrive il comportamento di Servizi Desktop remoto quando si implementa l'accesso alle smart card.
La logica di reindirizzamento delle smart card e l'API WinSCard vengono combinate per supportare più sessioni reindirizzate in un unico processo.
Il supporto delle smart card è necessario per abilitare molti scenari di Servizi Desktop remoto. tra cui:
- Uso di Cambio utente rapido o Servizi Desktop remoto. Un utente non è in grado di stabilire una connessione desktop remoto basata su smart card reindirizzata. Ovvero, il tentativo di connessione non riesce nel passaggio rapido dell'utente o da una sessione di Servizi Desktop remoto
- Abilitazione di Encrypting File System (EFS) per individuare il lettore di smart card dell'utente dal processo LSA ( Local Security Authority ) in Cambio utente veloce o in una sessione di Servizi Desktop remoto. Se EFS non è in grado di individuare il lettore o il certificato della smart card, EFS non può decrittografare i file utente
Reindirizzamento di Servizi Desktop remoto
In uno scenario di Desktop remoto, un utente usa un server remoto per l'esecuzione dei servizi e la smart card è locale per il computer usato dall'utente. In uno scenario di accesso con smart card, il servizio smart card nel server remoto reindirizza al lettore di smart card connesso al computer locale in cui l'utente sta tentando di accedere.
Reindirizzamento desktop remoto
Note sul modello di reindirizzamento:
- Questo scenario è una sessione di accesso remoto in un computer con Servizi Desktop remoto. Nella sessione remota (etichettata come sessione client), l'utente esegue
net use /smartcard - Le frecce rappresentano il flusso del PIN dopo che l'utente ha digitato il PIN al prompt dei comandi finché non raggiunge la smart card dell'utente in un lettore di smart card connesso al computer client di Connessione Desktop remoto
- L'autenticazione viene eseguita dall'LSA nella sessione 0
- L'elaborazione CryptoAPI viene eseguita nell'LSA (
lsass.exe). Questo è possibile perché il redirector RDP (rdpdr.sys) consente il contesto per sessione, anziché per processo - La libreria ScHelper è un wrapper CryptoAPI specifico del protocollo Kerberos
- La decisione di reindirizzamento viene presa in base al contesto per smart card, in base alla sessione del thread che esegue la
SCardEstablishContextchiamata
Esperienza single sign-in del server Host sessione Desktop remoto
Nell'ambito della conformità ai criteri comuni, il client RDC deve essere configurabile per usare Gestione credenziali per acquisire e salvare la password o il PIN della smart card dell'utente. La conformità ai criteri comuni richiede che le applicazioni non abbiano accesso diretto alla password o al PIN dell'utente.
La conformità ai criteri comuni richiede in particolare che la password o il PIN non lascino mai l'LSA non crittografato. Uno scenario distribuito deve consentire alla password o al PIN di spostarsi tra un LSA attendibile e un altro e non può essere crittografato durante il transito.
Quando si usa l'accesso Single Sign-In (SSO) abilitato per le smart card per le sessioni di Servizi Desktop remoto, gli utenti devono comunque accedere per ogni nuova sessione di Servizi Desktop remoto. Tuttavia, all'utente non viene richiesto più di una volta un PIN per stabilire una sessione di Servizi Desktop remoto. Ad esempio, dopo che l'utente fa doppio clic su un'icona del documento di Microsoft Word che si trova in un computer remoto, all'utente viene richiesto di immettere un PIN. Questo PIN viene inviato usando un canale sicuro stabilito dal provider di credenziali. Il PIN viene reinstradato al client RDC tramite il canale sicuro e inviato a Winlogon. L'utente non riceve richieste aggiuntive per il PIN, a meno che il PIN non sia errato o non si siano verificati errori correlati alle smart card.
Accesso a Servizi Desktop remoto e smart card
Servizi Desktop remoto consente agli utenti di accedere con una smart card immettendo un PIN nel computer client rdc e inviandolo al server Host sessione Desktop remoto in modo simile all'autenticazione basata su nome utente e password.
È inoltre necessario abilitare le impostazioni di Criteri di gruppo specifiche di Servizi Desktop remoto per l'accesso basato su smart card.
Per abilitare l'accesso della smart card a un server Host sessione Desktop remoto, il certificato del Centro distribuzione chiavi (KDC) deve essere presente nel computer client rdc. Se il computer non è nello stesso dominio o gruppo di lavoro, è possibile usare il comando seguente per distribuire il certificato:
certutil.exe -dspublish NTAuthCA "DSCDPContainer"
Il DSCDPContainer nome comune (CN) è in genere il nome dell'autorità di certificazione.
Esempio:
certutil -dspublish NTAuthCA <CertFile> "CN=NTAuthCertificates,CN=Public Key Services,CN=Services,CN=Configuration,DC=engineering,DC=contoso,DC=com"
Per informazioni su questa opzione per lo strumento da riga di comando, vedere -dsPublish.
Servizi Desktop remoto e accesso alle smart card tra domini
Per abilitare l'accesso remoto alle risorse in un'organizzazione, è necessario effettuare il provisioning del certificato radice per il dominio nella smart card. Da un computer aggiunto a un dominio, eseguire il comando seguente nella riga di comando:
certutil.exe -scroots update
Per informazioni su questa opzione per lo strumento da riga di comando, vedere -SCRoots.
Per Servizi Desktop remoto tra domini, il certificato KDC del server Host sessione Desktop remoto deve essere presente anche nell'archivio NTAUTH del computer client. Per aggiungere l'archivio, eseguire il comando seguente nella riga di comando:
certutil -addstore -enterprise NTAUTH <CertFile>
Dove CertFile è il certificato radice dell'autorità di certificazione KDC.
Per informazioni su questa opzione per lo strumento da riga di comando, vedere -addstore.
Nota
Per accedere con una smart card da un computer non aggiunto a un dominio, la smart card deve contenere la certificazione radice del controller di dominio. Non è possibile stabilire un canale sicuro dell'infrastruttura a chiave pubblica (PKI) senza la certificazione radice del controller di dominio.
L'accesso a Servizi Desktop remoto in un dominio funziona solo se l'UPN nel certificato usa il formato seguente: <ClientName>@<DomainDNSName>.
L'UPN nel certificato deve includere un dominio che può essere risolto. In caso contrario, il protocollo Kerberos non è in grado di determinare quale dominio contattare. È possibile risolvere questo problema abilitando gli hint di dominio dell'oggetto Criteri di gruppo X509. Per altre informazioni su questa impostazione, vedere Smart Card Criteri di gruppo e Impostazioni del Registro di sistema.