Windows Hello for Business: spiegazione delle chiavi hardware e dell'SSO

Windows Hello per le aziende (WHfB) È diventato un componente chiave della strategia di identità di Microsoft per le aziende: addio alle password tradizionali e benvenuto a un modello di autenticazione basato su chiavi crittografiche, dati biometrici, PIN e dispositivi affidabili. In combinazione con ID di accesso Microsoft e Single Sign-On (SSO)Consente agli utenti di accedere alle risorse cloud e on-premise con un solo gesto, mantenendo al contempo controlli di sicurezza di livello aziendale.

In questo articolo analizzeremo, con calma ma in modo diretto, Come funziona l'autenticazione di Windows Hello for Business quando sono coinvolte chiavi hardware, dispositivi abilitati TPM e scenari SSO? Rispetto a Microsoft Entra ID e Active Directory, esamineremo le fasi interne (registrazione del dispositivo, provisioning, sincronizzazione delle chiavi, certificati e autenticazione), il ruolo di PRT in SSO, come si integra con Kerberos in ambienti ibridi e i requisiti infrastrutturali affinché tutto funzioni senza problemi.

Architettura generale di Windows Hello for Business e del suo modello senza password

Windows Hello for Business non significa solo "inserire un PIN o mostrare il proprio volto" Per effettuare l'accesso, si utilizza un sistema distribuito che combina l'identità dell'utente, l'identità del dispositivo e chiavi crittografiche protette da hardware. L'autenticazione si basa su una coppia di chiavi pubblica/privata o su certificati, associati al dispositivo (TPM) e sbloccati da un elemento noto all'utente (PIN) o da un elemento che identifica (biometria).

La grande differenza rispetto alle password classiche Il motivo è che non esiste più un "segreto condiviso" che viaggia attraverso la rete o viene archiviato centralmente: il server (ID Microsoft Entra o Active Directory) memorizza solo la parte pubblica della chiave, mentre la parte privata non lascia mai il dispositivo. Quando l'utente desidera autenticarsi, Windows firma un nonce con la chiave privata e il provider di identità convalida tale firma con la chiave pubblica registrata.

Questo approccio rende WHfB resistente al phishingAnche se un aggressore inducesse un utente a inserire il proprio nome utente su un sito dannoso, non potrebbe replicare l'autenticazione senza la chiave privata collegata al TPM del dispositivo. Il risultato è un sistema di autenticazione a due fattori (chiave + PIN/biometria) che soddisfa rigorosi criteri MFA, ma con un'esperienza utente molto più fluida e una maggiore sicurezza. Windows 11.

WHfB si integra in modo nativo con Microsoft Entra ID e Active DirectoryCiò consente diversi modelli di distribuzione: solo cloud, ibrido o completamente on-premise. Inoltre, può coesistere con smart card e chiavi FIDO2 e persino riutilizzare la PKI esistente dell'organizzazione quando si opta per modelli basati su certificati.

Fasi di funzionamento di Windows Hello for Business

Per comprendere appieno cosa succede “sotto il cofano”L'approccio più pratico consiste nel suddividere il ciclo di vita di Windows Hello for Business in diverse fasi collegate: registrazione del dispositivo, provisioning, sincronizzazione delle chiavi (in modalità ibrida), registrazione del certificato (se utilizzato) e, infine, autenticazione e SSO.

1. Registrazione del dispositivo

Prima di rilasciare le credenziali WHfB a un utente, il dispositivo deve avere una propria identità.Questo processo è denominato registrazione del dispositivo e associa il dispositivo al provider di identità (IdP) dell'organizzazione.

A seconda del tipo di distribuzione, l'IdP e il servizio di registrazione cambiano.:

• Implementazioni cloud o ibride: L'IdP è Microsoft Enter ID. Il dispositivo si registra con Servizio di registrazione del dispositivo dell'ID Entra e diventa un "dispositivo aggiunto a Microsoft Entra" o un "ibrido aggiunto a Microsoft Entra".
• Implementazioni puramente locali: L'IdP è AD FS e il dispositivo è registrato in servizio di registrazione dei dispositivi aziendali che espone AD FS.

A seguito della registrazione, l'IdP conferisce al team la propria identità.Questo verrà utilizzato nei successivi scambi di autenticazione utente e nel recupero dei token. Esistono diversi "tipi di combinazione" o stati di adesione (solo accesso, ibrido, classico adesione a un dominio + registrazione, ecc.) che determinano il comportamento del dispositivo in ambienti misti.

2. Provisioning di Windows Hello per le aziende

La fase di provisioning è quando le credenziali Hello vengono effettivamente create per un utente specifico su un dispositivoQui appare un concetto chiave: il Contenitore Windows Hello, che è una struttura logica in cui è archiviato tutto il "materiale chiave" associato alle identità dell'utente su quel computer.

Il tipico flusso di approvvigionamento comprende diversi passaggi collegati:

1. L'utente effettua l'accesso con le proprie credenziali tradizionali (solitamente nome utente e password) e il sistema avvia l'esperienza di configurazione di WHfB, richiedendo l'autenticazione a più fattori dall'IdP (Microsoft Entra ID o AD FS).
2. Dopo aver completato con successo l'MFA, All'utente viene chiesto di definire un PIN e, se l'hardware lo consente, di registrare i dati biometrici. (impronta, viso, iride).
3. Una volta confermato il PIN, Windows crea il contenitore Windows Hello sul dispositivo.
4. A viene generato coppia di chiavi di autenticazione pubblica e privata, collegato al TPM (se esiste) o, in mancanza, protetto tramite software.
5. La chiave privata è memorizzata localmente e sigillata sul TPM, non è esportabile.
6. La chiave pubblica è registrata nell'IdP e collegata all'account dell'utente:
   1. Negli scenari cloud o ibridi, il servizio di registrazione del dispositivo lo scrive nell'oggetto utente Microsoft Entra ID.
   2. Negli scenari locali con AD FS, viene archiviato in Active Directory.

All’interno del contenitore, ogni “protettore” (PIN, gesto biometrico, ecc.) mantiene la propria copia crittografata della chiave di autenticazioneSe è presente un TPM, il PIN viene utilizzato come entropia in un'operazione di sigillatura; in caso contrario, viene derivata una chiave simmetrica per crittografare il materiale. Ciò consente all'utente di sbloccare la stessa coppia di chiavi con gesti diversi, senza compromettere la sicurezza.

Oltre alla chiave di autenticazione primaria, il contenitore può includere altri elementi, come una chiave amministrativa per scenari di reimpostazione del PIN, blob con certificati TPM e, soprattutto, diversi tipi di chiavi identificative utente utilizzate per protocolli specifici (WebAuthn/FIDO2, Entra ID, certificati utente per VPN o RDP, ecc.).

Dettagli delle chiavi di autenticazione e dell'identificativo utente

La chiave di autenticazione di Windows Hello è sempre una coppia asimmetrica (pubblico/privato) generato durante la registrazione. Ogni volta che deve essere utilizzato, deve essere sbloccato tramite PIN o dati biometrici. Se l'utente reimposta il PIN, viene generata una nuova coppia di chiavi di autenticazione e tutto il materiale protetto dalla coppia precedente viene nuovamente crittografato.

Le chiavi identificative dell'utente possono essere simmetriche o asimmetriche.A seconda dell'IdP e dello scenario. Negli ambienti aziendali moderni (ID Microsoft Entra, Active Directory, account Microsoft personali), si tratta solitamente di coppie di chiavi asimmetriche, generate e memorizzate sul dispositivo, con la parte pubblica registrata presso l'identity provider.

Esistono due modi principali per generare chiavi identificative utente nelle organizzazioni:

• Associarli con il PKI aziendalein modo che la chiave sia collegata a un certificato emesso dalla CA aziendale. Ciò facilita la transizione dalle infrastrutture basate su certificati (VPN, RDP con certificati utente, ecc.) a WHfB.
• Lascia che sia direttamente il IdP (Entra ID o AD FS) colui che gestisce la coppia di chiavi associato all'identità, riducendo la complessità della PKI quando non è essenziale.

Queste chiavi vengono utilizzate per dimostrare il possesso firmando i nonce o token di autenticazione, sia per i controller di dominio (Kerberos) sia per i servizi web che utilizzano WebAuthn (FIDO2). Un singolo dispositivo può ospitare diverse credenziali FIDO associate a diversi siti web o applicazioni, tutte gestite all'interno del contenitore Windows Hello.

Archiviazione locale dei dati biometrici

Un punto che spesso preoccupa molti utenti e revisori è cosa succede alle loro caratteristiche biometriche.In Windows Hello for Business, i modelli biometrici Sono memorizzati solo sul dispositivo, in un database locale a cui Microsoft non accede e non è sincronizzato con il cloud.

Ogni sensore biometrico mantiene il proprio database di modelli (ad esempio, in C:\WINDOWS\System32\WinBioDatabase), crittografati con una chiave casuale univoca per database, protetti con AES in modalità CBC e con hashing SHA-256. Anche se un aggressore ottenesse questo database, non sarebbe in grado di ricostruire le immagini "grezze" del volto o dell'impronta digitale; si tratta di dati modello irreversibili.

3. Sincronizzazione delle chiavi in ​​ambienti ibridi

Nelle distribuzioni ibride, la chiave pubblica registrata in Microsoft Entra ID deve raggiungere anche Active Directory in modo che l'utente possa autenticarsi senza password sia ai servizi cloud che alle risorse locali.

Questo processo è gestito da Microsoft. Accedi a Connect Sync., che sincronizza la chiave pubblica dell'utente da Enter ID all'attributo msDS-KeyCredentialLink dell'oggetto utente in Active Directory. In questo modo, i controller di dominio possono convalidare le autenticazioni basate su chiave (scenario di trust chiave) o utilizzare le informazioni associate per i modelli di trust cloud Kerberos.

4. Registrazione del certificato (quando si utilizza il modello basato sul certificato)

Se la tua organizzazione ha già implementato una PKI e desidera sfruttarla con WHfBIn alternativa, è possibile scegliere il modello di trust basato su certificato. In questo caso, dopo aver registrato la chiave presso l'IdP, il client genera una richiesta di certificato e la invia a un'autorità di certificazione (CRA), in genere ospitata su un server AD FS.

La CRA convalida la richiesta e la inoltra alla CA aziendaleche rilascia un certificato utente. Tale certificato viene archiviato nel contenitore Windows Hello e verrà utilizzato per l'autenticazione su risorse locali che richiedono certificati client (ad esempio, l'autenticazione Kerberos con certificati o VPN IPsec).

5. Fase di autenticazione: come viene “rilasciata” la chiave

Una volta completate le fasi precedenti, l'esperienza quotidiana dell'utente è molto semplice.Per accedere o sbloccare il dispositivo, utilizza il tuo PIN o i dati biometrici. Tecnicamente, questo gesto "sblocca" l'accesso alla parte privata delle tue credenziali WHfB memorizzate nel TPM.

Né il PIN né la chiave privata lasciano il dispositivo o vengono inviati all'IdPIl PIN funge da entropia per le operazioni di firma con chiave privata; in altre parole, è un trigger locale che autorizza l'uso della chiave. Quando un'applicazione o il sistema stesso deve autenticarsi presso un Identity Provider (IdP), Windows firma un blocco di dati con la chiave privata e invia la firma al server, che ne verifica la validità rispetto alla chiave pubblica registrata.

Questo schema viene ripetuto sia per l'autenticazione diretta che per l'inserimento dell'ID. (tramite protocolli web e il provider Cloud AP) come per le autenticazioni Kerberos rispetto ad Active Directory (tramite una chiave, un certificato o un trust Kerberos nel cloud).

Token di aggiornamento primario (PRT) e Single Sign-On (SSO)

L'SSO moderno negli ambienti Microsoft ruota attorno al Primary Update Token o PRT.Mentre nel Kerberos classico il "token master" è il TGT, negli scenari Entra ID il PRT è un token JWT che contiene informazioni sull'utente e sul dispositivo e consente di ottenere token di accesso per diverse applicazioni senza che l'utente debba autenticarsi nuovamente in modo esplicito.

Il PRT viene normalmente emesso durante l'accesso o lo sblocco del dispositivo. Quando l'utente si autentica con WHfB su un computer con accesso a Microsoft Entra o su un computer ibrido con accesso a Entra. Sui dispositivi personali registrati, il PRT si ottiene aggiungendo un account aziendale o scolastico a Windows.

Senza PRT non esiste un vero SSO per le applicazioni protette da Entra ID o AD FSSe per qualsiasi motivo il dispositivo non dispone di un PRT valido, gli utenti vedranno ripetute richieste di credenziali e i criteri di accesso condizionale che richiedono informazioni sul dispositivo (ad esempio, "solo dispositivi contrassegnati come conformi") non funzioneranno.

In scenari di accesso remoto con VPN e SAML SSOUna volta che l'utente si è autenticato con WHfB sul sistema operativo, il PRT consente a Entra ID di "ricordare" che l'autenticazione MFA anti-phishing è già stata soddisfatta. Pertanto, durante l'accesso VPN tramite SAML, Entra ID può contrassegnare la sessione come conforme all'autenticazione MFA senza richiedere un secondo fattore di autenticazione, aspetto che spesso suscita dibattiti con assicuratori e revisori contabili.

Flusso di autenticazione del dispositivo aggiunto a Microsoft: Invio per immettere l'ID

Su un dispositivo connesso a Entra, la catena di eventi durante un accesso WHfB In termini semplificati, è come segue:

• L'utente chiude la schermata di blocco e inserisce il proprio PIN o i dati biometrici nel provider di credenziali WHfB.
• Winlogon trasmette tali credenziali a LSASS, che a sua volta le consegna al provider di sicurezza per l'autenticazione cloud (Cloud AP).
• Cloud AP richiede un nonce Microsoft Inserisci ID; Inserisci ID risponde con quel valore.
• Il client firma il nonce con la chiave privata dell'utente e invia il risultato a Entra ID.
• Entra ID verifica la firma con la chiave pubblica registrata in precedenza e, se tutto è corretto, genera un PRT, crittografato con la chiave di trasporto del dispositivo.
• Cloud AP decrittografa la chiave di sessione PRT utilizzando la chiave di trasporto privata (protetta da TPM) e memorizza il PRT in una cache protetta.
• LSASS informa Winlogon che l'autenticazione è riuscita e la sessione utente è stata creata.

Da quel momento in poi, il PRT verrà utilizzato per ottenere token di accesso e di aggiornamento per diverse applicazioni (Microsoft 365, SaaS di terze parti, applicazioni SAML, ecc.) senza che l'utente debba digitare nuovamente nulla, sempre nel rispetto dei criteri di accesso condizionale configurati.

Autenticazione di Windows Hello for Business vs. Active Directory

Quando il dispositivo è solo "unito a Entra" ma deve accedere alle risorse localiÈ qui che entra in gioco l'integrazione con Active Directory attraverso vari modelli: Kerberos Cloud Trust, Key Trust e Certificate Trust. Tutti questi modelli consentono alle credenziali WHfB di generare ticket Kerberos senza richiedere password.

Affidati a Kerberos nel cloud con Microsoft. Inizia subito.

Nel modello di fiducia Kerberos nel cloudMicrosoft Entra ID emette un TGT parziale associato all'identità dell'utente e firmato dal servizio cloud Kerberos. Quando il dispositivo necessita di un TGT completo da un controller di dominio locale, invia tale TGT parziale al KDC locale, che lo convalida ed emette un TGT "reale" per l'utente.

Questo approccio semplifica notevolmente l'infrastrutturaperché delega parte della logica di autenticazione all'ID Entra, ma richiede che i controller di dominio siano aggiornati e configurati correttamente per riconoscere e convalidare i TGT parziali provenienti dal cloud.

Modello di fiducia chiave

Nel modello di trust chiave, il controller di dominio convalida direttamente una firma creata con la chiave privata dell'utente. registrati in Active Directory. Il flusso di alto livello è:

• Il provider Kerberos sul client firma i dati di pre-autenticazione con la chiave privata e invia la firma insieme alla chiave pubblica (in un certificato autofirmato) al KDC.
• Il KDC verifica che il certificato sia autofirmato, individuando la chiave pubblica nell'attributo msDS-KeyCredentialLink dall'utente e convalida la firma.
• Se tutto corrisponde (UPN, chiavi, firma), il KDC restituisce un TGT al client.

Successivamente, il client convalida il certificato KDC (collegamento a una radice di attendibilità, autenticazione KDC EKU, nome alternativo corrispondente al dominio, algoritmi sicuri come SHA-256 e RSA 2048, ecc.) prima di accettare tale TGT e memorizzarlo nella cache per future richieste di ticket di servizio.

Certificato di fiducia

Nel modello basato su certificato, l'utente presenta al KDC un certificato client rilasciato dalla CA dell'organizzazione.Kerberos utilizza le informazioni del certificato (DN del soggetto o UPN nella SAN) come indizio per individuare l'account in Active Directory.

Il controller di dominio convalida la catena di certificati fino a una radice di attendibilitàVerifica che il certificato sia entro il suo periodo di validità e non sia stato revocato, e utilizza la chiave pubblica del certificato per verificare i dati di pre-autenticazione firmati. Se tutto è corretto, emette il TGT, che il client accetta dopo aver verificato il certificato del KDC.

Requisiti infrastrutturali per ambienti ibridi sicuri

Per garantire che un dispositivo aggiunto a Microsoft Entra si autentichi correttamente in Active Directory Ciò implica prestare molta attenzione alla configurazione della PKI aziendale, ai punti di distribuzione CRL e alla fiducia nei certificati dei controller di dominio.

Punti di distribuzione dell'elenco di revoca (CDP/CRL)

Un errore molto comune è lasciare il CDP solo in LDAP all'interno del dominioI dispositivi uniti all'ID Entra che non fanno parte del dominio non possono leggere il percorso LDAP prima di autenticarsi, creando un loop: devono convalidare il certificato DC per autenticarsi, ma non possono leggere il CRL senza essersi autenticati.

La soluzione consigliata è quella di pubblicare la CRL in un punto accessibile tramite HTTP senza autenticazione.In genere si tratta di un sito web interno e l'URL viene aggiunto come CDP ai certificati CA e del controller di dominio. Il processo prevede:

• Configurare un server web (IIS) con una directory virtuale (ad esempio, cdp) e abilitare l'esplorazione delle directory.
• Regolare NTFS e condividere le autorizzazioni in modo che la CA possa pubblicare automaticamente i file CRL in quella directory.
• Aggiornare la configurazione CA per includere il nuovo URL HTTP come CDP e come posizione di pubblicazione CRL e delta CRL.
• Riemettere i certificati del controller di dominio per includere il nuovo CDP HTTP.

Dopo questi passaggi, i dispositivi connessi a Entra possono convalidare il certificato DC senza dover essere autenticati.eliminando il problema circolare e consentendo il corretto funzionamento dell'autenticazione basata su certificati o chiavi.

Requisiti del certificato del controller di dominio

Per Windows Hello for Business per imporre una "rigorosa convalida KDC" Quando si esegue l'autenticazione da un dispositivo associato a Entra, i certificati del controller di dominio devono soddisfare diversi criteri:

• La CA radice emittente deve trovarsi nel magazzino di autorità di certificazione radice attendibili Del dispositivo.
• Il certificato deve essere basato sul Modello di autenticazione Kerberos adeguato.
• Deve includere l'EKU di Autenticazione KDC.
• Il nome alternativo del soggetto (SAN) deve contenere un nome DNS che corrisponda al dominio.
• L'algoritmo di firma deve essere SHA-256 e la chiave pubblica deve essere RSA di almeno 2048 bit.

Se una di queste procedure fallisce, i dispositivi collegati a Entra potrebbero rifiutare il certificato DC. e l'autenticazione con WHfB ad Active Directory non funzionerà, anche se tutto sembra funzionare correttamente con le password classiche.

Distribuzione del certificato radice CA sui dispositivi uniti a Entra

In modo che si fidino dei certificati del controller di dominioI dispositivi aggiunti a Microsoft Entra devono avere installato il certificato radice della CA aziendale. Questo certificato viene in genere esportato da un controller di dominio e distribuito ai computer che utilizzano Microsoft Intune con un criterio di "certificato attendibile".

La direttiva dovrebbe puntare all'archivio certificati del team (radice di attendibilità). e assegnati ai gruppi di utenti o dispositivi appropriati. Una volta applicati, i sistemi vedranno i certificati emessi da quella CA, incluso il certificato KDC, come "attendibili" e la convalida rigorosa potrà essere completata con successo.

Modelli di distribuzione, sfide e best practice

Windows Hello for Business supporta distribuzioni solo cloud, ibride o completamente on-premisee ogni modello ha implicazioni pratiche diverse in termini di complessità, compatibilità e costi.

Nelle organizzazioni cloud-first senza Active Directory on-premiseLa soluzione più semplice è un modello basato solo sul cloud, in cui la gestione delle chiavi e l'autenticazione sono gestite interamente da Microsoft Entra ID, senza richiedere una PKI locale o AD FS. Gli utenti accedono alle applicazioni Microsoft 365 e SaaS tramite SSO, utilizzando WHfB come autenticatore senza password.

Nella maggior parte delle aziende di medie e grandi dimensioni, lo scenario più realistico rimane il modello ibrido.Le risorse critiche rimangono locali, le applicazioni Kerberos pure esistono e i servizi cloud vengono utilizzati simultaneamente. È qui che si devono prendere decisioni tra l'affidabilità del cloud Kerberos, l'affidabilità delle chiavi e l'affidabilità dei certificati; si deve valutare la compatibilità con le applicazioni legacy e, in molti casi, i metodi basati su password o smart card devono essere mantenuti per un certo periodo di tempo.

Nei settori altamente regolamentati o in quelli con requisiti estremi di sovranità dei dati (governo, alcune entità finanziarie o sanitarie), un modello completamente locale con ADFS e una propria PKI potrebbe avere senso, in cui WHfB viene utilizzato come sostituto della password, ma senza affidarsi al cloud. Tuttavia, ciò comporta una maggiore complessità operativa e di manutenzione.

In tutti i casi, ci sono sfide comuni: hardware compatibile, postazioni di lavoro condivise, resistenza degli utenti al cambiamento e giustificazione agli assicuratori e ai revisori dei conti che WHfB conta effettivamente come MFALa chiave è combinare WHfB con policy di accesso condizionale che richiedono autenticatori resistenti al phishing, abilitare la riautenticazione o intensificare l'MFA laddove ragionevole (ad esempio, in operazioni altamente sensibili o connessioni VPN critiche) e documentare accuratamente il modello di minaccia.

Tutto ciò è accompagnato da una buona formazione, da chiare policy PIN, dal monitoraggio degli accessi e da un'implementazione graduale supportata da Intune o GPO.Windows Hello for Business consente alle organizzazioni di compiere un salto di qualità verso un modello di identità senza password, riducendo la superficie di attacco, migliorando la conformità normativa e offrendo agli utenti un'esperienza di accesso molto più naturale e veloce.