Requisiti ed enumerazione dei certificati

Questo argomento per professionisti IT e sviluppatori di smart card descrive come vengono gestiti e usati i certificati per l'accesso alle smart card.

Quando viene inserita una smart card, vengono eseguiti i passaggi seguenti.

1. Il database di Gestione risorse smart card cerca il provider di servizi di crittografia (CSP) della smart card.

2. Un nome di contenitore completo viene costruito usando il nome del lettore di smart card e viene passato al CSP. Il formato è \\.<Reader name>\

3. Viene chiamato CryptAcquireContext per recuperare un contesto nel contenitore predefinito. Se si verifica un errore, la smart card non è utilizzabile per l'accesso alla smart card.

4. Il nome del contenitore viene recuperato usando il parametro PP_CONTAINER con CryptGetProvParam.

5. Usando il contesto acquisito nel passaggio 3, viene eseguita una query sul CSP per il parametro PP_USER_CERTSTORE. Per altre informazioni, vedere Architettura delle smart card. Se l'operazione ha esito positivo, viene restituito il nome di un archivio certificati e il flusso del programma passa al passaggio 8.

6. Se l'operazione nel passaggio 5 ha esito negativo, viene eseguita una query sul contesto del contenitore predefinito del passaggio 3 per la chiave di AT_KEYEXCHANGE.

7. Viene quindi eseguita una query sul certificato dal contesto della chiave usando KP_CERTIFICATE. Il certificato viene aggiunto a un archivio certificati in memoria.

8. Per ogni certificato nell'archivio certificati del passaggio 5 o del passaggio 7, vengono eseguiti i controlli seguenti:

   1. Il certificato deve essere valido, in base all'orologio del sistema del computer (non scaduto o valido con una data futura)
   2. Il certificato non deve trovarsi nella parte AT_SIGNATURE di un contenitore
   3. Il certificato deve avere un nome dell'entità utente (UPN) valido
   4. Il certificato deve avere l'utilizzo della chiave di firma digitale
   5. Il certificato deve avere l'EKU di accesso alla smart card

   Qualsiasi certificato che soddisfi questi requisiti viene visualizzato all'utente con l'UPN (o l'indirizzo di posta elettronica o l'oggetto del certificato, a seconda della presenza delle estensioni del certificato)

9. Il processo sceglie quindi un certificato e viene immesso il PIN

10. LogonUI.exe pacchetti le informazioni e le invia a Lsass.exe per elaborare il tentativo di accesso

11. In caso di esito positivo, LogonUI.exe si chiude. In questo modo il contesto acquisito nel passaggio 3 viene rilasciato

Flusso di accesso delle smart card in Windows

La maggior parte dei problemi durante l'autenticazione si verifica a causa di modifiche al comportamento della sessione. Quando si verificano modifiche, l'autorità di sicurezza locale (LSA) non riacquisisce il contesto della sessione; si basa invece sul provider del servizio di crittografia per gestire la modifica della sessione.

I certificati client che non contengono un UPN nel subjectAltName campo (SAN) del certificato possono essere abilitati per l'accesso, che supporta un'ampia gamma di certificati e supporta più certificati di accesso nella stessa scheda.

Il supporto per più certificati nella stessa scheda è abilitato per impostazione predefinita. I nuovi tipi di certificato devono essere abilitati tramite Criteri di gruppo.

Se si abilita il criterio Consenti chiavi di firma valide per il provider di credenziali di accesso, tutti i certificati disponibili nella smart card con una chiave di sola firma vengono elencati nella schermata di accesso. Ciò consente agli utenti di selezionare l'esperienza di accesso. Se il criterio è disabilitato o non configurato, i certificati basati sulla chiave della firma della smart card non sono elencati nella schermata di accesso.

Il diagramma seguente illustra il funzionamento dell'accesso con smart card nelle versioni supportate di Windows.

Flusso di accesso alle smart card

Di seguito sono riportati i passaggi eseguiti durante l'accesso a una smart card:

1. Winlogon richiede le informazioni sulle credenziali dell'interfaccia utente di accesso

2. In modo asincrono, viene avviato resource manager della smart card e il provider di credenziali smart card esegue le operazioni seguenti:

   1. Ottiene le informazioni sulle credenziali (un elenco di credenziali note o, se non esistono credenziali, le informazioni sul lettore di smart card rilevate da Windows)
   2. Ottiene un elenco di lettori di smart card (usando l'API WinSCard) e l'elenco di smart card inserite in ognuna di esse
   3. Enumera ogni scheda per verificare che sia presente un certificato di accesso controllato da Criteri di gruppo. Se il certificato è presente, il provider di credenziali della smart card lo copia in una cache temporanea e sicura nel computer o nel terminale

   Nota

   Le voci della cache delle smart card vengono create per i certificati con un nome soggetto o con un identificatore di chiave del soggetto. Se il certificato ha un nome soggetto, viene archiviato con un indice basato sul nome del soggetto e sull'autorità di certificazione. Se viene usato un altro certificato con lo stesso nome soggetto e autorità di certificazione, sostituirà la voce memorizzata nella cache esistente. Una modifica di questo comportamento consente la condizione quando il certificato non ha un nome soggetto, la cache viene creata con un indice basato sull'identificatore della chiave soggetto e sull'autorità di certificazione del certificato. Se un altro certificato ha lo stesso identificatore della chiave soggetto e l'autorità di certificazione del certificato, la voce della cache viene sostituita. Quando i certificati non hanno né un nome soggetto né un identificatore di chiave del soggetto, non viene creata una voce memorizzata nella cache.

   1. Notifica all'interfaccia utente di accesso che dispone di nuove credenziali

3. L'interfaccia utente di accesso richiede le nuove credenziali al provider di credenziali della smart card. Come risposta, il provider di credenziali della smart card fornisce ogni certificato di accesso all'interfaccia utente di accesso e vengono visualizzati i riquadri di accesso corrispondenti. L'utente seleziona un riquadro del certificato di accesso basato su smart card e Windows visualizza una finestra di dialogo PIN

4. L'utente immette il PIN e quindi preme INVIO. Il provider di credenziali della smart card crittografa il PIN

5. Il provider di credenziali che risiede nel sistema LogonUI raccoglie il PIN. Come parte del pacchetto delle credenziali nel provider di credenziali della smart card, i dati vengono inclusi in un pacchetto in una struttura KERB_CERTIFICATE_LOGON. Il contenuto principale della struttura KERB_CERTIFICATE_LOGON sono il PIN della smart card, i dati CSP (ad esempio nome lettore e nome contenitore), il nome utente e il nome di dominio. Il nome utente è obbligatorio se il dominio di accesso non si trova nella stessa foresta perché consente il mapping di un certificato a più account utente

6. Il provider di credenziali esegue il wrapping dei dati (ad esempio il PIN crittografato, il nome del contenitore, il nome del lettore e la specifica della chiave della scheda) e lo invia nuovamente a LogonUI

7. Winlogon presenta i dati da LogonUI all'LSA con le informazioni utente in LSALogonUser

8. LSA chiama il pacchetto di autenticazione Kerberos (SSP Kerberos) per creare una richiesta del servizio di autenticazione Kerberos (KRB_AS_REQ), che contiene un preautenticatore (come specificato in RFC 4556: Crittografia a chiave pubblica per l'autenticazione iniziale in Kerberos (PKINIT)).

   Se l'autenticazione viene eseguita usando un certificato che usa una firma digitale, i dati di preautenticazione sono costituiti dal certificato pubblico dell'utente e dal certificato firmato digitalmente con la chiave privata corrispondente.

   Se l'autenticazione viene eseguita usando un certificato che usa la crittografia della chiave, i dati di preautenticazione sono costituiti dal certificato pubblico dell'utente e dal certificato crittografato con la chiave privata corrispondente.

9. Per firmare la richiesta digitalmente (in base a RFC 4556), viene effettuata una chiamata al CSP corrispondente per un'operazione di chiave privata. Poiché la chiave privata in questo caso viene archiviata in una smart card, viene chiamato il sottosistema smart card e viene completata l'operazione necessaria. Il risultato viene inviato di nuovo al provider di supporto di sicurezza Kerberos.

10. Il provider di servizi condivisi Kerberos invia una richiesta di autenticazione per un ticket-granting-ticket (TGT) (per RFC 4556) al servizio Key Distribution Center (KDC) eseguito in un controller di dominio.

11. Il KDC trova l'oggetto account dell'utente in Active Directory Domain Services (AD DS), come descritto in Dettaglio nei mapping e nei requisiti dei certificati client e usa il certificato dell'utente per verificare la firma.

12. Il KDC convalida il certificato dell'utente (ora, percorso e stato di revoca) per assicurarsi che il certificato proveni da un'origine attendibile. Il KDC usa CryptoAPI per compilare un percorso di certificazione dal certificato dell'utente a un certificato dell'autorità di certificazione radice (CA) che si trova nell'archivio radice nel controller di dominio. Il KDC usa quindi CryptoAPI per verificare la firma digitale sull'autenticatore firmato incluso nei campi dei dati di preautenticazione. Il controller di dominio verifica la firma e usa la chiave pubblica del certificato dell'utente per dimostrare che la richiesta è stata originata dal proprietario della chiave privata che corrisponde alla chiave pubblica. Il KDC verifica inoltre che l'autorità di certificazione sia attendibile e venga visualizzata nell'archivio certificati NTAUTH.

13. Il servizio KDC recupera le informazioni sull'account utente da Active Directory Domain Services. Il KDC costruisce un TGT, basato sulle informazioni sull'account utente recuperate da Active Directory Domain Services. I campi dei dati di autorizzazione del TGT includono l'identificatore di sicurezza (SID) dell'utente, i SID per i gruppi di dominio universali e globali a cui appartiene l'utente e ,in un ambiente multidominio, i SID per tutti i gruppi universali di cui l'utente è membro.

14. Il controller di dominio restituisce il TGT al client come parte della risposta KRB_AS_REP.

    Nota

    Il pacchetto KRB_AS_REP è costituito da:

    • Certificato dell'attributo privilege (PAC)
    • SID dell'utente
    • SID di tutti i gruppi di cui l'utente è membro
    • Una richiesta per il servizio di concessione di ticket (TGS)
    • Dati di preautenticazione

    Il TGT viene crittografato con la chiave master del KDC e la chiave di sessione viene crittografata con una chiave temporanea. Questa chiave temporanea è derivata in base a RFC 4556. Usando CryptoAPI, la chiave temporanea viene decrittografata. Nell'ambito del processo di decrittografia, se la chiave privata si trova in una smart card, viene effettuata una chiamata al sottosistema smart card usando il provider di servizi di configurazione specificato per estrarre il certificato corrispondente alla chiave pubblica dell'utente. Le chiamate programmatiche per il certificato includono CryptAcquireContext, CryptSetProvParam con PIN, CryptgetUserKey e CryptGetKeyParam. Dopo aver ottenuto la chiave temporanea, il provider di servizi condivisi Kerberos decrittografa la chiave di sessione.

15. Il client convalida la risposta dal KDC (ora, percorso e stato di revoca). Innanzitutto verifica la firma del KDC mediante la costruzione di un percorso di certificazione dal certificato del KDC a una CA radice attendibile e quindi usa la chiave pubblica del KDC per verificare la firma di risposta.

16. Ora che è stato ottenuto un TGT, il client ottiene un ticket di servizio, che viene usato per accedere al computer locale.

17. Con esito positivo, LSA archivia i ticket e restituisce un messaggio di esito positivo a LSALogonUser. Dopo l'emissione di questo messaggio di esito positivo, viene selezionato e impostato il profilo utente per il dispositivo, viene creata un'istanza dell'aggiornamento di Criteri di gruppo e vengono eseguite altre azioni.

18. Dopo il caricamento del profilo utente, il servizio di propagazione della certificazione (CertPropSvc) rileva questo evento, legge i certificati dalla smart card (inclusi i certificati radice) e li popola nell'archivio certificati dell'utente (MYSTORE)

19. La comunicazione da CSP a gestione risorse smart card avviene nel canale LRPC.

20. Al termine dell'autenticazione, i certificati vengono propagati nell'archivio dell'utente in modo asincrono dal servizio di propagazione dei certificati (CertPropSvc).

21. Quando la scheda viene rimossa, i certificati nell'archivio cache protetto temporaneo vengono rimossi. I certificati non sono più disponibili per l'accesso, ma rimangono nell'archivio certificati dell'utente.

Per altre informazioni sul protocollo Kerberos, vedere Microsoft Kerberos.

Per impostazione predefinita, il KDC verifica che il certificato del client contenga l'EKU di autenticazione client smart card szOID_KP_SMARTCARD_LOGON. Tuttavia, se abilitata, l'impostazione criteri di gruppo Consenti certificati senza attributo certificato di utilizzo della chiave estesa consente al KDC di non richiedere l'EKU SC-LOGON. L'EKU SC-LOGON non è necessario per i mapping degli account basati sulla chiave pubblica.

Certificato KDC

Servizi certificati Active Directory offre tre tipi di modelli di certificato:

• Controller di dominio
• Autenticazione del controller di dominio
• Autenticazione Kerberos

A seconda della configurazione del controller di dominio, uno di questi tipi di certificati viene inviato come parte del pacchetto AS_REP.

Mapping e requisiti dei certificati client

I requisiti del certificato sono elencati in base alle versioni del sistema operativo Windows. Il mapping dei certificati descrive il mapping delle informazioni del certificato all'account utente.

Requisiti dei certificati

Mapping dei certificati client

Il mapping dei certificati si basa sul nome upn contenuto nel campo subjectAltName (SAN) del certificato. Sono supportati anche i certificati client che non contengono informazioni nel campo SAN.

SSL/TLS può eseguire il mapping dei certificati che non dispongono di SAN e il mapping viene eseguito usando gli attributi AltSecID negli account client. L'AltSecID X509, usato dall'autenticazione client SSL/TLS, è nel formato "X509: <Issuer Name><Subject Name. <Subject Name> E <Issuer Name> sono tratti dal certificato client, con '\r' e '\n' sostituiti con ','.

Punti di distribuzione della lista di revoche di certificati

UPN nel campo Nome alternativo soggetto

Campi Soggetto e Autorità di certificazione

Questo mapping degli account è supportato dal KDC oltre ad altri sei metodi di mapping. La figura seguente illustra un flusso di logica di mapping degli account utente usato dal KDC.

Flusso generale dell'elaborazione dei certificati per l'accesso

L'oggetto certificato viene analizzato per cercare il contenuto per eseguire il mapping dell'account utente.

• Quando viene fornito un nome utente con il certificato, il nome utente viene usato per individuare l'oggetto account. Questa operazione è la più veloce, perché si verifica la corrispondenza delle stringhe
• Quando viene fornito solo l'oggetto certificato, vengono eseguite più operazioni per individuare il nome utente per eseguire il mapping del nome utente a un oggetto account
• Quando non sono disponibili informazioni sul dominio per l'autenticazione, il dominio locale viene usato per impostazione predefinita. Se un altro dominio deve essere usato per la ricerca, è necessario fornire un hint per il nome di dominio per eseguire il mapping e l'associazione

Il mapping basato sugli attributi generici non è possibile perché non esiste un'API generica per recuperare gli attributi da un certificato. Attualmente, il primo metodo che individua un account arresta correttamente la ricerca. Tuttavia, si verifica un errore di configurazione se due metodi eseguono il mapping dello stesso certificato a account utente diversi quando il client non fornisce il nome client tramite gli hint di mapping.

La figura seguente illustra il processo di mapping degli account utente per l'accesso nella directory visualizzando varie voci nel certificato.

Logica di elaborazione dei certificati

NT_AUTH criterio è descritto meglio nella sezione CERT_CHAIN_POLICY_NT_AUTH parametro della funzione CertVerifyCertificateChainPolicy. Per altre informazioni, vedere CertVerifyCertificateChainPolicy.

Accesso con smart card per un singolo utente con un certificato in più account

È possibile eseguire il mapping di un singolo certificato utente a più account. Ad esempio, un utente potrebbe essere in grado di accedere a un account utente e anche di accedere come amministratore di dominio. Il mapping viene eseguito usando l'AltSecID costruito in base agli attributi degli account client. Per informazioni su come viene valutato questo mapping, vedere Mapping e requisiti dei certificati client.

In base alle informazioni disponibili nel certificato, le condizioni di accesso sono:

1. Se nel certificato non è presente alcun UPN:
   1. L'accesso può verificarsi nella foresta locale o in un'altra foresta se un singolo utente con un certificato deve accedere a account diversi
   2. È necessario specificare un hint se il mapping non è univoco (ad esempio, se più utenti sono mappati allo stesso certificato)
2. Se nel certificato è presente un UPN:
   1. Il certificato non può essere mappato a più utenti nella stessa foresta
   2. Il certificato può essere mappato a più utenti in foreste diverse. Per consentire a un utente di accedere ad altre foreste, è necessario fornire un hint X509 all'utente

Accesso con smart card per più utenti in un singolo account

Un gruppo di utenti potrebbe accedere a un singolo account , ad esempio un account amministratore. Per tale account, i certificati utente vengono mappati in modo che siano abilitati per l'accesso.

È possibile eseguire il mapping di diversi certificati distinti a un singolo account. Perché funzioni correttamente, il certificato non può avere UPN.

Ad esempio, se Certificate1 ha CN=CNName1, Certificate2 ha CN=User1 e Certificate3 ha CN=User2, è possibile eseguire il mapping di AltSecID di questi certificati a un singolo account usando il mapping dei nomi utenti e computer di Active Directory.

Accesso tramite smart card tra foreste

Affinché il mapping degli account funzioni tra foreste, in particolare nei casi in cui non sono disponibili informazioni sufficienti sul certificato, l'utente potrebbe immettere un suggerimento sotto forma di nome utente, ad esempio dominio\utente, o un UPN completo, ad user@contoso.comesempio .

Supporto OCSP per PKINIT

Online Certificate Status Protocol (OCSP), definito in RFC 2560, consente alle applicazioni di ottenere informazioni tempestive sullo stato di revoca di un certificato. Poiché le risposte OCSP sono piccole e ben associate, i client vincolati potrebbero voler usare OCSP per verificare la validità dei certificati per Kerberos nel KDC, per evitare la trasmissione di CRL di grandi dimensioni e per risparmiare larghezza di banda sulle reti vincolate. Per informazioni sulle chiavi del Registro di sistema CRL, vedere Criteri di gruppo smart card e Impostazioni del Registro di sistema.

I KDC in Windows tentano di ottenere le risposte OCSP e usarle quando disponibili. Questo comportamento non può essere disabilitato. CryptoAPI per OCSP memorizza nella cache le risposte OCSP e lo stato delle risposte. Il KDC supporta solo le risposte OCSP per il certificato del firmatario.

I computer client Windows tentano di richiedere le risposte OCSP e usarle nella risposta quando sono disponibili. Questo comportamento non può essere disabilitato.

Requisiti del certificato radice della smart card per l'uso con l'accesso al dominio

Per il funzionamento dell'accesso in un dominio basato su smart card, il certificato smart card deve soddisfare le condizioni seguenti:

• Il certificato radice KDC nella smart card deve avere un punto di distribuzione CRL HTTP elencato nel relativo certificato
• Nel certificato di accesso della smart card deve essere elencato il punto di distribuzione CRL HTTP
• Il punto di distribuzione CRL deve avere un CRL valido pubblicato e un CRL delta, se applicabile, anche se il punto di distribuzione CRL è vuoto
• Il certificato smart card deve contenere uno dei seguenti elementi:
  • Campo soggetto che contiene il nome di dominio DNS nel nome distinto. In caso contrario, la risoluzione di un dominio appropriato ha esito negativo, quindi Servizi Desktop remoto e l'accesso al dominio con la smart card hanno esito negativo
  • UPN in cui il nome di dominio viene risolto nel dominio effettivo. Ad esempio, se il nome di dominio è Engineering.Corp.Contoso, l'UPN è username@engineering.corp.contoso.com. Se una parte del nome di dominio viene omessa, il client Kerberos non riesce a trovare il dominio appropriato

Per consentire l'accesso della smart card a un dominio in queste versioni, eseguire le operazioni seguenti:

1. Abilitare i punti di distribuzione CRL HTTP nell'autorità di certificazione
2. Riavviare l'autorità di certificazione
3. Rilasciare nuovamente il certificato KDC
4. Rilasciare o rilasciare nuovamente il certificato di accesso alla smart card
5. Propagare il certificato radice aggiornato alla smart card che si vuole usare per l'accesso al dominio

La soluzione alternativa consiste nell'abilitare l'impostazione Criteri di gruppo Consenti hint nome utente (chiave del Registro di sistema X509HintsNeeded ), che consente all'utente di fornire un hint nell'interfaccia utente delle credenziali per l'accesso al dominio.

Se il computer client non è aggiunto al dominio o se è aggiunto a un dominio diverso, il computer client può risolvere il dominio del server solo esaminando il nome distinto nel certificato, non l'UPN. Per il funzionamento di questo scenario, il certificato richiede un soggetto completo, incluso DC=<DomainControllerName>, per la risoluzione dei nomi di dominio.

Per distribuire i certificati radice in una smart card per il dominio attualmente aggiunto, è possibile usare il comando seguente:

certutil.exe -scroots update

Per altre informazioni su questa opzione per lo strumento da riga di comando, vedere -SCRoots.