Come implementare Windows Hello for Business in un dominio ibrido

Se hai tecnici sul campo o utenti con computer portatili e tablet Chi è costantemente incollato alla tastiera virtuale di solito si stanca di digitare la password più e più volte. Windows Hello per le aziende Windows Hello for Business è stato creato proprio per questo scopo: sostituire la password con metodi di accesso più comodi e sicuri, come PIN, impronta digitale o riconoscimento facciale, mantenendo al contempo l'integrazione con il dominio e con Microsoft Login ID (precedentemente Azure AD).

Il problema è che, quando inizi a leggere la documentazione ufficiale, concetti come Modelli di implementazione, tipi di fiducia, Kerberos nel cloud, PKI, AD FS, MFA, sincronizzazione delle chiavi…ed è facile sentirsi sopraffatti, soprattutto se non si vuole avere a che fare troppo con i controller di dominio. In questa guida, analizzeremo tutto con calma, spiegando cosa serve realmente per implementare Windows Hello in un ambiente di dominio (inclusi gli ambienti ibridi) e quali parti si possono ignorare a seconda dello scenario specifico.

Che cos'è Windows Hello for Business e in cosa si differenzia dal "normale" Windows Hello?

Windows Hello for business è la versione aziendale di Windows Hello che sostituisce le password con credenziali della chiave pubblica collegate al dispositivoNon viene utilizzato solo per sbloccare il computer: viene utilizzato anche per autenticarsi con Active Directory e/o ID Microsoft Entra.

In pratica, l'utente effettua l'accesso utilizzando un PIN, impronta digitale o riconoscimento faccialeMa in realtà, Windows utilizza una coppia di chiavi asimmetriche memorizzate e protette sul dispositivo (preferibilmente nel TPM) per autenticarsi presso il provider di identità (IdP): può trattarsi di Microsoft Entra ID, di un ambiente ibrido o di un ambiente puramente locale con AD FS.

La chiave privata non lascia mai il computer; La chiave pubblica è registrata con Microsoft Enter ID o AD FS durante la registrazione. Da lì, l'utente può eseguire l'SSO verso risorse cloud e/o risorse on-premise a seconda del modello di implementazione scelto.

Modelli di implementazione di Windows Hello per le aziende

Prima di intervenire su GPO o Intune, è importante chiarire cosa modello di implementazione Si adatta al tuo ambiente. Windows Hello for Business distingue tre scenari principali, a seconda di dove risiedono le identità e le risorse:

Solo nel cloudOrganizzazioni che dispongono esclusivamente di identità Microsoft Entra ID e non accedono a risorse locali. I dispositivi si connettono a Microsoft Entra (tramite Azure AD join) o si registrano, e tutto ciò di cui l'utente ha bisogno (SharePoint Online, OneDrive, app SaaS, ecc.) è disponibile nel cloud. Non sono necessari controller di dominio locali né certificati per VPN o altri servizi locali.

IbridaLe aziende che sincronizzano le identità tra Active Directory locale e Microsoft Entra ID in genere dispongono di dispositivi aggiunti a un dominio tradizionale, dispositivi aggiunti ad Azure AD o dispositivi ibridi, e desiderano l'SSO sia per le risorse locali (server di file, applicazioni legacy) sia per le risorse cloud. Questo è lo scenario più comune e interessante quando ci si chiede come implementare Windows Hello in un dominio senza causare problemi.

Locale (in loco)Organizzazioni senza identità cloud o applicazioni Microsoft Entra ID. Tutto risiede in Active Directory e le app sono integrate con AD o AD FS. Ciononostante, possono sfruttare Windows Hello for Business per avere un esperienza senza password e l'SSO all'interno dell'ambiente locale stesso.

Il modello che scegli determina quali servizi ti servono (ad esempio, Microsoft Entra Connect, AD FS, PKI, Kerberos nel cloud, ecc.) e quale tipo di attendibilità utilizzerai per comunicare con Active Directory.

Tipi di fiducia: come Windows Hello si autentica rispetto al dominio

El tipo di fiducia Questo definisce il modo in cui i client di Windows Hello for Business si autenticano in Active Directory. È un concetto fondamentale quando si desidera che gli utenti possano utilizzare un PIN o un'impronta digitale su un PC aggiunto al dominio per accedere alle risorse locali.

Importante: questo tipo di fiducia si applica solo quando c'è Active Directory localePer l'autenticazione con Microsoft Entra ID, Windows Hello utilizza sempre una chiave (non un certificato), ad eccezione di specifici scenari con smart card in ambienti federati.

I tre tipi di trust tra cui puoi scegliere sono:

1. Attendibilità Kerberos nel cloud
In questo modello, gli utenti ottengono il loro TGT di Active Directory tramite Microsoft introduce KerberosMicrosoft Entra ID rilascia un ticket che i controller di dominio locali accettano, i quali a loro volta continuano a rilasciare ticket di servizio Kerberos ed eseguire l'autorizzazione. Questo è lo stesso meccanismo utilizzato per l'accesso con chiavi di sicurezza FIDO2.

I principali vantaggi dell'affidabilità Kerberos nel cloud sono:

• Non è necessario implementare una PKI né modificare l'infrastruttura di certificati esistente.
• Non è necessario sincronizzare le chiavi pubbliche tra Microsoft Entra ID e Active Directory per consentire all'utente di accedere alle risorse locali, eliminando così qualsiasi ritardo tra la registrazione a Windows Hello e la possibilità di autenticarsi al dominio.
• Connettori Accedi con le chiavi di sicurezza FIDO2 con una configurazione aggiuntiva molto leggera.

Tuttavia, la fiducia Kerberos nel cloud richiede l'implementazione Microsoft introduce Kerberos e che tu soddisfi le versioni minime di Windows e Windows Server (lo vedremo più avanti nei requisiti di sistema).

2. Fiducia chiave
In questo caso, gli utenti si autenticano rispetto all'Active Directory locale utilizzando un chiave collegata al dispositivo creato durante la registrazione a Windows Hello. Il client richiede un TGT Kerberos utilizzando quella chiave. Affinché ciò funzioni, è necessario che siano presenti determinati certificati ai controller di dominio, poiché Kerberos utilizzerà l'autenticazione basata su certificati per il controller di dominio.

Questo modello non rilascia certificati per gli utenti finali: le credenziali dell'utente rimangono la chiave asimmetrica protetta dal dispositivo, ma i controller di dominio necessitano di certificati affinché i computer Windows li riconoscano come entità attendibili.

3. Fiducia nei certificati
Qui fanno un ulteriore passo avanti: trasmettono certificati di autenticazione per gli utentiDurante la registrazione, l'utente richiede un certificato utilizzando una chiave collegata al dispositivo (generata da Windows Hello). Successivamente, le richieste di accesso e di TGT Kerberos si basano su tale certificato utente, protetto dall'infrastruttura a chiave pubblica (PKI) aziendale.

Questo modello richiede un Un'infrastruttura a chiave pubblica (PKI) aziendale ben strutturata e un'autorità di registro dei certificati (CRA). Nelle implementazioni federate, AD FS in genere funge da CRA. Inoltre, negli ambienti ibridi, la scrittura inversa dei dispositivi deve essere abilitata in Microsoft Entra Connect.

Punto importante: nessuno di questi tipi di trust è intrinsecamente più sicuro degli altri; la scelta dipende dall'infrastruttura attuale, dalla presenza o meno di un'infrastruttura a chiave pubblica (PKI), dalla volontà di aggiungere AD FS e dalla disponibilità a intervenire sui controller di dominio.

Requisiti PKI in base al modello e al tipo di fiducia

Una delle domande tipiche quando si parla di Windows Hello in un dominio è se è necessario configurare un'infrastruttura a chiave pubblica (PKI) completa Affinché funzioni, la risposta dipende interamente dal modello di implementazione e dal tipo di fiducia scelto:

Kerberos Cloud Trust è l'unica opzione ibrida che non richiede certificati.Passando a questo modello, si evita di dover implementare CA aziendali per i controller di dominio e gli utenti. Ciò lo rende particolarmente interessante per gli ambienti che non desiderano gestire un'infrastruttura a chiave pubblica (PKI).

D'altra parte, in modelli ibridi basati sulla fiducia nella chiave o sulla fiducia nel certificato, così come nei modelli puramente locali, è necessaria la PKI:

• I controller di dominio Gli ambienti ibridi e on-premise necessitano di un certificato affinché i client Windows possano considerarlo attendibile durante la convalida dell'autenticazione basata su certificati.
• Se usi certificato di fiduciaPer emettere certificati utente sono necessari un'infrastruttura a chiave pubblica (PKI) aziendale e un'autorità di registro dei certificati (CRA). In molte implementazioni, Active Directory FS funge da CRA.
• In alcuni ambienti ibridi sarà necessario emettere certificati VPN per gli utenti, se il loro accesso alle risorse locali avviene tramite tunnel che dipendono dai certificati.

Pertanto, se esiti a toccare il controller di dominio e il tuo ambiente è già sincronizzato con Microsoft Entra ID, la soluzione più pratica è solitamente quella di optare per Kerberos nel cloudil che semplifica notevolmente l'infrastruttura.

Autenticazione con ID di accesso Microsoft

Windows Hello for Business viene utilizzato anche per autenticare l'utente in ID Microsoft EntraA prescindere dal metodo di comunicazione con Active Directory, entrano in gioco due opzioni principali: l'autenticazione federata (ad esempio, con AD FS) o l'autenticazione cloud (PHS/PTA).

A seconda del modello di implementazione e del tipo di trust, vengono imposti determinati requisiti:

• Solo cloudL'autenticazione cloud è utilizzata per impostazione predefinita. Se lo desideri, puoi optare per l'autenticazione federata con un IdP di terze parti, ma Windows Hello funziona perfettamente anche con l'autenticazione cloud standard.
• Ibrido con Kerberos Cloud Trust o Key TrustA seconda della configurazione attuale, è possibile utilizzare la sincronizzazione dell'hash delle password (PHS), l'autenticazione pass-through (PTA) o la federazione (AD FS o altri IdP).
• auto certificataRichiede l'autenticazione federata con AD FS; non supporta PHS o PTA. AD FS è fondamentale per questo.

Se il tuo inquilino è già configurato con PHS o PTA e non vuoi toccare AD FS, Fiducia Kerberos nel cloud Il modello Key Trust è più adatto. Tuttavia, se si utilizza già la federazione con AD FS per tutto, la fiducia nei certificati potrebbe essere la scelta più naturale.

Registrazione del dispositivo in base al modello

Un altro blocco chiave è il registrazione del dispositivoche determina chi controlla le apparecchiature per emettere i token e abilitare l'SSO.

En ambienti localiIl server con il ruolo AD FS è responsabile della registrazione dei dispositivi. Gestisce la relazione di fiducia con i dispositivi ed emette i token necessari affinché Windows Hello for Business funzioni all'interno del dominio locale.

Negli ambienti ibrido o solo cloudI dispositivi devono essere registrati con un ID Entra Microsoft, in uno dei seguenti modi:

• È stato aggiunto Microsoft Azure AD.
• Microsoft entra nel mondo degli ibridi (adesione ibrida ad Active Directory).
• Accesso a Microsoft per gli utenti registrati (comune negli ambienti BYOD).

Il tipo di connessione determina le funzionalità disponibili: ad esempio, i dispositivi ibridi consentono l'accesso SSO sia al cloud che all'ambiente locale, senza che l'utente debba gestire credenziali diverse.

Autenticazione a più fattori (MFA) nel provisioning

Uno degli obiettivi principali di Windows Hello per le aziende è Evitate le password metodi tradizionali, fornendo credenziali solide supportate da dispositivi sicuri. Per raggiungere questo obiettivo, il processo di provisioning richiede l'autenticazione a due fattori.

L'idea è che le credenziali deboli (nome utente e password) vengano utilizzate solo come primo fattore, mentre il secondo fattore è fornito da un Soluzione MFAWindows non genera le credenziali di Windows Hello for Business finché l'utente non completa correttamente l'autenticazione a più fattori (MFA).

Negli ambienti ibridi e interamente basati sul cloud, è possibile utilizzare:

• Microsoft introduce l'autenticazione a più fattori (MFA). integrato.
• Soluzioni MFA di terze parti, sia come metodo di autenticazione esterno in Microsoft Enter ID, sia tramite un IdP federato.

Negli ambienti locali senza un ID Microsoft Entra, sarà necessaria un'opzione MFA che si integri come Adattatore AD FS MFAMicrosoft e altri produttori offrono adattatori specifici per questo scopo.

Inoltre, nei domini federati è possibile modificare il marchio FederatedIdpMfaBehaviorQuesto indica a Microsoft Entra ID se accettare, richiedere o rifiutare l'autenticazione a più fattori (MFA) proveniente dall'IdP federato. Questa impostazione viene esaminata e modificata utilizzando comandi PowerShell come: Get-MgDomainFederationConfiguration y Update-MgDomainFederationConfiguration.

Configurazione dei criteri: GPO vs CSP

Affinché gli utenti possano utilizzare Windows Hello for Business sui propri dispositivi, è necessario configurare le politiche appropriateEsistono due meccanismi principali:

• Fornitore di servizi di configurazione (CSP)Ideale per dispositivi gestiti tramite MDM, come Microsoft Intune. Consente di distribuire i criteri di Windows Hello utilizzando profili di configurazione e persino pacchetti di provisioning.
• Criteri di gruppo (GPO): utilizzato per i computer aggiunti al dominio che non sono gestiti tramite MDM o laddove si preferisce continuare con la gestione tradizionale in locale.

In qualsiasi modello (solo cloud, ibrido o locale), è possibile utilizzare CSP, GPO o una combinazione di entrambi, a seconda di come si gestiscono i dispositivi. Ad esempio, è possibile gestire i laptop aggiunti al dominio utilizzando Intune (ibrido) e contemporaneamente applicare una configurazione di base tramite GPO o altri metodi. Amministrazione remota sicura.

In una classica implementazione GPO, c'è un Direttiva chiave obbligatoria per abilitare Windows Hello for Business in un modello di attendibilità chiave e un'altra policy altamente consigliata:

• Percorso di squadra: Configurazione computer → Modelli amministrativi → Componenti di Windows → Windows Hello for Business → Usa Windows Hello for Business (abilitato).
• Percorso utente: Configurazione utente → Modelli amministrativi → Componenti di Windows → Windows Hello for Business → Usa Windows Hello for Business (attivare se si desidera forzarlo per ciascun utente).
• Aggiuntivo: Utilizzare un dispositivo di sicurezza hardware, per imporre l'uso del TPM e migliorare la protezione delle chiavi.

Se applichi la configurazione sul nodo Team, tutti gli utenti Gli utenti che accedono da tali dispositivi saranno obbligati a tentare la registrazione a Windows Hello for Business. Se si applica la modifica a livello di utente, solo gli utenti interessati visualizzeranno la procedura di registrazione. In caso di conflitto, i criteri utente hanno la precedenza sui criteri computer.

Gli oggetti Criteri di gruppo (GPO) possono essere collegati al dominio o a specifiche unità organizzative (OU), filtrati in base ai gruppi di sicurezza o persino ai filtri WMI per segmentare con precisione i computer inclusi nella distribuzione. Oltre a queste opzioni di base, sono disponibili numerose altre funzionalità. Linee guida dettagliate per Windows Hello (ad esempio, complessità del PIN, tempo di blocco, utilizzo della biometria) che è possibile regolare in base alle politiche di sicurezza aziendali.

Processo di registrazione ed esperienza utente

Dal punto di vista dell'utente, il processo di configurazione di Windows Hello for Business è abbastanza guidato. Il provisioning inizia subito dopo il caricamento del profilo utente. e prima di visualizzare il desktop, a condizione che siano soddisfatti tutti i prerequisiti e le politiche dell'infrastruttura.

Se vuoi verificare se i controlli preliminari sono stati superati, puoi rivedere il registro amministratore dispositivo utente Nel Visualizzatore eventi: Registri applicazioni e servizi → Microsoft → Windows. Un'altra opzione è utilizzare dsregcmd.exe /status su una console per visualizzare lo stato di registrazione del dispositivo e la sua relazione con Microsoft Enter ID.

I passaggi che l'utente segue durante la registrazione sono generalmente i seguenti:

1. Se il dispositivo supporta l'autenticazione biometrica (lettore di impronte digitali, fotocamera compatibile), Windows chiederà all'utente di configurare un gesto biometricoQuesto gesto sbloccherà il dispositivo e autenticherà gli utenti con le risorse che accettano Windows Hello for Business. L'utente può saltare questo passaggio se preferisce utilizzare solo un PIN.
2. Windows ti informa che utilizzerà Windows Hello con l'account aziendale e l'utente deve accettare.
3. La fase inizia autenticazione a più fattoriWindows informa l'utente che sta tentando di contattarlo tramite il metodo di autenticazione a più fattori (MFA) configurato (ad esempio, app mobile, chiamata o SMS). Il provisioning non prosegue finché l'MFA non viene completata, non fallisce o non scade. In caso di errore o scadenza dell'MFA, l'utente riceve un messaggio di errore e gli viene chiesto di riprovare.
4. Dopo un'autenticazione a più fattori (MFA) riuscita, il sistema chiede all'utente di Crea e convalida un PINQuesto PIN deve essere conforme alle direttive di complessità configurate (lunghezza minima, limitazione delle cifre ripetute, ecc.).
5. Infine, Windows richiede un coppia di chiavi asimmetriche Per l'utente, idealmente le chiavi vengono generate e protette all'interno del TPM (o sono richieste se specificato nei criteri). Una volta generate, Windows registra la chiave pubblica presso l'IdP (Microsoft Entra ID o AD FS, a seconda del modello). Al termine della registrazione della chiave, la procedura guidata informa l'utente che può ora utilizzare il PIN o i dati biometrici per accedere, dopodiché l'utente chiude l'applicazione di provisioning e accede al desktop.

La documentazione ufficiale in genere include diagrammi di sequenza e video che illustrano questi passaggi, compresi esempi con adattatori MFA personalizzati per AD FS. Questi elementi sono utili per comprendere le comunicazioni tra il client, l'IdP, i controller di dominio e il servizio MFA.

Registrazione delle sequenze di tasti e sincronizzazione delle directory

Al centro di Windows Hello for business c'è creazione e registrazione della coppia di chiavi asimmetricheIl processo di provisioning genera una chiave privata collegata al dispositivo (solitamente memorizzata nel TPM) e registra la chiave pubblica presso il provider di identità appropriato:

• Modelli esclusivamente cloudLa chiave pubblica è registrata nell'ID di accesso Microsoft.
• Modelli ibridiSi registra inoltre con Microsoft Entra ID; successivamente, Microsoft Entra Connect Sync si occupa di sincronizzare la chiave pubblica con Active Directory.
• Modelli localiLa chiave pubblica è registrata in AD FS, che funge da provider di identità per l'ambiente locale.

Nei modelli ibridi, Microsoft Entra Connect non solo sincronizza utenti e dispositivi, ma anche Credenziali pubbliche di Windows Helloconsentendo all'utente di ottenere l'SSO (Single Sign-On) verso le risorse locali utilizzando tali credenziali sicure, senza dover reinserire la password.

Nei modelli puramente locali che utilizzano Azure MFA come soluzione di autenticazione a più fattori, la sincronizzazione della directory può essere utilizzata per importare gli utenti da Active Directory al server Azure MFA, il quale a sua volta comunica con il servizio cloud MFA per convalidare il secondo fattore.

Requisiti del sistema operativo

Per quanto riguarda le versioni di Windows, tutte le versioni client ufficialmente supportate da Microsoft possono essere utilizzate Windows Hello per le aziendeTuttavia, la fiducia di Kerberos nel cloud prevede dei requisiti minimi specifici:

• Windows 10 21H2 con aggiornamento KB5010415 o versioni successive.
• Windows 11 21H2 con aggiornamento KB5010414 o versioni successive.

Per altri tipi di fiducia (chiave e certificato) in modelli ibridi o locali, tutte le versioni client di Windows supportate Sono validi, a condizione che ricevano gli aggiornamenti di sicurezza.

Per quanto riguarda i controller di dominio, Windows Hello for Business funziona con tutte le versioni di Windows Server ancora supportate, ma Fiducia Kerberos nel cloud Anche in questo caso, sono previsti dei requisiti minimi:

• Windows Server 2016 con KB4534307 o versione successiva.
• Windows Server 2019 con KB4534321 o versione successiva.
• Windows Server 2022.
• Windows Server 2025.

In ogni caso, il livello funzionale minimo della foresta e del dominio deve essere Di Windows Server 2008 R2 Questo vale per tutti i modelli di implementazione. Se si dispone ancora di domini con livelli funzionali obsoleti, sarà necessario aggiornarli prima di prendere in considerazione un'implementazione seria di Windows Hello for Business.

Requisiti di licenza e di servizio cloud

In termini di licenza, Windows Hello for Business di per sé non richiede direttamente Microsoft Inserisci ID P1 o P2Tuttavia, alcune funzionalità correlate (come la registrazione automatica MDM, determinate politiche di accesso condizionale o la scrittura dei dati sui dispositivi) potrebbero richiedere i livelli P1/P2.

Alcuni punti chiave relativi alle licenze sono:

• È possibile distribuire Windows Hello for Business con livello gratuito ID di accesso Microsoft. Tutti gli account gratuiti possono utilizzare l'autenticazione a più fattori (MFA) di Microsoft per le funzionalità di Windows senza password.
• I dispositivi gestiti tramite MDM (Intune o altri) non richiedono P1/P2 semplicemente perché utilizzano Windows Hello; tuttavia, senza P1/P2, la registrazione MDM potrebbe non essere automatica e gli utenti dovranno registrazione manuale nella soluzione MDM.
• Se si utilizza il modello di certificato di fiducia In un ambiente ibrido, è necessario almeno un ID Microsoft P1 per abilitare funzionalità come la scrittura dei dispositivi e la registrazione dei certificati tramite l'autorità di registro AD FS.
• Negli ambienti locali, se si decide di utilizzare Azure MFA come soluzione di autenticazione a più fattori, sarà necessario disporre delle licenze o dei pacchetti Azure MFA corrispondenti che la includono.

In sintesi: per molte implementazioni di questo tipo ibrido con Kerberos nel cloud o Key Trust Non è obbligatorio possedere gli abbonamenti P1/P2, ma se si desidera sfruttare appieno la gestione moderna, l'accesso condizionale avanzato e la scrittura dei dati sui dispositivi, tali abbonamenti diventano rilevanti.

Come si inserisce tutto questo in uno scenario reale: tablet con connessione ibrida

In un tipico ambiente di lavoro di un tecnico sul campo con tablet Windows connessi in modalità ibrida, di solito si verifica quanto segue:

• I dispositivi sono Aggiunto al dominio e registrato con l'ID di accesso Microsoft (adesione ibrida AD).
• La configurazione viene gestita tramite Intune, GPO o una combinazione di entrambi.
• Vuoi abilitare Accedi con impronta digitale o PIN per evitare di digitare le password su un touchscreen.

In questo contesto, di solito è più consigliabile optare per Kerberos nel cloud rispetto ai modelli che richiedono un'infrastruttura a chiave pubblica (PKI) completa. Non è necessario "modificare" nulla sui controller di dominio, a parte installare le patch necessarie e configurare Microsoft Entra Kerberos, ed eviti di impantanarti con i certificati utente e CRA.

Se hai già creato un profilo di configurazione in Intune per abilitare Windows Hello e vedi che il sistema ti offre di configurare un PIN o la biometria, ma poi appare l'errore “Le loro credenziali non sono state verificate.” Quando tenti di utilizzare Windows Hello, molto probabilmente:

• Non ho Backend affidabile completato (Kerberos nel cloud/Chiave/Certificato) per comunicare con il dominio.
• Oppure la configurazione non funziona correttamente modello di implementazione ibrido seguendo le linee guida ufficiali (ad esempio, la guida specifica per la fiducia Kerberos nel cloud ibrido).

L'impostazione globale da "Registra dispositivi → Registrazione Windows" in Intune attiva Windows Hello a livello di tenant, ma non sostituisce Anche i requisiti dell'infrastruttura sottostante (tipo di attendibilità, Microsoft Entra Kerberos, sincronizzazione della directory, ecc.) sono un fattore determinante. Questo spiega perché la procedura guidata viene visualizzata sul lato client, ma il lato server non riesce a convalidare le credenziali.

La cosa sensata da fare in questi casi è rivedere passo passo la documentazione di distribuzione di Windows Hello for Business e la sua ibridazione con Kerberos nel cloud, assicurandosi che i dispositivi siano registrati correttamente (tramite dsregcmd /status), che Microsoft Enter Kerberos sia stato configurato nella foresta corretta e che i criteri (CSP/GPO) siano applicati agli utenti e ai computer appropriati.

Con tutti questi elementi correttamente allineati (un modello di implementazione chiaro, il tipo di attendibilità appropriato, un'autenticazione a più fattori funzionante, una corretta registrazione dei dispositivi e delle chiavi e criteri ben applicati), Windows Hello for Business smette di essere un "problema di configurazione" e diventa un modo piuttosto comodo per i tuoi utenti di accedere al dominio. PIN, impronta digitale o riconoscimento facciale invece di soffrire con infinite password su tastiere touch.