autenticazione Windows Hello for Business
Windows Hello for Business'autenticazione è un'autenticazione a due fattori senza password. L'autenticazione con Windows Hello for Business offre un'esperienza di accesso pratica che autentica l'utente nelle risorse di Microsoft Entra ID e Active Directory.
Microsoft Entra dispositivi aggiunti eseguono l'autenticazione in Microsoft Entra ID durante l'accesso e possono, facoltativamente, eseguire l'autenticazione in Active Directory. Microsoft Entra dispositivi aggiunti ibridi eseguono l'autenticazione in Active Directory durante l'accesso e si autenticano in Microsoft Entra ID in background.
Microsoft Entra aggiungere l'autenticazione a Microsoft Entra ID
Nota
Tutti i dispositivi aggiunti Microsoft Entra eseguono l'autenticazione con Windows Hello for Business per Microsoft Entra ID allo stesso modo. Il tipo di attendibilità Windows Hello for Business influisce solo sul modo in cui il dispositivo esegue l'autenticazione ad ACTIVE Directory locale.
| Fase | Descrizione |
|---|---|
| A | L'autenticazione inizia quando l'utente chiude la schermata di blocco, che attiva Winlogon per visualizzare il provider di credenziali Windows Hello for Business. L'utente fornisce il movimento di Windows Hello (PIN o biometrica). Il provider di credenziali crea il pacchetto di queste credenziali e le restituisce a Winlogon. Winlogon passa le credenziali raccolte a lsass. Lsass passa le credenziali raccolte al provider di supporto per la sicurezza dell'autenticazione cloud, definito provider ap cloud. |
| B | Il provider di app cloud richiede un nonce da Microsoft Entra ID. Microsoft Entra ID restituisce un nonce. Il provider ap cloud firma il nonce usando la chiave privata dell'utente e restituisce il nonce firmato al Microsoft Entra ID. |
| C | Microsoft Entra ID convalida il nonce firmato usando la chiave pubblica registrata in modo sicuro dell'utente rispetto alla firma nonce. Microsoft Entra ID convalida quindi il nonce firmato restituito e crea un PRT con la chiave di sessione crittografata per la chiave di trasporto del dispositivo e la restituisce al provider di ap cloud. |
| D | Il provider di ap cloud riceve il token PRT crittografato con la chiave di sessione. Usando la chiave di trasporto privata del dispositivo, il provider di ap cloud decrittografa la chiave di sessione e protegge la chiave di sessione usando il TPM del dispositivo. |
| E | Il provider di ap cloud restituisce una risposta di autenticazione corretta a lsass. Lsass memorizza nella cache il token di aggiornamento primario e informa Winlogon dell'autenticazione riuscita. Winlogon crea una sessione di accesso, carica il profilo dell'utente e avvia explorer.exe. |
Microsoft Entra aggiungere l'autenticazione ad Active Directory usando l'attendibilità Kerberos cloud
| Fase | Descrizione |
|---|---|
| A | L'autenticazione in Active Directory da un dispositivo aggiunto Microsoft Entra inizia con il primo tentativo dell'utente di usare una risorsa che richiede l'autenticazione Kerberos. Il provider di supporto per la sicurezza Kerberos, ospitato in lsass, usa i metadati della chiave Windows Hello for Business per ottenere un suggerimento sul dominio dell'utente. Usando l'hint, il provider usa il servizio DClocator per individuare un controller di dominio. |
| B | Dopo aver individuato un controller di dominio, il provider Kerberos invia un TGT parziale ricevuto da Microsoft Entra ID da un'autenticazione Microsoft Entra precedente al controller di dominio. Il TGT parziale contiene solo il SID utente ed è firmato da Microsoft Entra Kerberos. Il controller di dominio verifica che il TGT parziale sia valido. In caso di esito positivo, il KDC restituisce un TGT al client. |
Microsoft Entra aggiungere l'autenticazione ad Active Directory usando una chiave
| Fase | Descrizione |
|---|---|
| A | L'autenticazione in Active Directory da un dispositivo aggiunto Microsoft Entra inizia con il primo tentativo dell'utente di usare una risorsa che richiede l'autenticazione Kerberos. Il provider di supporto per la sicurezza Kerberos, ospitato in lsass, usa i metadati della chiave Windows Hello for Business per ottenere un suggerimento sul dominio dell'utente. Usando l'hint, il provider usa il servizio DClocator per individuare un controller di dominio. Dopo che il provider ha individuato un controller di dominio, il provider usa la chiave privata per firmare i dati di preautenticazione Kerberos. |
| B | Il provider Kerberos invia i dati di preautenticazione firmati e la relativa chiave pubblica (sotto forma di certificato autofirmato) al servizio Centro distribuzione chiavi (KDC) in esecuzione nel controller di dominio sotto forma di KERB_AS_REQ. Il controller di dominio determina che il certificato è un certificato autofirma. Recupera la chiave pubblica dal certificato incluso nel KERB_AS_REQ e cerca la chiave pubblica in Active Directory. Convalida che l'UPN per la richiesta di autenticazione corrisponda all'UPN registrato in Active Directory e convalida i dati di preautenticazione firmati usando la chiave pubblica da Active Directory. In caso di esito positivo, il KDC restituisce un TGT al client con il relativo certificato in un KERB_AS_REP. |
| C | Il provider Kerberos garantisce che possa considerare attendibile la risposta del controller di dominio. In primo luogo, garantisce che il certificato KDC venga concatenato a un certificato radice considerato attendibile dal dispositivo. Successivamente, garantisce che il certificato sia entro il periodo di validità e che non sia stato revocato. Il provider Kerberos verifica quindi che il certificato disponga dell'autenticazione KDC presente e che il nome alternativo del soggetto elencato nel certificato del KDC corrisponda al nome di dominio a cui l'utente sta eseguendo l'autenticazione. Dopo aver passato questi criteri, Kerberos restituisce il TGT a lsass, dove viene memorizzato nella cache e usato per le successive richieste di ticket di servizio. |
Nota
È possibile che un dominio locale sia federato con Microsoft Entra ID. Dopo aver effettuato correttamente il provisioning di Windows Hello for Business PIN/Bio nel dispositivo aggiunto Microsoft Entra, qualsiasi account di accesso futuro di Windows Hello for Business (PIN/Bio) eseguirà direttamente l'autenticazione con Microsoft Entra ID per ottenere PRT e attivare l'autenticazione sul controller di dominio (se los-to-dc è disponibile) per ottenere Kerberos. Non usa più AD FS per eseguire l'autenticazione per gli accessi Windows Hello for Business.
Microsoft Entra aggiungere l'autenticazione ad Active Directory usando un certificato
| Fase | Descrizione |
|---|---|
| A | L'autenticazione in Active Directory da un dispositivo aggiunto Microsoft Entra inizia con il primo tentativo dell'utente di usare una risorsa che richiede l'autenticazione Kerberos. Il provider di supporto per la sicurezza Kerberos, ospitato in lsass, usa le informazioni del certificato per ottenere un suggerimento sul dominio dell'utente. Kerberos può usare il nome distinto dell'utente trovato nell'oggetto del certificato oppure il nome dell'entità utente dell'utente trovato nel nome alternativo soggetto del certificato. Usando l'hint, il provider usa il servizio DClocator per individuare un controller di dominio. Dopo che il provider ha individuato un controller di dominio attivo, il provider usa la chiave privata per firmare i dati di preautenticazione Kerberos. |
| B | Il provider Kerberos invia i dati di preautenticazione firmati e il certificato dell'utente, che include la chiave pubblica, al servizio Centro distribuzione chiavi (KDC) in esecuzione nel controller di dominio sotto forma di KERB_AS_REQ. Il controller di dominio determina che il certificato non è certificato autofirma. Il controller di dominio garantisce che il certificato venga concatenato al certificato radice attendibile, sia compreso nel periodo di validità, possa essere usato per l'autenticazione e non sia stato revocato. Recupera la chiave pubblica e l'UPN dal certificato incluso nel KERB_AS_REQ e cerca l'UPN in Active Directory. Convalida i dati di preautenticazione firmati usando la chiave pubblica del certificato. In caso di esito positivo, il KDC restituisce un TGT al client con il relativo certificato in un KERB_AS_REP. |
| C | Il provider Kerberos garantisce che possa considerare attendibile la risposta del controller di dominio. In primo luogo, garantisce che il certificato KDC venga concatenato a un certificato radice considerato attendibile dal dispositivo. Successivamente, garantisce che il certificato sia entro il periodo di validità e che non sia stato revocato. Il provider Kerberos verifica quindi che il certificato disponga dell'autenticazione KDC presente e che il nome alternativo del soggetto elencato nel certificato del KDC corrisponda al nome di dominio a cui l'utente sta eseguendo l'autenticazione. Dopo aver passato questi criteri, Kerberos restituisce il TGT a lsass, dove viene memorizzato nella cache e usato per le successive richieste di ticket di servizio. |
Nota
È possibile che un dominio locale sia federato con Microsoft Entra ID. Dopo aver effettuato correttamente il provisioning di Windows Hello for Business PIN/Bio on, qualsiasi account di accesso futuro dell'accesso Windows Hello for Business (PIN/Bio) eseguirà direttamente l'autenticazione con Microsoft Entra ID per ottenere PRT, nonché eseguire l'autenticazione nel controller di dominio (se los-to-dc è disponibile) per ottenere Kerberos come indicato in precedenza. La federazione di AD FS viene usata solo quando vengono effettuate chiamate PRT aziendali dal client. È necessario che il writeback del dispositivo sia abilitato per ottenere "Enterprise PRT" dalla federazione.
Microsoft Entra l'autenticazione di join ibrido usando l'attendibilità Kerberos cloud
| Fase | Descrizione |
|---|---|
| A | L'autenticazione inizia quando l'utente chiude la schermata di blocco, che attiva Winlogon per visualizzare il provider di credenziali Windows Hello for Business. L'utente fornisce il movimento di Windows Hello (PIN o biometrica). Il provider di credenziali crea il pacchetto di queste credenziali e le restituisce a Winlogon. Winlogon passa le credenziali raccolte a lsass. Lsass esegue query Windows Hello for Business criteri per verificare se l'attendibilità Kerberos cloud è abilitata. Se l'attendibilità Kerberos cloud è abilitata, Lsass passa le credenziali raccolte al provider di supporto per la sicurezza dell'autenticazione cloud o al punto di accesso cloud. Cloud AP richiede un nonce da Microsoft Entra ID. Microsoft Entra ID restituisce un nonce. |
| B | Cloud AP firma il nonce usando la chiave privata dell'utente e restituisce il nonce firmato a Microsoft Entra ID. |
| C | Microsoft Entra ID convalida il nonce firmato usando la chiave pubblica registrata in modo sicuro dell'utente rispetto alla firma nonce. Dopo aver convalidato la firma, Microsoft Entra ID convalida il nonce firmato restituito. Dopo aver convalidato il nonce, Microsoft Entra ID crea un PRT con la chiave di sessione crittografata nella chiave di trasporto del dispositivo e crea un TGT parziale da Microsoft Entra Kerberos e li restituisce al punto di accesso cloud. |
| D | Cloud AP riceve il token PRT crittografato con la chiave di sessione. Usando la chiave di trasporto privata del dispositivo, Cloud AP decrittografa la chiave di sessione e protegge la chiave di sessione usando il TPM del dispositivo (se disponibile). Punto di accesso cloud restituisce una risposta di autenticazione corretta a lsass. Lsass memorizza nella cache il valore PRT e il TGT parziale. |
| E | Il provider di supporto per la sicurezza Kerberos, ospitato in lsass, usa i metadati della chiave Windows Hello for Business per ottenere un suggerimento sul dominio dell'utente. Usando l'hint, il provider usa il servizio DClocator per individuare un controller di dominio. Dopo aver individuato un controller di dominio attivo, il provider Kerberos invia il TGT parziale ricevuto da Microsoft Entra ID al controller di dominio. Il TGT parziale contiene solo il SID utente ed è firmato da Microsoft Entra Kerberos. Il controller di dominio verifica che il TGT parziale sia valido. In caso di esito positivo, il KDC restituisce un TGT al client. Kerberos restituisce il TGT a lsass, dove viene memorizzato nella cache e usato per le successive richieste di ticket di servizio. Lsass informa Winlogon dell'autenticazione riuscita. Winlogon crea una sessione di accesso, carica il profilo dell'utente e avvia explorer.exe. |
Microsoft Entra l'autenticazione di join ibrido usando una chiave
| Fase | Descrizione |
|---|---|
| A | L'autenticazione inizia quando l'utente chiude la schermata di blocco, che attiva Winlogon per visualizzare il provider di credenziali Windows Hello for Business. L'utente fornisce il movimento di Windows Hello (PIN o biometrica). Il provider di credenziali crea il pacchetto di queste credenziali e le restituisce a Winlogon. Winlogon passa le credenziali raccolte a lsass. Lsass passa le credenziali raccolte al provider di supporto di sicurezza Kerberos. Il provider Kerberos ottiene gli hint di dominio dalla workstation aggiunta al dominio per individuare un controller di dominio per l'utente. |
| B | Il provider Kerberos invia i dati di preautenticazione firmati e la chiave pubblica dell'utente (sotto forma di certificato autofirmato) al servizio Centro distribuzione chiavi (KDC) in esecuzione nel controller di dominio sotto forma di KERB_AS_REQ. Il controller di dominio determina che il certificato è un certificato autofirma. Recupera la chiave pubblica dal certificato incluso nel KERB_AS_REQ e cerca la chiave pubblica in Active Directory. Convalida che l'UPN per la richiesta di autenticazione corrisponda all'UPN registrato in Active Directory e convalida i dati di preautenticazione firmati usando la chiave pubblica da Active Directory. In caso di esito positivo, il KDC restituisce un TGT al client con il relativo certificato in un KERB_AS_REP. |
| C | Il provider Kerberos garantisce che possa considerare attendibile la risposta del controller di dominio. In primo luogo, garantisce che il certificato KDC venga concatenato a un certificato radice considerato attendibile dal dispositivo. Successivamente, garantisce che il certificato sia entro il periodo di validità e che non sia stato revocato. Il provider Kerberos verifica quindi che il certificato disponga dell'autenticazione KDC presente e che il nome alternativo del soggetto elencato nel certificato del KDC corrisponda al nome di dominio a cui l'utente sta eseguendo l'autenticazione. |
| D | Dopo aver passato questi criteri, Kerberos restituisce il TGT a lsass, dove viene memorizzato nella cache e usato per le successive richieste di ticket di servizio. |
| E | Lsass informa Winlogon dell'autenticazione riuscita. Winlogon crea una sessione di accesso, carica il profilo dell'utente e avvia explorer.exe. |
| F | Mentre Windows carica il desktop dell'utente, lsass passa le credenziali raccolte al provider di supporto di sicurezza di Cloud Authentication, noto come provider di ap cloud. Il provider di app cloud richiede un nonce da Microsoft Entra ID. Microsoft Entra ID restituisce un nonce. |
| G | Il provider ap cloud firma il nonce usando la chiave privata dell'utente e restituisce il nonce firmato al Microsoft Entra ID. Microsoft Entra ID convalida il nonce firmato usando la chiave pubblica registrata in modo sicuro dell'utente rispetto alla firma nonce. Dopo aver convalidato la firma, Microsoft Entra ID convalida il nonce firmato restituito. Dopo aver convalidato il nonce, Microsoft Entra ID crea un PRT con la chiave di sessione crittografata nella chiave di trasporto del dispositivo e la restituisce al provider di ap cloud. Il provider di ap cloud riceve il token PRT crittografato con la chiave di sessione. Usando la chiave di trasporto privata del dispositivo, il provider di ap cloud decrittografa la chiave di sessione e protegge la chiave di sessione usando il TPM del dispositivo. Il provider di ap cloud restituisce una risposta di autenticazione corretta a lsass. Lsass memorizza nella cache il PRT. |
Importante
Nel modello di distribuzione precedente, un utente di cui è stato effettuato il provisioning non sarà in grado di accedere usando Windows Hello for Business fino a quando (a) Microsoft Entra Connect non sincronizza correttamente la chiave pubblica con l'Active Directory locale e (b) il dispositivo non ha una linea di vista per il controller di dominio per la prima volta.
Microsoft Entra l'autenticazione join ibrida con un certificato
| Fase | Descrizione |
|---|---|
| A | L'autenticazione inizia quando l'utente chiude la schermata di blocco, che attiva Winlogon per visualizzare il provider di credenziali Windows Hello for Business. L'utente fornisce il movimento di Windows Hello (PIN o biometrica). Il provider di credenziali crea il pacchetto di queste credenziali e le restituisce a Winlogon. Winlogon passa le credenziali raccolte a lsass. Lsass passa le credenziali raccolte al provider di supporto di sicurezza Kerberos. Il provider Kerberos ottiene gli hint di dominio dalla workstation aggiunta al dominio per individuare un controller di dominio per l'utente. |
| B | Il provider Kerberos invia i dati di preautenticazione firmati e il certificato dell'utente, che include la chiave pubblica, al servizio Centro distribuzione chiavi (KDC) in esecuzione nel controller di dominio sotto forma di KERB_AS_REQ. Il controller di dominio determina che il certificato non è certificato autofirma. Il controller di dominio garantisce che il certificato venga concatenato al certificato radice attendibile, sia compreso nel periodo di validità, possa essere usato per l'autenticazione e non sia stato revocato. Recupera la chiave pubblica e l'UPN dal certificato incluso nel KERB_AS_REQ e cerca l'UPN in Active Directory. Convalida i dati di preautenticazione firmati usando la chiave pubblica del certificato. In caso di esito positivo, il KDC restituisce un TGT al client con il relativo certificato in un KERB_AS_REP. |
| C | Il provider Kerberos garantisce che possa considerare attendibile la risposta del controller di dominio. In primo luogo, garantisce che il certificato KDC venga concatenato a un certificato radice considerato attendibile dal dispositivo. Successivamente, garantisce che il certificato sia entro il periodo di validità e che non sia stato revocato. Il provider Kerberos verifica quindi che il certificato disponga dell'autenticazione KDC presente e che il nome alternativo del soggetto elencato nel certificato del KDC corrisponda al nome di dominio a cui l'utente sta eseguendo l'autenticazione. |
| D | Dopo aver passato questi criteri, Kerberos restituisce il TGT a lsass, dove viene memorizzato nella cache e usato per le successive richieste di ticket di servizio. |
| E | Lsass informa Winlogon dell'autenticazione riuscita. Winlogon crea una sessione di accesso, carica il profilo dell'utente e avvia explorer.exe. |
| F | Mentre Windows carica il desktop dell'utente, lsass passa le credenziali raccolte al provider di supporto di sicurezza di Cloud Authentication, noto come provider di ap cloud. Il provider di app cloud richiede un nonce da Microsoft Entra ID. Microsoft Entra ID restituisce un nonce. |
| G | Il provider ap cloud firma il nonce usando la chiave privata dell'utente e restituisce il nonce firmato al Microsoft Entra ID. Microsoft Entra ID convalida il nonce firmato usando la chiave pubblica registrata in modo sicuro dell'utente rispetto alla firma nonce. Dopo aver convalidato la firma, Microsoft Entra ID convalida il nonce firmato restituito. Dopo aver convalidato il nonce, Microsoft Entra ID crea un PRT con la chiave di sessione crittografata nella chiave di trasporto del dispositivo e la restituisce al provider di ap cloud. Il provider di ap cloud riceve il token PRT crittografato con la chiave di sessione. Usando la chiave di trasporto privata del dispositivo, il provider di ap cloud decrittografa la chiave di sessione e protegge la chiave di sessione usando il TPM del dispositivo. Il provider di ap cloud restituisce una risposta di autenticazione corretta a lsass. Lsass memorizza nella cache il PRT. |
Importante
Nel modello di distribuzione precedente, un nuovo utente di cui è stato effettuato il provisioning non sarà in grado di accedere usando Windows Hello for Business a meno che il dispositivo non abbia una linea di visualizzazione per il controller di dominio.