Windows Hello for Business: una guida completa all'SSO e alla sicurezza hardware

Windows Hello per le aziende È diventato il componente chiave della strategia senza password di Microsoft: combina PIN, dati biometrici e chiavi crittografiche in modo che gli utenti possano accedere senza digitare password, ma con un livello di sicurezza molto più elevato. Tutto questo è supportato da Sicurezza hardware, TPM e modelli SSO moderni sia nel cloud che in ambienti ibridi e on-premise.

Lungi dall'essere solo "il PIN di Windows", Windows Hello per le aziende (WHfB) Si tratta di un sistema distribuito che integra Microsoft Entra ID (in precedenza Azure AD), Active Directory, PKI, Kerberos, FIDO2 e policy avanzate per dispositivi e utenti. Se sei un amministratore di Windows o di identità, comprendere come tutto si integra (registrazione, provisioning, sincronizzazione delle chiavi, certificati e autenticazione) è essenziale per un'implementazione fluida ed efficace. Single sign-on robusto e resistente al phishing.

Cos'è esattamente Windows Hello for Business e in che modo modifica l'autenticazione?

Windows Hello per le aziende È la versione aziendale e gestita di Windows Hello. Sostituisce la password con una credenziale a chiave pubblica associata al dispositivo, protetta da un TPM e sbloccabile tramite PIN o gesto biometrico. Questa credenziale consente l'autenticazione contro ID di accesso Microsoft, Active Directory o AD FSservizi che fanno affidamento su di essi.

Invece di affidarsi a segreti condivisi (password, OTP, codici SMS), WHfB genera un coppia di chiavi pubblica/privata per utente e dispositivo. La chiave pubblica viene registrata presso il fornitore di identità (IdP), mentre la chiave privata rimane archiviata in modo sicuro sul dispositivo e non può essere esportata. L'utente fornisce "entropia" solo con il proprio PIN o dati biometrici per rilasciare la chiave privata quando desidera autenticarsi.

Il risultato è un'esperienza di autenticazione resistente al phishing, al furto di credenziali e agli attacchi brute-forceGestione dell'SSO sia nel cloud (Microsoft 365, applicazioni moderne) sia nei servizi locali (Kerberos, applicazioni legacy, VPN basate su certificati, ecc.).

Fasi interne di Windows Hello for Business: da zero a SSO

Per comprendere appieno WHfB È consigliabile suddividere il funzionamento in più fasi cronologiche: registrazione del dispositivo, provisioning, sincronizzazione delle chiavi (se applicabile), registrazione del certificato (se utilizzato) e, infine, autenticazione giornaliera.

1. Registrazione del dispositivo

Innanzitutto, il team deve passare attraverso un processo di registrazione del dispositivoQuesto passaggio associa il dispositivo a un IdP specifico e gli assegna una propria identità:

• Implementazioni cloud o ibrideL'IdP è Microsoft Enter ID e il dispositivo è registrato nel servizio di registrazione dei dispositivi.
• Implementazioni puramente localiL'IdP è AD FS e la registrazione viene eseguita tramite il servizio di registrazione dei dispositivi aziendali esposto da AD FS.

Dopo la registrazione, il dispositivo ha un identità attendibile che consente l'autenticazione con l'IdP quando un utente effettua l'accesso. Esistono diversi tipi di registrazione (adesione al dominio, adesione a Microsoft Login, registrazione personale, ecc.), noti come tipi di relazione o "tipi di join", che determinano il comportamento successivo di WHfB e SSO.

2. Fase di approvvigionamento

Durante il provisioning, l'utente cessa di essere un "utente con password" e diventa un utente con una propria password. Contenitore Windows Hello sul dispositivo. Questo contenitore raggruppa il materiale crittografico associato ai tuoi account (aziendali, didattici, personali) in modo isolato in base al provider di identità.

Il flusso di fornitura tipico Segui questi passi:

1. Nell'assistente all'esperienza utente (CXH), l'utente si autentica con l'IdP utilizzando AMF (solitamente nome utente/password più un secondo fattore).
2. Dopo aver superato l'MFA, il sistema chiede all'utente di configurare un PIN e, se è disponibile hardware compatibile, uno o più gesti biometrici (volto, impronta).
3. Il contenitore Windows Hello è stato creato sul dispositivo.
4. Il team genera un coppia di chiavi di autenticazione pubblica/privata, preferibilmente collegato al TPM; se non è presente il TPM, è protetto dalla crittografia software.
5. La chiave privata è memorizzata localmente, sigillata dal TPM quando ne esiste uno e contrassegnata come non esportabile.
6. La chiave pubblica è registrata nell'IdP associato all'account dell'utente:
   • Negli ambienti cloud, il servizio di registrazione del dispositivo lo scrive nell'oggetto utente Microsoft Enter ID.
   • Negli scenari locali, AD FS archivia la chiave in Active Directory.

Da quel momento in poi, quando l'utente sblocca il dispositivo con un PIN o con dati biometrici, in realtà "attiva" l'uso di quella chiave privata di Hello per dimostrare la propria identità all'IdP.

3. Dettagli del contenitore Windows Hello e tipi di chiave

Il contenitore Windows Hello non memorizza solo una chiave: può contenere diversi tipi di materiale crittograficoOgnuno ha la sua funzione e il suo "protettore". Ogni protettore crittografa la propria copia della chiave di autenticazione con una tecnica diversa (ad esempio, sigillando in TPM utilizzando il PIN come entropia o crittografando simmetricamente il PIN in assenza di TPM).

All'interno del contenitore possiamo trovare:

• Un chiave di autenticazione primariaSempre una coppia asimmetrica (pubblica/privata) creata durante la registrazione. Questa è quella che deve essere sbloccata ogni volta tramite un PIN o dati biometrici. Se l'utente reimposta il PIN, un Nuova password e tutto il materiale protetto dal precedente viene nuovamente crittografato con quello nuovo.
• Uno o più chiavi identificative utente (Chiavi ID utente): possono essere simmetriche o asimmetriche a seconda dell'IdP e del modello di trust. Nelle implementazioni basate su certificati, queste chiavi vengono utilizzate per generare richieste alla CA o per RDP, VPN, ecc.
• Facoltativamente, a chiave amministrativa, progettato per scenari di ripristino (ad esempio, recupero del PIN) e dati associati al TPM del dispositivo.

Le chiavi identificative dell'utente vengono utilizzate per dimostrare il possesso della chiave privata davanti al servizio (ad esempio, firmando un nonce). Active Directory, Microsoft Entra ID e gli account Microsoft personali richiedono coppie di chiavi asimmetriche; il dispositivo genera la coppia, registra la parte pubblica e protegge la parte privata, che non lascia mai il dispositivo.

Se la tua organizzazione dispone di una PKI aziendale, puoi associare le chiavi identificative utente a certificati rilasciati dalla tua CACiò consente a WHfB di integrarsi con applicazioni dipendenti dai certificati (VPN classiche, RDP con smart card, ecc.). Se non è necessaria una PKI, l'IdP stesso può generare e gestire questo materiale di identificazione per ridurre la complessità.

4. Sincronizzazione delle chiavi in ​​ambienti ibridi

Nelle distribuzioni ibrideQuando Microsoft Entra ID e Active Directory coesistono, è necessaria una fase aggiuntiva: sincronizzare la chiave pubblica Hello dal cloud alla directory locale in modo che i controller di dominio possano autenticare gli utenti.

La chiave pubblica è memorizzata nell'attributo msDS-KeyCredentialLink dell'oggetto utente in Active Directory e la sincronizzazione è gestita da Sincronizzazione Microsoft ConnectSenza questa replica, sarebbe impossibile per un dominio locale verificare l'autenticazione basata su WHfB da un dispositivo unito a Microsoft Entra.

5. Registrazione del certificato (quando si utilizza Certificate Trust)

Nei modelli in cui WHfB si basa su certificati per l'autenticazione Kerberos o applicazioni localiSi apre una fase ulteriore: la registrazione dei certificati.

Una volta registrata la chiave, il client genera una richiesta di certificato e la invia al Autorità di registrazione dei certificati (CRA)La CA risiede in genere sul server AD FS e orchestra la richiesta alla PKI aziendale. La CA emette il certificato, che viene archiviato nel contenitore Hello dell'utente sul dispositivo e utilizzato per l'autenticazione alle risorse locali che richiedono un certificato smart card o simile.

Autenticazione giornaliera, SSO e ruolo della sicurezza hardware

Nella vita di tutti i giorniQuando l'utente accende o sblocca il computer, l'autenticazione si basa sempre sulla parte privata delle credenziali di Windows Hello (chiave o certificato), più il gesto dell'utente (PIN o dati biometrici). Questo gesto non viene mai inviato all'IdP né memorizzato come tale nel sistema.

L'autenticazione è, di fatto, due fattori:

• Qualcosa che l'utente possiede: la chiave o il certificato associato al dispositivo.
• Qualcosa che l'utente conosce o è: un PIN locale o dati biometrici.

Quando l'utente immette il PIN o utilizza l'impronta digitale/riconoscimento facciale, Windows rilascia la chiave di autenticazione dal suo contenitore e la utilizza per firmare crittograficamente i dati inviati all'IdPIl provider di identità confronta questa firma con la chiave pubblica memorizzata e, se tutto corrisponde, emette i token necessari per accedere alle risorse (Microsoft 365, applicazioni SaaS, risorse locali, ecc.).

Né il PIN né il modello biometrico uscire dal dispositivoIl PIN non viene nemmeno memorizzato come testo: funge da entropia per le operazioni crittografiche e per sbloccare il materiale protetto da TPM. L'IdP vede solo la prova crittografica che l'utente controlla la chiave privata registrata.

Master Refresh Token (PRT) e SSO moderno

El Single Sign-On Nel moderno mondo Microsoft, c'è un token chiave: il Token di aggiornamento primario (PRT)Si tratta di un token Web JSON che include attestazioni utente e dispositivo e consente l'accesso SSO alle applicazioni protette da Microsoft Entra ID o AD FS.

Il PRT si ottiene a accedi o sblocca il dispositivo con una credenziale attendibile (WHfB o credenziali tradizionali), in modo analogo a come veniva precedentemente ottenuto il Kerberos TGT in un ambiente esclusivamente on-premise. Sui dispositivi:

• Unisciti a Microsoft. o ibridi collegati a Microsoft Enter: il PRT viene rilasciato al momento dell'accesso stesso.
• Dispositivi personali registrati (BYOD): il PRT viene generato quando un account aziendale o scolastico viene aggiunto al dispositivo.

Senza PRT, gli utenti dovrebbero immettere continuamente credenziali e criteri di accesso condizionale in base allo stato del dispositivo. non poteva essere valutatoCon WHfB e un PRT valido, si ottiene un SSO fluido, condizionato anche dallo stato dell'apparecchiatura, dalla conformità, dal rischio, ecc.

Impostazioni principali dei criteri: SSO e sicurezza hardware

WHfB offre una vasta gamma di impostazioni dei criteri sia tramite CSP (per MDM come Intune) sia tramite GPO. Molti di questi sono focalizzati sul rafforzamento dell'SSO e sulla garanzia che l'hardware di sicurezza disponibile sul dispositivo sia sempre utilizzato.

Utilizzo obbligatorio di dispositivi di sicurezza hardware (TPM)

Una delle policy più rilevanti impone che il provisioning di Windows Hello per le aziende venga eseguito solo in dispositivi con TPM utilizzabile (1.2 o 2.0)Un TPM fornisce una protezione aggiuntiva perché la chiave privata è collegata a quel componente fisico; anche se un aggressore copia il disco, non sarà in grado di utilizzare la chiave su un altro computer.

Attraverso CSP, Questa configurazione È controllato da:

• ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice
• E, facoltativamente, l'esclusione di alcuni TPM 1.2 con:
  ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/ExcludeSecurityDevices/TPM12

Inoltre, esiste un GPO equivalente nei modelli amministrativi di Windows Hello per le aziende a livello di team. Se abilitato, Il provisioning WHfB non sarà disponibile sulle apparecchiature prive di un TPM valido., rafforzando così drasticamente la sicurezza dell'ambiente.

Configurare SSO locale: certificato vs. attendibilità cloud

Per l'SSO alle risorse locali (controller di dominio, applicazioni on-premise), WHfB può utilizzare tre principali modelli di fiducia: basato su certificato, basato su chiave (Key Trust) e, più recentemente, Fiducia Kerberos nel cloud (fiducia nel cloud).

Ci sono due politiche fondamentali:

• Utilizzo del certificato per l'autenticazione locale:
  ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCertificateForOnPremAuth
  Se abilitato, WHfB registra un certificato di accesso all'interno del contenitore e lo utilizza per l'autenticazione locale.
• Utilizzo del cloud trust per l'autenticazione locale:
  ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth
  Se abilitato, WHfB utilizza un ticket Kerberos derivato dall'autenticazione in Microsoft Entra ID per autenticarsi sulle risorse locali, senza la necessità di emettere certificati aggiuntivi.

La disabilitazione o la mancata configurazione di queste policy fa sì che il sistema ripieghi su un chiave o certificatoA seconda delle altre opzioni attive. In GPO, queste opzioni si trovano nelle sezioni Computer e Utente in Componenti di Windows > Windows Hello for Business.

Controllo principale: abilita o disabilita Windows Hello for Business

Esiste una direttiva globale per decidere se un dispositivo usare WHfB o no E se la procedura guidata di provisioning viene avviata dopo l'accesso:

• ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork
• ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/DisablePostLogonProvisioning

Con loro puoi:

• Richiedere a tutti gli utenti di eseguire il provisioning di WHfB sul dispositivo.
• Impedire completamente l'uso di WHfB.
• Consenti a ciascun utente di decidere se desidera configurare Hello.
• Impedisci alla procedura guidata di avviarsi automaticamente dopo il primo accesso, il che è utile quando Stai utilizzando una soluzione di terze parti per fornire WHfB.

Criteri PIN, recupero e controlli della complessità

Il PIN di Windows Hello È uno dei pilastri della soluzione. Sebbene molti la confondano con una password "breve", in realtà è un fattore locale legato al dispositivo, protetto dal TPM e molto meno riutilizzabile di una password tradizionale.

Scadenza, cronologia e lunghezza del PIN

Le politiche PIN ti consentono di modificare il tuo ciclo di vita e complessità in modo simile, anche se più granulare, alle password tradizionali:

• ScadenzaÈ possibile forzare la scadenza del PIN tra 1 e 730 giorni. Se il valore è 0, il PIN non scade mai (valore predefinito).
• record: definisce quanti PIN precedenti non possono essere riutilizzati, tra 0 e 50. Un valore pari a 0 indica che non viene memorizzata alcuna cronologia.
• Lunghezza minima e massima: configurabile minimo da 4 caratteri; massimo fino a 127, sempre rispettando che il minimo è inferiore al massimo e che di default, se non configurato, è richiesto un minimo di 6 caratteri.

Se queste policy non vengono impostate, il comportamento predefinito consente fino a 127 caratteri e richiede un PIN di almeno 6, senza ulteriori requisiti oltre alle regole di complessità da te definite.

Requisiti di composizione del PIN

Puoi decidere Quali tipi di caratteri sono accettati e quali sono richiesti nel PIN di Windows Hello?

• CifreSe si abilita la policy per richiedere l'inserimento di cifre, il PIN deve includere almeno un numero. Se la si disabilita, i numeri non saranno consentiti. Senza questa impostazione, i numeri sono consentiti ma non obbligatori.
• Lettere minuscole: consente di richiederne almeno uno, di proibirli completamente o di lasciarli facoltativi.
• Letras mayúsculas: stesso schema delle lettere minuscole.
• Personaggi speciali: almeno uno può essere obbligatorio, possono essere proibiti o possono essere consentiti. È considerato un ampio insieme di simboli (! " # $ % & ' ( ) + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~).

Queste regole consentono di regolare l'equilibrio tra usabilità e robustezzaTuttavia, se la complessità è eccessiva, aumenta il rischio di dimenticare PIN e ticket di supporto, un problema che molte organizzazioni cercano di evitare proprio quando adottano WHfB.

Recupero PIN

La Recupero PIN Consente all'utente di reimpostare un PIN dimenticato senza perdere le credenziali o i certificati associati (incluse le chiavi collegate agli account personali sul computer). Per fare ciò, Windows Hello crittografa un segreto di ripristino archiviato localmente, in modo che solo il servizio di ripristino e il dispositivo stesso possano decrittografarlo.

Questa funzionalità richiede all'utente di eseguire Autenticazione a più fattori rispetto a Microsoft Enter ID Per recuperare il PIN, se si abilita il criterio corrispondente (tramite CSP o GPO), Windows genererà e memorizzerà il segreto di ripristino; se lo si disabilita o lo si lascia non configurato, il dispositivo Non creerà né manterrà Il segreto e, in caso di dimenticanza del PIN, l'utente dovrà cancellarlo completamente e fornirne uno nuovo, registrandosi nuovamente ai servizi a cui il PIN precedente dava accesso.

Biometria, protezione anti-spoofing ed ESS

Biometria presso WHfB (volto, impronta digitale, iride) è un complemento al PIN, non una sua sostituzione completa. Esiste sempre un PIN di riserva per quando il sensore si guasta o il contesto non ne consente l'utilizzo.

Protezione anti-spoofing migliorata

Esiste una politica specifica da richiedere protezione avanzata contro lo spoofing (anti-spoofing avanzato) nel riconoscimento facciale. Se abilitato, Windows consentirà l'autenticazione facciale solo se il sensore e lo stack soddisfano questi requisiti avanzati di rilevamento degli attacchi (ad esempio, impedendo l'accesso tramite foto, video o semplici deepfake).

Se è disabilitato o non configurato, Windows non richiederà quella protezione avanzata e l'autenticazione facciale sarà meno restrittiva. Il percorso CSP associato è ./Device/Vendor/MSFT/PassportForWork/Biometrics/FacialFeaturesUseEnhancedAntiSpoofinge l'equivalente può essere trovato anche in GPO nelle opzioni biometriche di Windows Hello for Business.

ESS: sicurezza di accesso migliorata con periferiche

La Sicurezza di accesso avanzata (ESS) Si tratta di un livello aggiuntivo che combina VBS (Virtualization Based Security), TPM 2.0 e componenti specifici per isolare i modelli biometrici e le operazioni di confronto tramite hardware.

Con ESS, i dati biometrici (volto, impronta digitale) e i confronti vengono eseguiti in regioni di memoria isolate e protetteSi tratta di punti dati a cui il resto del sistema operativo non ha accesso diretto. Anche il canale tra i sensori e l'algoritmo è protetto, in modo che malware o aggressori non possano iniettare o riprodurre dati biometrici falsi per simulare accessi o bloccare gli utenti.

politica EnableESSwithSupportedPeripherals consentire due valori principali:

• 0ESS è abilitato anche se sono presenti sensori periferici o integrati che non lo supportano. Le operazioni di autenticazione sono consentite con questi dispositivi, con alcune limitazioni. Questa non è l'opzione più consigliata.
• 1ESS abilitato peccato Accetta sensori non ESS periferici o integrati. In altre parole, le operazioni biometriche da qualsiasi dispositivo che non supporti ESS sono bloccate per Windows Hello. Questa è la configurazione con maggiore sicurezza.

Se è disabilitato o non configurato, sui dispositivi ESS lo farà Bloccano i sensori. che non sono compatibili con ESS, mantenendo un approccio conservativo alla sicurezza.

Utilizzo della biometria in generale

politica Usa dati biometrici Controlla se Windows Hello for Business consente l'uso di gesti biometrici o se sono supportati solo i PIN. Se abilitato o non configurato, i gesti biometrici sono consentiti; se disabilitato, il loro utilizzo è vietato e gli utenti dovranno sempre autenticarsi con un PIN. PIN o altri fattori.

In ogni caso, dati biometrici:

• Sono immagazzinati solo sul dispositivo locale (banca dati in C:\Windows\System32\WinBioDatabase).
• Ogni sensore ha il proprio file e una chiave univoca generata casualmente, crittografata con AES in modalità CBC e hash SHA-256.
• Non vengono inviati a server esterni né sincronizzati tra computer, impedendo agli aggressori di creare punti di raccolta unici.

Integrazione con smart card e applicazioni legacy

Molte organizzazioni fanno ancora affidamento su smart card e applicazioni che attendono certificati "tipo smart card"WHfB incorpora opzioni per emulare o integrare questi ambienti senza perdere i vantaggi dell'autenticazione moderna.

Emulazione ed enumerazione di smart card

per impostazione predefinita,Windows impedisce agli utenti sullo stesso computer di visualizzare le credenziali di Windows Hello fornite ad altri utenti. Un criterio consente di escludere l'accesso nei seguenti casi:

• Lo stesso utente può avere account con e senza privilegi sullo stesso computer.
• Vuole accedere con l'account "normale", ma aumentare i privilegi prima di disconnettersi, utilizzando le sue credenziali Hello.

C'è anche la possibilità di Disabilitare l'emulazione della smart cardSe abilitate, le credenziali WHfB non saranno più compatibili con le applicazioni che richiedono una smart card. Se disattivate o non configurate, Windows continuerà a fornire questa emulazione automaticamente.

Utilizzare i certificati Hello come certificati smart card

Un'altra politica importante es UseHelloCertificatesAsSmartCardCertificatesSe abilitato, le applicazioni possono gestire il Certificati Windows Hello per le aziende, come i certificati smart card.Tuttavia, in tale contesto, i fattori biometrici Non sono disponibili quando viene richiesta l'autorizzazione all'utilizzo della chiave privata del certificato.

Se non è configurato o è disabilitatoLe applicazioni non utilizzano i certificati Hello in questo modo e i dati biometrici rimangono disponibili all'utente. Non è possibile attivare questa opzione contemporaneamente alla policy che disabilita l'emulazione della smart card.

Requisiti per i certificati PKI, CRL e controller di dominio

Nelle distribuzioni in cui WHfB deve fornire SSO alle risorse locali utilizzando certificati e KerberosL'infrastruttura PKI e dei certificati deve essere configurata correttamente, soprattutto se sono presenti dispositivi connessi solo a Microsoft. Inserisci che verrà autenticato tramite Active Directory.

Punto di distribuzione CRL accessibile dai dispositivi connessi a Entra

Uno dei punti critici è il elenco di revoca dei certificati (CRL)Quando una CA revoca un certificato, aggiunge informazioni a questo elenco e Windows lo consulta per convalidare se il certificato è ancora valido.

In molti ambienti on-premise il CDP (CRL Distribution Point) è pubblicato come percorso LDAP in Active DirectoryQuesta soluzione funziona bene per i computer aggiunti a un dominio, ma non per i dispositivi aggiunti solo a Microsoft Entra, che non possono leggere Active Directory prima di autenticarsi. Questo crea una dipendenza circolare: per convalidare il certificato del controller di dominio, è necessario leggere Active Directory, ma non è possibile leggere Active Directory senza prima autenticarsi.

La soluzione è pubblicare il CDP in un server web accessibile tramite HTTP (non HTTPS)che non richiede autenticazione preventiva. La procedura tipica prevede:

• Installare IIS o un altro server Web su un server interno.
• Creare una directory virtuale (ad esempio, cdp) che punta a una cartella condivisa in cui la CA può pubblicare le CRL.
• Regolare NTFS e condividere le autorizzazioni in modo che la CA possa scrivere in quella cartella.
• Creare un record DNS (ad esempio, crl.midominio.com) che punta a quel server.
• Configurare la trasmissione AC per includere un CDP HTTP nelle estensioni dei certificati emessi e pubblicare la CRL e la delta CRL in tale sede.

Dopo È necessario forzare la pubblicazione di un nuovo CRL e verificare che sia possibile accedervi da un browser. http://crl.tudominio.com/cdp e visualizza i file .crl generato.

Rilascio del certificato del controller di dominio e rigorosa convalida KDC

I certificati già emessi non vengono aggiornati automaticamente con il nuovo CDP; rinnovarliNello specifico, i certificati del controller di dominio utilizzati per l'autenticazione Kerberos. WHfB impone questa funzionalità. "Validazione rigorosa KDC" Quando un dispositivo aggiunto a Microsoft Entra esegue l'autenticazione su un dominio locale, il certificato DC deve soddisfare diversi requisiti:

• Il DC deve possedere la chiave privata del certificato presentato.
• La CA radice che ha emesso il certificato DC deve essere in radici di fiducia Del dispositivo.
• Devi usare il Modello di certificato di autenticazione Kerberosnon vecchi modelli.
• Il certificato deve includere l'EKU di Autenticazione KDC.
• Il nome alternativo del soggetto deve contenere un nome DNS che corrispondere al nome di dominio.
• L'algoritmo di firma deve essere almeno SHA256.
• La chiave pubblica deve essere RSA a 2048 bit.

Dopo aver configurato la CA e rinnovato i certificati DC, è necessario verificare nella scheda dei dettagli di ciascun certificato che sia presente il CDP HTTP corretto. Questo è fondamentale per Dispositivi uniti solo ai controller di dominio trust Entra durante l'autenticazione con WHfB.

Implementare il certificato radice CA sui dispositivi uniti a Entra

Infine, i dispositivi connessi a Microsoft Entra Devono fidarsi della CA radice dell'azienda. Ciò si ottiene esportando il certificato radice dalla catena di attendibilità del certificato DC e distribuendolo ai computer, ad esempio, utilizzando:

• Una politica di certificato di fiducia dell'attrezzatura in Microsoft Intune, puntando all'archivio radice attendibile del team.
• Oppure metodi equivalenti in altre soluzioni MDM/gestite.

Se questo passaggio viene omesso, anche se tutti gli altri elementi sono configurati correttamente, i dispositivi non considereranno attendibili i DC e le autenticazioni con WHfB. Falliranno a livello TLS/certificato.

Windows Hello for Business rappresenta un significativo passo avanti in termini di sicurezza ed esperienza di accessoSostituisce le password con credenziali collegate al dispositivo, protette da hardware e gestite centralmente, offrendo un SSO moderno e resistente al phishing sia in ambienti cloud che on-premise. Tuttavia, affinché funzioni davvero bene, è necessario prendere sul serio la preparazione dell'infrastruttura di identità e PKI, definire policy appropriate per PIN, dati biometrici e utilizzo obbligatorio del TPM, e tutto ciò deve essere accompagnato da un'implementazione graduale con una comunicazione chiara agli utenti, in modo che il cambiamento sia percepito come un miglioramento e non come un'ulteriore complicazione IT.