Windows Hello for Business, chiavi hardware e SSO

Se gestisci le identità in ambienti Microsoft, probabilmente ne hai sentito parlare Windows Hello, Windows Hello for Business, chiavi hardware e SSOMa è facile perdersi tra così tanti acronimi, tipi di trust e requisiti. Inoltre, nelle distribuzioni ibride con Active Directory legacy, capire cosa offre realmente WHfB rispetto a un semplice PIN o a un accesso biometrico può fare la differenza tra un progetto senza intoppi... e un mal di testa costante.

In questo articolo analizzeremo in dettaglio come funziona Windows Hello for Business (WHfB): quale ruolo svolgono le chiavi hardware? Come si ottiene l'accesso Single Sign-On (SSO)? e in che modo si differenzia dal "normale" Windows Hello per gli utenti domestici. Esamineremo le fasi interne (registrazione del dispositivo, provisioning, sincronizzazione delle chiavi, certificati e autenticazione), i modelli di distribuzione (solo cloud, ibrido e on-premise), i tipi di trust, i requisiti PKI, le licenze, le sfide di distribuzione reali e come tutto ciò si adatti ad approcci moderni come FIDO2 e la sicurezza senza password.

Windows Hello vs Windows Hello for Business: cosa cambia davvero

Windows Hello (semplice e chiaro) è l'esperienza utente per l'accesso con un PIN o dati biometrici su un dispositivo Windows, progettato sia per ambienti domestici che professionali. Windows Hello for Business (WHfB), invece, è l'estensione aziendale che aggiunge potenti funzionalità di gestione dell'identità integrate con Active Directory e Microsoft Entra ID.

Con entrambi i metodi puoi usare PIN, impronta digitale o riconoscimento facciale supportati dal TPM per accedere al computer. È possibile autenticarsi anche tramite un dominio locale classico. La grande differenza è che WHfB crea e gestisce credenziali crittografiche a livello aziendaleCoppie di chiavi o certificati collegati all'utente e al dispositivo, gestiti da policy e utilizzabili per SSO su risorse locali e cloud.

Mentre il "normale" Windows Hello è essenzialmente limitato a sostituisci la password con un gesto comodo su quel dispositivoWHfB genera una credenziale forte che il provider di identità (AD, Microsoft Entra ID o AD FS) riconosce, memorizza e utilizza per emettere token di accesso e applicare la sicurezza. Accesso condizionale, convalida KDC rigorosa, PRT, Kerberos nel cloud e altri controlli avanzati.

La domanda logica è: se ho già dispositivi aggiunti al dominio, gestiti con Intune, con TPM e biometria e SSO al cloud tramite sincronizzazione dell'hash della password, Cosa guadagno esattamente aggiungendo WHfB? La risposta sta nel modo in cui le chiavi vengono create e convalidate, nel modo in cui il dispositivo è collegato e nella capacità di estendere tale sicurezza all'intero ecosistema, non solo all'accesso locale.

Architettura di base: fasi di Windows Hello for Business

WHfB è un sistema distribuito che si basa su diversi componenti: meccanismi di dispositivo, TPM, provider di identità, PKI, sincronizzazione delle directory e SSOPer comprenderlo senza perdersi, è utile suddividerne il funzionamento in cinque fasi cronologiche di attuazione.

1. Registrazione del dispositivo

Il primo pezzo del puzzle è il registrazione del dispositivo presso il fornitore di identità (IdP)Questo passaggio consente di associare il dispositivo a un'identità nella directory e di abilitarne l'autenticazione automatica quando un utente effettua l'accesso.

In ambienti cloud-only o ibridi, L'IdP è Microsoft Inserisci ID e il dispositivo si registra con il suo servizio di registrazione dispositivi (unito a Microsoft Entra, unito in modo ibrido o registrato). In scenari puramente locali, l'IdP è in genere AD FS con il suo servizio di registrazione dei dispositivi aziendali.

Al termine di questa registrazione, l'IdP assegna il team un'identità univoca che verrà utilizzata per stabilire la fiducia dispositivo-directory nelle autenticazioni successive. Questo record è classificato in base al "tipo di associazione del dispositivo", che determina se il dispositivo è associato a un dominio locale, a un ID Entra, a un dominio ibrido o semplicemente registrato come personale.

2. Provisioning: creazione del contenitore Windows Hello

Una volta registrato il dispositivo, inizia la fase Provisioning delle credenziali di Windows Hello per le aziendeQui viene creato il cosiddetto contenitore Windows Hello, che raggruppa logicamente tutto il materiale crittografico dell'utente su quel computer.

Il tipico flusso di approvvigionamento segue questi passaggi principali, seguendo sempre un autenticazione iniziale con credenziali deboli (nome utente e password):

• L'utente si autentica con MFA presso l'IdP (Microsoft Enter MFA o un altro metodo compatibile, oppure un adattatore MFA in AD FS in ambienti locali).
• Dopo aver superato questo secondo fattore, ti verrà chiesto di configurare un PIN e, se è disponibile hardware compatibile, un gesto biometrico (impronta, viso, iride).
• Dopo aver confermato il PIN, Windows genera il Contenitore Windows Hello per quell'account in quella squadra.
• All'interno di quel contenitore, un coppia di chiavi crittografiche (pubblica e privata), collegato al TPM quando esiste o, in mancanza, protetto dal software.
• La La chiave privata rimane sul dispositivo e non può essere esportata, rimanendo protetti dal TPM e dai protettori PIN/biometrici.
• La la chiave pubblica è registrata nell'IdP ed è collegato all'oggetto utente: in Microsoft Login ID viene scritto all'utente e, negli scenari locali federati, AD FS lo trasferisce ad Active Directory.

Il contenitore comprende anche un chiave amministrativaQuesta funzionalità è utile per scenari come il reset del PIN; sui dispositivi dotati di TPM, viene memorizzato anche un blocco di dati contenente i certificati TPM. Tutto il materiale viene sbloccato solo quando l'utente esegue il gesto (PIN o dati biometrici) e questa combinazione MFA iniziale stabilisce la fiducia tra utente, dispositivo e IdP.

3. Chiavi all'interno del contenitore: autenticazione e identificativo utente

All'interno del contenitore Windows Hello troviamo diversi tipi di chiavi, con ruoli diversi, tutti crittografato con protezione basata su PIN o biometrica:

• Chiave di autenticazioneUna coppia di chiavi asimmetriche generate durante la registrazione che devono sempre essere sbloccate tramite PIN o gesto biometrico. Costituiscono la base su cui vengono riciclati altri materiali quando si cambia il PIN.
• Chiavi identificative utenteLe chiavi di identità possono essere simmetriche o asimmetriche a seconda dell'Identity Provider (IdP) e del modello (chiave o certificato). Vengono utilizzate per firmare o crittografare richieste e token indirizzati all'Identity Provider. Negli ambienti aziendali, vengono in genere generate come coppie di chiavi asimmetriche, con la chiave pubblica registrata presso l'IdP.

Queste chiavi identificative utente possono essere ottenute principalmente in due modi: associato alla PKI aziendale per emettere certificati (ad esempio, per VPN, autenticazione Kerberos basata su RDP o certificato) o generata direttamente dall'IdP in scenari senza PKI (modello a chiave pura).

La stessa infrastruttura consente l'utilizzo di Windows Hello come autenticatore FIDO2/WebAuthn in app e siti web compatibili. I siti possono creare una credenziale FIDO all'interno del contenitore Windows Hello; nelle visite successive, l'utente si autentica con il proprio PIN o dati biometrici senza esporre le password.

4. Sincronizzazione delle chiavi in ​​ambienti ibridi

Nelle architetture ibride dove coesistono ID di accesso Microsoft e Active DirectoryLa semplice registrazione della chiave nel cloud non è sufficiente. Dopo il provisioning, la chiave pubblica WHfB deve essere sincronizzata con la directory locale per abilitarla. autenticazione e SSO sulle risorse locali.

In questi scenari, Microsoft Entra Connect Sync si occupa di copiare la chiave pubblica nell'attributo msDS-KeyCredentialLink dell'oggetto utente in Active Directory. Questa sincronizzazione è fondamentale affinché il controller di dominio possa convalidare le firme generate dal dispositivo con la chiave privata memorizzata nel TPM.

5. Registrazione dei certificati (solo quando necessario)

In alcuni modelli (come il certificato di fiduciaOltre alle chiavi, l'organizzazione deve rilasciare certificati di autenticazione agli utenti. In tal caso, viene attivata una fase aggiuntiva. registrazione dei certificati.

Dopo aver registrato la chiave pubblica, il client genera un richiesta di certificato che invia la richiesta all'autorità di registro dei certificati, in genere integrata in AD FS nelle distribuzioni federate. Tale CRA convalida la richiesta utilizzando la PKI aziendale e Emette un certificato che viene archiviato nel contenitore Hello, riutilizzabile per l'autenticazione su risorse locali che si basano ancora sui certificati.

Autenticazione, chiave privata e SSO: come funzionano tutti insieme

Una volta completate le fasi di registrazione e provisioning, la vita quotidiana dell'utente si riduce a qualcosa di molto semplice: un gesto (PIN o biometria) che “rilascia” la chiave privata sul dispositivoLa cosa interessante è ciò che accade dietro le quinte.

Quando l'utente sblocca il computer, Windows utilizza la parte privata delle credenziali WHfB per firmare crittograficamente i dati inviati all'IdPQuesto processo verifica la firma utilizzando la chiave pubblica memorizzata nell'oggetto utente. Poiché il PIN e la chiave privata non lasciano mai il dispositivo, il processo è resistente al phishing e ai tradizionali furti di credenziali.

Negli scenari Microsoft Enter ID, il completamento di tale autenticazione comporta un Token di aggiornamento primario (PRT)Un token web JSON contenente informazioni su utenti e dispositivi. È la base dell'SSO per le applicazioni cloud e, in combinazione con Microsoft Kerberos o la sincronizzazione delle chiavi, anche per le risorse locali.

Senza PRT, anche se l'utente ha una credenziale WHfB valida, Perderei l'accesso unico. e sarebbero costretti ad autenticarsi continuamente in ogni app. Ecco perché le policy di accesso condizionale, basate sul dispositivo o sul rischio, di solito tengono conto della presenza e della validità di tale PRT.

Per Active Directory, quando si utilizza la fiducia tramite chiave o certificato, WHfB agisce come smart card virtualeL'utente firma un nonce o una sfida dal KDC, il controller di dominio convalida il certificato o la chiave ed emette un ticket TGT Kerberos, abilitando così l'SSO ai servizi locali integrati con Kerberos.

Sicurezza interna: biometria, TPM e protezione dagli attacchi

Uno dei pilastri del WHfB è che il I dati biometrici non lasciano mai il dispositivoI modelli generati dai sensori vengono memorizzati localmente in database crittografati (ad esempio, nel percorso C:\WINDOWS\System32\WinBioDatabase) utilizzando chiavi univoche per database, protetti con AES in modalità CBC e SHA-256 come funzione hash.

Ciò significa che anche se un aggressore riuscisse ad accedere a quei file, Non sono riuscito a ricostruire l'immagine del volto o dell'impronta digitale dell'utente.né possono essere utilizzati su altri dispositivi. Inoltre, ogni sensore conserva la propria memoria, riducendo la possibilità che un singolo punto centrale possa rubare i modelli biometrici.

Il PIN di Windows Hello for Business è inoltre più protetto di una password tradizionale. Non viaggia in rete, viene convalidato localmente e il TPM applica le misure di sicurezza. blocchi dovuti a troppi tentativi erratiQuesto rende inutili gli attacchi brute-force o a dizionario. E se qualcuno ruba il PIN, funzionerebbe solo su quel dispositivo specifico, poiché la credenziale è legata all'hardware.

Di fronte alle minacce moderne (Come capire se un'e-mail è di phishing(riutilizzo delle password, furto di massa delle credenziali), WHfB si basa su Crittografia a chiave pubblica collegata al dispositivoCiò evita, per definizione, l'esposizione di segreti condivisi, in perfetta linea con gli standard e le raccomandazioni di normative come NIST 800-63B e con i modelli di sicurezza Zero Trust.

Modelli di distribuzione: cloud, ibrido e on-premise

WHfB è flessibile in termini di topologia, ma questa flessibilità comporta una certa complessità. In generale, possiamo parlare di tre modelli di distribuzione che si combinano in modi diversi. ID Microsoft Entra, Active Directory, PKI e federazione.

Modello solo cloud

Nelle organizzazioni che vivono quasi al 100% in Microsoft 365 e altri servizi SaaS, senza infrastrutture locali rilevanti, il modello più semplice è quello di Solo cloud con dispositivi connessi a Microsoft. AccediIn questo scenario:

• Tutti gli utenti e i dispositivi risiedono in ID Microsoft Entra.
• La registrazione del dispositivo e della chiave avviene direttamente nel cloud.
• Non è necessaria alcuna PKI aziendale né certificati del controller di dominio.
• SSO si basa sui token PRT e Microsoft Entra per le applicazioni.

È l'opzione più diretta per le aziende cloud-first, con bassi costi infrastrutturali e distribuzione relativamente semplice, ideale quando le risorse locali non sono disponibili o sono minime.

Modello ibrido: il caso più comune

La stragrande maggioranza delle aziende si colloca nel mezzo: Active Directory storico combinato con ID di accesso Microsoft sincronizzatoWHfB è il punto di forza, ma è anche il luogo in cui i problemi di configurazione sono più comuni se non ben pianificati.

In un ambiente ibrido, le identità vengono sincronizzate con Microsoft Entra Connect Sync e sono possibili diverse combinazioni di modello di distribuzione (ibrido) e tipo di trust (cloud Kerberos, chiave o certificato)L'obiettivo è solitamente quello di offrire:

• SSO ai servizi cloud (SharePoint Applicazioni online, Teams, OIDC/SAML).
• Accesso trasparente alle risorse locali (azioni, applicazioni Kerberos, VPN, RDP).
• Una via di uscita graduale per le password, mantenendo al contempo le applicazioni legacy.

I principali tipi di trust negli scenari ibridi sono:

• Kerberos nel cloudMicrosoft Entra Kerberos emette TGT per Active Directory senza richiedere un'infrastruttura a chiave pubblica (PKI) aggiuntiva. Questo è il modello ibrido più moderno e semplice, poiché sfrutta l'infrastruttura FIDO2 esistente e non richiede la sincronizzazione delle chiavi pubbliche con Active Directory.
• Fiducia chiaveGli utenti si autenticano ad Active Directory utilizzando una chiave associata al dispositivo; i controller di dominio richiedono certificati specifici. La PKI è richiesta per i controller di dominio, ma non per i certificati utente.
• Fiducia del certificatoI certificati di autenticazione utente vengono emessi e utilizzati per ottenere i TGT Kerberos. Ciò richiede una PKI completa, AD FS come CRA e una configurazione più complessa.

La scelta del tipo di trust giusto è fondamentale: nessuno è intrinsecamente “più sicuro”Tuttavia, variano in termini di costi, complessità e requisiti infrastrutturali. Affidarsi a Kerberos nel cloud è spesso l'opzione migliore per le nuove distribuzioni, a condizione che le versioni client e server di Windows soddisfino i requisiti minimi.

Modello locale puro

Le organizzazioni con forti vincoli normativi o con un'adozione del cloud scarsa o nulla possono optare per un'implementazione WHfB. 100% locale, supportato da Active Directory e AD FSIn questo modello:

• La registrazione del dispositivo è gestita AD FS.
• L'autenticazione può essere basata su chiave o su certificato, ma è sempre supportata da una PKI aziendale.
• Le opzioni MFA includono adattatori per AD FS o soluzioni come Azure MFA Server (già legacy) integrate in locale.

Questo approccio fornisce un controllo completo sui dati di autenticazioneTuttavia, richiede un notevole sforzo di manutenzione (PKI, AD FS, pubblicazione di CRL accessibili da computer non appartenenti al dominio, ecc.), qualcosa che non tutte le organizzazioni sono disposte ad assumersi a lungo termine.

PKI accessibile, certificati del controller di dominio e CRL

Nei modelli che si basano sui certificati (sia per gli utenti, sia per i controller di dominio, sia per entrambi), la PKI diventa il cuore della fiducia. WHfB richiede rigorosa convalida dei KDC quando un dispositivo unito a Microsoft Enter esegue l'autenticazione su un dominio locale.

In pratica, ciò significa che il certificato del controller di dominio deve soddisfare una serie di condizioni tecniche: rilasciato da una CA radice attendibile per il dispositivo, in base al modello di autenticazione Kerberos, con EKU "autenticazione KDC", nome DNS corretto, RSA 2048 e SHA-256 come algoritmo di firmatra gli altri requisiti.

Inoltre, è essenziale che il dispositivo possa verificare la revoca dei certificatiQui risiede il classico problema con le CRL: un dispositivo unito solo a Microsoft Entra non può leggere i percorsi LDAP in Active Directory se non si è ancora autenticato, quindi è necessario pubblicare il punto di distribuzione CRL in un URL HTTP accessibile senza autenticazione.

Ciò comporta la preparazione di un server web (ad esempio IIS), la creazione di una directory virtuale (cdp) e la regolazione delle autorizzazioni. NTFS e dalle risorse condivise, disabilitare il immagazzinamento Nella memorizzazione nella cache offline, configura la CA per pubblicare la CRL su quella risorsa condivisa ed esporla tramite HTTP. Una volta fatto, devi Rinnovare i certificati del controller di dominio per includere il nuovo CDP e garantire che il certificato radice aziendale venga distribuito ai dispositivi uniti a Microsoft Entra (ad esempio, con Intune e un profilo "certificato attendibile").

Sincronizzazione delle directory, MFA e configurazione del dispositivo

L'esperienza dell'utente finale con Windows Hello for Business dipende in larga misura da Come vengono integrati la sincronizzazione delle directory, l'MFA e la configurazione dei criteri.

Nelle distribuzioni ibride, Microsoft Entra Connect Sync non solo sincronizza gli account, ma può anche sincronizzare attributi critici come msDS-KeyCredentialLinkche contiene la chiave pubblica WHfB necessaria per l'autenticazione in AD. Negli ambienti locali con Azure MFA Server, la sincronizzazione viene utilizzata per importare gli utenti nel server MFA, che quindi interroga il servizio cloud per la verifica.

Per quanto riguarda l'autenticazione a più fattori, le organizzazioni hanno diverse opzioni: Microsoft Entra MFA per scenari cloud o ibridiMetodi esterni integrati tramite autenticazione esterna nell'ID Entra o tramite federazione e adattatori MFA di terze parti per AD FS in ambienti on-premise. Il flag FederatedIdpMfaBehavior nei domini federati determina se l'ID Entra accetta, richiede o ignora l'MFA eseguita dall'IdP federato, il che può essere fondamentale per il corretto funzionamento del provisioning WHfB.

La configurazione WHfB sull'apparecchiatura può essere effettuata con criteri di gruppo (GPO) o CSP tramite MDM (ad esempio, Intune). Nelle organizzazioni moderne, è prassi comune abilitare la registrazione automatica WHfB, forzare l'autenticazione a più fattori al primo accesso, definire policy di complessità dei PIN e controllare quali metodi biometrici sono accettati (solo sensori certificati, telecamere a infrarossi, ecc.).

Parallelamente, è fondamentale considerare l'esperienza di recupero: reset self-service del PIN, metodi alternativi come le chiavi FIDO2 e Crittografia BitLocker per proteggere i dati inattivi in ​​caso di smarrimento o furto del dispositivo.

Licenze, requisiti di sistema e limitazioni pratiche

Uno dei miti più comuni è che bisogna sempre usare WHfB Microsoft Inserisci ID P1 o P2In realtà, le funzionalità principali di WHfB sono disponibili con il livello gratuito Entra ID e l'autenticazione a più fattori richiesta per il provisioning senza password può essere abilitata anche senza licenze premium, sebbene funzionalità come la registrazione automatica MDM, l'accesso condizionale avanzato o la scrittura differita dei dispositivi richiedano livelli superiori.

In termini di sistema operativo, praticamente tutte le versioni client moderne di Windows supportano WHfB, ma La fiducia in Kerberos nel cloud richiede minimi concreti (ad esempio, Windows 10 21H2 con determinate patch o versioni specifiche di Windows 11Sul lato server, qualsiasi versione supportata di Windows Server può generalmente fungere da controller di dominio, sebbene la parte Kerberos nel cloud richieda versioni e aggiornamenti specifici sui controller di dominio.

Oltre agli aspetti tecnici, ci sono sfide molto pratiche: attrezzature condivise dove WHfB, essendo specifico per dispositivo e utente, si adatta regolarmente; hardware senza TPM 2.0 o senza sensori biometrici; o ambienti in cui il costo del rinnovo delle vecchie flotte, dell'implementazione di PKI e dell'aggiornamento dei DC del 2012 rende l'adozione completa di WHfB poco attraente nel breve termine.

In alcuni casi, il percorso ragionevole prevede combinare WHfB con altri fattori senza password (chiavi FIDO2, smart card, autenticazione telefonica) per coprire postazioni di lavoro condivise, piattaforme non Windows o utenti altamente mobili, lasciando WHfB come autenticatore primario in Portátiles società collegate a Entra o ibride.

Considerando il quadro generale, Windows Hello for Business offre molto più di un "bel PIN": introduce credenziali asimmetriche vincolate all'hardware, rigorosa verifica KDC, profonda integrazione con Microsoft Entra ID e Active Directory e un framework robusto per SSO sicuro Sia nel cloud che on-premise. Tuttavia, il suo reale valore rispetto a Windows Hello di base dipende dal punto di partenza: nei moderni ambienti cloud-first o ibridi con PKI e DC aggiornati, il salto in termini di sicurezza e gestione supera chiaramente lo sforzo; in domini molto vecchi, con un'infrastruttura scarsamente preparata e senza piani di modernizzazione, potrebbe essere più sensato progredire prima in termini di hardware, PKI e controllo degli accessi prima di sfruttare appieno il potenziale di WHfB.

Articolo correlato:

Come sapere quali app hanno accesso alla fotocamera, al microfono o alla posizione in Windows 11

Isaac

Scrittore appassionato del mondo dei byte e della tecnologia in generale. Adoro condividere le mie conoscenze attraverso la scrittura, ed è quello che farò in questo blog, mostrarti tutte le cose più interessanti su gadget, software, hardware, tendenze tecnologiche e altro ancora. Il mio obiettivo è aiutarti a navigare nel mondo digitale in modo semplice e divertente.