• Cloud, Guide, Microsoft 365, Sicurezza
• 18 Agosto 2026

Windows Hello for Business permette agli utenti di accedere a Windows e alle risorse aziendali senza utilizzare ogni volta la password. L’autenticazione avviene attraverso un PIN oppure un dato biometrico, come l’impronta digitale o il riconoscimento del volto.

Il PIN non è una password più corta. È legato al singolo dispositivo e serve a sbloccare una chiave privata che, quando possibile, viene protetta dal TPM. Il PIN non viene trasmesso in rete e non può essere utilizzato per accedere da un altro computer.

Accanto a Windows Hello for Business vedremo anche le chiavi di sicurezza FIDO2, oggi indicate da Microsoft anche come passkey archiviate su security key. Questi dispositivi USB o NFC permettono di autenticarsi senza password e possono essere particolarmente utili per gli utenti che lavorano su più computer o utilizzano postazioni condivise.

In questa guida utilizzeremo un ambiente ibrido, composto da Active Directory on-premises, Microsoft Entra ID ed Entra Connect. I computer saranno configurati come Microsoft Entra hybrid joined e utilizzeremo Cloud Kerberos Trust per consentire agli utenti autenticati con Windows Hello for Business o con una chiave FIDO2 di accedere anche alle risorse locali protette da Kerberos.

Cloud Kerberos Trust è il modello raccomandato da Microsoft per le nuove implementazioni ibride. Rispetto ai precedenti modelli key trust e certificate trust, semplifica il deployment perché non richiede la distribuzione di certificati di autenticazione agli utenti né la sincronizzazione delle chiavi pubbliche di Windows Hello in Active Directory.

Vedremo quindi come preparare l’ambiente, configurare le policy, registrare il PIN e la chiave FIDO2 e verificare l’accesso sia a Windows sia alle risorse on-premises senza utilizzare la password.

Scenario utilizzato nella guida

Per le demo utilizzeremo un dominio Active Directory on-premises sincronizzato con Microsoft Entra ID attraverso Entra Connect. Gli utenti manterranno la stessa identità nei due ambienti e i computer Windows saranno configurati come Microsoft Entra hybrid joined.

L’accesso alle risorse locali verrà gestito tramite Cloud Kerberos Trust. Quando l’utente accede con Windows Hello for Business o con una chiave FIDO2, Microsoft Entra ID rilascia un ticket Kerberos parziale che viene successivamente utilizzato dai domain controller per ottenere i ticket necessari ad accedere alle risorse del dominio.

Prerequisiti

Prima di procedere è necessario verificare che la sincronizzazione di utenti e dispositivi tramite Entra Connect funzioni correttamente. I dispositivi interessati devono risultare registrati in Microsoft Entra ID come Microsoft Entra hybrid joined.

Cloud Kerberos Trust richiede domain controller Windows Server 2016 o successivi, aggiornati con le patch necessarie. I client devono utilizzare una versione di Windows supportata; per una nuova distribuzione è consigliabile adottare Windows 11 completamente aggiornato.

È fortemente consigliato utilizzare dispositivi dotati di TPM 2.0, che permette di proteggere in hardware le chiavi private generate da Windows Hello for Business. È tecnicamente possibile utilizzare anche chiavi software, ma in un ambiente aziendale è preferibile richiedere esplicitamente la presenza del TPM tramite policy. Se viene abilitata l’impostazione Use a hardware security device, il TPM diventa un requisito per il provisioning.

Nel tenant Microsoft Entra deve essere disponibile almeno un metodo MFA con cui l’utente possa verificare la propria identità durante il provisioning. La registrazione del PIN non dovrebbe infatti essere confusa con un semplice cambio delle opzioni di accesso locali.

Per utilizzare le chiavi di sicurezza bisogna abilitare il metodo di autenticazione Passkey (FIDO2) nelle Authentication methods policies di Microsoft Entra ID. Le chiavi utilizzate devono essere compatibili FIDO2 e, per l’accesso a Windows, deve essere consentito l’utilizzo delle security key tramite Group Policy o Microsoft Intune.

Ovviamente, durante la configurazione iniziale è necessario disporre delle autorizzazioni amministrative appropriate sia in Active Directory sia in Microsoft Entra ID. Prima di estendere la configurazione a tutti gli utenti è consigliabile utilizzare un piccolo gruppo pilota, così da verificare provisioning, accesso Kerberos e procedure di recupero.

Licenze necessarie

Per configurare Windows Hello for Business, Cloud Kerberos Trust e le chiavi di sicurezza FIDO2 non è richiesta una licenza Microsoft Entra ID Premium. È possibile realizzare le demo utilizzando Microsoft Entra ID Free.

Una licenza Microsoft Entra ID P1 è però consigliata in produzione se si vogliono utilizzare funzionalità come Conditional Access, l’enrollment automatico MDM e i report avanzati sui metodi di autenticazione. Anche l’utilizzo di Microsoft Intune richiede una licenza dedicata, mentre nella nostra demo configureremo i dispositivi tramite Group Policy.

Verifica della configurazione ibrida

Prima di configurare Windows Hello for Business è necessario verificare che Entra Connect sincronizzi correttamente gli utenti e che i computer siano registrati in Microsoft Entra ID.

Nel portale di Microsoft Entra, aprite Identity > Devices > All devices e verificate che la colonna relativa al join riporti Microsoft Entra hybrid joined e che il dispositivo risulti abilitato.

Figura 1: Dispositivo Microsoft Entra hybrid joined nel portale Microsoft Entra

La verifica più importante deve essere effettuata direttamente sul client. Dopo aver eseguito l’accesso con un utente di dominio, aprite un prompt dei comandi e lanciate:

Nella sezione Device State, i valori AzureAdJoined e DomainJoined devono essere impostati su YES. Questa combinazione conferma che il computer appartiene al dominio Active Directory ed è registrato in Microsoft Entra ID come dispositivo hybrid joined.

Verificate inoltre che DeviceAuthStatus sia impostato su SUCCESS, a conferma che l’oggetto dispositivo presente in Microsoft Entra ID è abilitato e correttamente autenticato.

Nella sezione SSO State, il valore AzureAdPrt deve risultare impostato su YES. Il Primary Refresh Token consente il Single Sign-On verso Microsoft Entra ID ed è uno dei prerequisiti per il provisioning di Windows Hello for Business.

In questa fase OnPremTgt è ancora impostato su NO, perché non abbiamo ancora distribuito Microsoft Entra Kerberos. Anche NgcSet è impostato su NO, dato che l’utente non ha ancora configurato Windows Hello for Business. Entrambi i valori cambieranno dopo aver completato i passaggi successivi della guida.

Figura 2: Verifica dello stato del dispositivo e del Primary Refresh Token con dsregcmd

Configurazione di Microsoft Entra Kerberos

Cloud Kerberos Trust utilizza un oggetto denominato Microsoft Entra Kerberos per consentire a Microsoft Entra ID di rilasciare un ticket Kerberos parziale per il dominio Active Directory.

L’oggetto viene creato sia nel dominio on-premises sia nel tenant Microsoft Entra. Non corrisponde a un server fisico: in Active Directory viene rappresentato come un particolare RODC e viene utilizzato esclusivamente per questo processo di autenticazione.

La configurazione deve essere eseguita per ogni dominio Active Directory che contiene utenti sincronizzati. È necessario utilizzare un account membro di Domain Admins ed Enterprise Admins e un account Microsoft Entra con il ruolo Hybrid Identity Administrator. Anche un Global Administrator può eseguire l’operazione, ma dispone di privilegi più ampi di quelli necessari.

Aprite Windows PowerShell come amministratore sul server Microsoft Entra Connect e lanciate la seguente sequenza di comandi, dopo aver modificato i parametri necessari. È possibile utilizzare un altro server soltanto se sono già presenti il modulo e le dipendenze richieste per la configurazione di Microsoft Entra Kerberos.

Figura 3: Creazione dell’oggetto Microsoft Entra Kerberos in Active Directory

Al termine della procedura, nell’OU Domain Controllers viene creato l’account computer AzureADKerberos. Anche se viene rappresentato in Active Directory come un Read-Only Domain Controller, non corrisponde a un server fisico e non deve essere modificato o eliminato manualmente.

Per impostazione predefinita, gli account appartenenti ai gruppi amministrativi protetti di Active Directory non possono utilizzare Cloud Kerberos Trust per accedere alle risorse locali. Questa limitazione dipende dalla Password Replication Policy associata all’oggetto AzureADKerberos. Microsoft sconsiglia di modificarla per consentire l’utilizzo di Cloud Kerberos Trust agli account altamente privilegiati.

Figura 4: Oggetto AzureADKerberos creato nell’OU Domain Controllers

Configurazione di Windows Hello for Business tramite Group Policy

Dopo aver creato l’oggetto Microsoft Entra Kerberos possiamo configurare i computer affinché utilizzino Windows Hello for Business con Cloud Kerberos Trust.

Aprite la console Group Policy Management, create una nuova GPO e assegnatele un nome facilmente riconoscibile, ad esempio Windows Hello for Business – Cloud Kerberos Trust

Per una prima verifica è consigliabile collegare la GPO soltanto all’OU che contiene i computer utilizzati per il test.

Modificate la GPO e raggiungete il percorso Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Hello for Business

Abilitate la policy Use Windows Hello for Business. Questa impostazione avvia il provisioning della credenziale aziendale per gli utenti che accedono ai computer interessati.

Abilitate quindi Use cloud Kerberos trust for on-premises authentication. È questa la policy che indica a Windows di utilizzare Cloud Kerberos Trust per l’accesso alle risorse Active Directory locali.

È inoltre consigliabile abilitare Use a hardware security device, in modo da consentire il provisioning soltanto sui dispositivi dotati di un TPM accessibile. In questo modo la chiave privata di Windows Hello for Business viene generata e protetta in hardware.

Verificate che la policy Use certificate for on-premises authentication non sia abilitata. Il certificate trust ha la precedenza su Cloud Kerberos Trust e potrebbe quindi impedire l’utilizzo del modello configurato in questa guida.

Figura 5: Group Policy per abilitare Windows Hello for Business con Cloud Kerberos Trust

Provisioning di Windows Hello for Business

Dopo aver configurato e collegato la GPO, eseguite sul client gpupdate /force

Riavviate quindi il computer e accedete con la password di un normale utente di dominio sincronizzato con Microsoft Entra ID. Il computer deve poter contattare sia un domain controller sia i servizi Microsoft Entra.

Se tutti i prerequisiti sono soddisfatti, Windows avvia automaticamente la configurazione di Windows Hello for Business. L’utente deve prima verificare la propria identità utilizzando un metodo MFA già registrato e successivamente scegliere il proprio PIN.

Figura 6: Avvio del provisioning di Windows Hello for Business

L’utente deve quindi verificare la propria identità utilizzando uno dei metodi MFA registrati in Microsoft Entra ID. Questa verifica viene richiesta durante la creazione della credenziale e non a ogni successivo accesso con Windows Hello for Business.

Figura 7: Verifica dell’identità dell’utente

Dopo aver completato la verifica, Windows chiede di creare un PIN. Il PIN è legato al dispositivo e serve a sbloccare la chiave privata protetta dal TPM; non viene trasmesso a Microsoft Entra ID o ai domain controller.

Figura 8: Inserimento del PIN da parte dell’utente

Figura 9: Completamento del provisioning di Windows Hello for Business

Al successivo login l’utente potrà scegliere se utilizzare la password oppure il PIN di Windows Hello for Business.

Figura 10: Accesso a Windows tramite PIN di Windows Hello for Business

Verifica della configurazione

Dopo aver completato il provisioning, disconnettetevi da Windows e accedete nuovamente utilizzando il PIN appena creato. Al primo accesso con Windows Hello for Business, il computer ibrido deve poter contattare un domain controller.

Per verificare lo stato della credenziale eseguite, nel contesto dell’utente:

Nella sezione User State, il valore NgcSet deve essere impostato su YES. Questo conferma che l’utente dispone di una credenziale Windows Hello for Business sul dispositivo.

Nella sezione SSO State verificate che AzureAdPrt e OnPremTgt siano impostati su YES. Il primo conferma che l’utente dispone di un Primary Refresh Token valido per il Single Sign-On verso Microsoft Entra ID, mentre il secondo indica che Microsoft Entra ID ha rilasciato il ticket Kerberos parziale necessario per accedere alle risorse Active Directory. Il valore CloudTgt, quando presente, riguarda invece le risorse cloud che utilizzano Microsoft Entra Kerberos e non è necessario per confermare il funzionamento dell’accesso alle risorse Active Directory locali.

La presenza contemporanea di NgcSet, AzureAdPrt e OnPremTgt conferma che Windows Hello for Business e Cloud Kerberos Trust sono stati configurati correttamente.

Figura 11: Verifica di Windows Hello for Business e Cloud Kerberos Trust tramite dsregcmd

Per completare la prova, aprite una condivisione del dominio, ad esempio \\dc01.demo.lab\SYSVOL

L’accesso deve avvenire senza richiedere nuovamente nome utente e password. Il ticket parziale ricevuto da Microsoft Entra ID viene presentato a un domain controller e sostituito con un normale TGT Active Directory, completo delle informazioni necessarie all’autorizzazione.

È possibile verificare i ticket Kerberos presenti nella sessione eseguendo:

Nell’elenco troverete il Ticket Granting Ticket del dominio DEMO.LAB e il ticket di servizio CIFS utilizzato per accedere alla condivisione. Questo dimostra che l’utente, dopo aver effettuato l’accesso con il PIN, può raggiungere le risorse on-premises senza utilizzare la password.

Figura 12: Ticket Kerberos ottenuti dopo l’accesso con Windows Hello for Business

Protezione dagli attacchi di shoulder surfing

Qualcuno potrebbe obiettare che un PIN può essere osservato mentre viene digitato, attraverso un attacco chiamato shoulder surfing. È però importante ricordare che il PIN di Windows Hello for Business non è una password: è legato al singolo dispositivo e serve esclusivamente a sbloccare la chiave privata protetta dal TPM. Conoscere il PIN, senza essere anche in possesso del computer, non permette quindi di autenticarsi da remoto o da un altro dispositivo. Negli ambienti che richiedono una protezione ancora maggiore è possibile utilizzare il Multi-factor Unlock, configurando Windows affinché richieda, oltre al PIN o alla biometria, anche un segnale attendibile come la presenza dello smartphone tramite Bluetooth, una determinata rete Wi-Fi o una specifica configurazione IP. In questo modo, anche chi riuscisse a osservare il PIN e a entrare in possesso del computer non potrebbe sbloccarlo senza il secondo fattore, purché l’organizzazione abbia gestito correttamente anche gli altri metodi di accesso disponibili come fallback. Ho descritto la configurazione completa nella guida Configurare il Multi-factor Unlock con Windows Hello for Business e il proprio smartphone.

Il Multi-factor Unlock può essere distribuito centralmente tramite la policy Configure device unlock factors, disponibile in Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business. Nell’esempio seguente il PIN rappresenta il primo fattore, mentre la presenza di un dispositivo Bluetooth attendibile viene utilizzata come secondo fattore.

Figura 13: Configurazione del Multi-factor Unlock con PIN e segnale attendibile tramite Group Policy

Dopo aver inserito il PIN di Windows Hello for Business, Windows verifica la disponibilità dello smartphone associato tramite Bluetooth. Se il dispositivo viene rilevato, compare il messaggio Additional factor verified! e l’accesso viene completato.

Figura 14: Secondo fattore verificato tramite la presenza dello smartphone associato

Se invece lo smartphone non è vicino al computer oppure il Bluetooth è disattivato, Windows rimane per alcuni istanti nella fase Verifying phone e successivamente mostra il messaggio Couldn’t verify additional factor. Il PIN è corretto, ma l’accesso con Windows Hello for Business non viene completato perché manca il secondo fattore richiesto dalla policy. L’utente può eventualmente selezionare un altro metodo disponibile tramite Sign-in options.

Figura 15: Ricerca dello smartphone configurato come Trusted Signal

Figura 16: Accesso con Windows Hello for Business non completato perché lo smartphone non è disponibile

Utilizzare una chiave di sicurezza FIDO2

Oltre al PIN di Windows Hello for Business, gli utenti possono accedere a Windows utilizzando una chiave di sicurezza FIDO2. La chiave contiene la credenziale privata e può essere utilizzata su più computer, risultando particolarmente utile nelle postazioni condivise e per gli utenti che lavorano da dispositivi differenti.

Ho già approfondito il funzionamento delle chiavi FIDO2 e mostrato la configurazione completa di una chiave FEITIAN K28E nella guida Autenticazione Passwordless con Microsoft Entra ID: configurazione e utilizzo delle chiavi FIDO2 FEITIAN K28E.

La chiave FIDO2 è indipendente dal PIN di Windows Hello for Business. Durante la registrazione viene comunque richiesto di creare un PIN della chiave, che viene verificato direttamente dal dispositivo FIDO2 e non deve essere confuso con il PIN configurato sul computer.

Prima di configurare il client è necessario verificare che il metodo di autenticazione sia abilitato in Microsoft Entra ID. Accedete al Microsoft Entra admin center con un account che disponga almeno del ruolo Authentication Policy Administrator e raggiungete Entra ID > Authentication methods > Policies > Passkey (FIDO2)

Nella scheda Enable and target, abilitate il metodo e assegnatelo al gruppo che contiene gli utenti autorizzati a utilizzare le chiavi FIDO2. Per una prima distribuzione è consigliabile utilizzare un gruppo pilota invece di selezionare tutti gli utenti.

Nella scheda Configure verificate che sia consentita la configurazione self-service e create, se necessario, un profilo dedicato alle chiavi di sicurezza. Il profilo deve consentire le passkey device-bound, perché la credenziale privata rimane memorizzata nella chiave fisica.

È possibile limitare l’utilizzo a specifici modelli attraverso gli AAGUID oppure richiedere l’attestation. Queste opzioni offrono un maggiore controllo sui dispositivi ammessi, ma per la demo utilizzeremo la configurazione predefinita senza restrizioni sul produttore.

Figura 17: Abilitazione del metodo Passkey (FIDO2) nelle Authentication methods policies di Microsoft Entra ID

Configurazione del tenant e registrazione della chiave

Per utilizzare una chiave FIDO2 nella schermata di accesso a Windows sono necessarie due configurazioni distinte.

La policy Passkey (FIDO2) di Microsoft Entra ID autorizza gli utenti a utilizzare questo metodo di autenticazione, mentre la registrazione nella pagina Security info associa materialmente la chiavetta all’account. Durante questa operazione la chiave genera una coppia crittografica: la chiave privata rimane protetta nel dispositivo FIDO2 e quella pubblica viene registrata in Microsoft Entra ID.

Sul computer è inoltre necessario abilitare Turn on security key sign-in, che attiva il credential provider FIDO2 nella schermata di accesso a Windows. Questa policy non registra automaticamente la chiavetta e non la associa all’utente.

Le configurazioni sono quindi complementari. Una chiave registrata in Microsoft Entra ID può essere utilizzata per accedere alle applicazioni web anche se il credential provider non è abilitato sul computer. Al contrario, abilitare la policy sul client senza aver prima registrato la chiave farà comparire l’opzione di accesso, ma l’utente non disporrà ancora di una credenziale FIDO2 riconosciuta dal tenant.

Non è necessario configurare preventivamente il PIN di Windows Hello for Business. Durante la registrazione verrà creato un PIN specifico della chiave FIDO2, distinto da quello eventualmente utilizzato per accedere al computer.

Registrazione della chiave FIDO2

Accedete alla pagina Security info con l’utente che dovrà utilizzare la chiave e selezionate Add sign-in method.

Nel menu dei metodi disponibili scegliete Passkey e selezionate Add. Prima di consentire la registrazione della credenziale, Microsoft Entra ID richiede una verifica MFA recente. In alternativa, l’onboarding passwordless può essere avviato utilizzando un Temporary Access Pass.

Quando viene chiesto dove salvare la passkey, selezionate Security key. Questa scelta indica che la credenziale deve essere generata e conservata nella chiavetta FIDO2, anziché nel computer o in un dispositivo mobile.

Figura 18: Aggiunta di una passkey nelle informazioni di sicurezza dell’utente

Durante la procedura Microsoft Entra ID richiede una verifica MFA recente, l’inserimento della chiave e la configurazione del relativo PIN. Non ripercorreremo qui tutti i passaggi, che ho già descritto nella guida Autenticazione Passwordless con Microsoft Entra ID: configurazione e utilizzo delle chiavi FIDO2 FEITIAN K28E.

Durante la registrazione viene richiesto il PIN della chiave di sicurezza. Se la chiavetta è nuova, Windows chiederà di crearne uno; se è già stata inizializzata, sarà necessario inserire il PIN esistente.

Il PIN viene verificato direttamente dalla chiave FIDO2 e protegge l’utilizzo delle credenziali conservate al suo interno. Non coincide con il PIN di Windows Hello for Business e non viene memorizzato in Microsoft Entra ID.

Figura 19: Inserimento del PIN della chiave di sicurezza FIDO2

Dopo aver inserito il PIN, Windows richiede di toccare la chiave di sicurezza. Questa operazione verifica la presenza fisica dell’utente e impedisce che la credenziale venga utilizzata senza un’interazione volontaria.

Figura 20: Verifica della presenza dell’utente tramite la chiave FIDO2

Al termine della procedura, la chiave viene mostrata nelle Security info come Passkey device-bound. La definizione device-bound indica che la chiave privata rimane memorizzata nel dispositivo FIDO2 e non viene sincronizzata o trasferita su altri dispositivi.

Nell’esempio è stata registrata una chiave FEITIAN K28E, che potrà ora essere utilizzata per autenticarsi a Microsoft Entra ID e, dopo aver applicato la policy al client, anche per accedere a Windows.

Figura 21: Chiave FIDO2 registrata tra i metodi di autenticazione dell’utente

Abilitazione delle chiavi FIDO2 per l’accesso a Windows

Dopo aver abilitato il metodo Passkey (FIDO2) in Microsoft Entra ID, è necessario consentire l’utilizzo delle chiavi di sicurezza anche nella schermata di accesso a Windows.

Nel nostro ambiente Microsoft Entra hybrid joined distribuiremo questa impostazione tramite Group Policy. Aprite la console Group Policy Management e modificate la GPO applicata ai computer interessati, oppure createne una nuova dedicata alle chiavi FIDO2.

Raggiungete il percorso Computer Configuration > Policies > Administrative Templates > System > Logon e abilitate la policy Turn on security key sign-in. Questa impostazione attiva il credential provider necessario per mostrare la chiave di sicurezza tra le opzioni disponibili nella schermata di accesso a Windows.

Se la policy non è presente, aggiornate i template amministrativi utilizzando una versione recente del file CredentialProviders.admx e del relativo file della lingua CredentialProviders.adml.

Figura 22: Abilitazione dell’accesso a Windows tramite chiavi di sicurezza FIDO2

Accesso a Windows con la chiave FIDO2

Dopo aver registrato la chiave e applicato la policy al computer, disconnettete l’utente e selezionate Sign-in options nella schermata di accesso a Windows.

Tra i metodi disponibili compare ora l’icona della Security key. Selezionatela e inserite la chiave FIDO2 in una porta USB.

Figura 23: Selezione della chiave FIDO2 nella schermata di accesso a Windows

Windows riconosce la chiave e richiede il relativo Security Key PIN. Il nome dell’utente non deve essere digitato, perché la chiavetta contiene le informazioni necessarie a individuare l’account Microsoft Entra associato alla credenziale.

Figura 24: Inserimento del PIN della chiave FIDO2

Dopo aver inserito il PIN è necessario toccare la chiave per confermare la presenza fisica dell’utente. Microsoft Entra ID verifica la firma generata dalla chiavetta utilizzando la chiave pubblica registrata nell’account e, se il controllo ha esito positivo, autorizza l’accesso a Windows.

Figura 25: Accesso a Windows completato tramite chiave di sicurezza FIDO2

L’intera procedura avviene senza inserire il nome utente o la password dell’account. Per autenticarsi sono necessari sia il possesso della chiave FIDO2 sia la conoscenza del relativo PIN, offrendo così un metodo di accesso passwordless e resistente al phishing.

Come si può vedere dalla figura sotto, l’accesso è stato effettuato con l’utente di dominio Active Directory, anche se l’autenticazione è avvenuta tramite Microsoft Entra ID utilizzando la chiave FIDO2.

Figura 26: Accesso all’account di dominio completato tramite chiave FIDO2

L’utente ha quindi aperto una normale sessione di dominio senza inserire la propria password. Grazie a Microsoft Entra Kerberos potrà inoltre ottenere i ticket necessari per accedere alle risorse Active Directory on-premises.

Utilizzare le chiavi FIDO2 senza configurare Windows Hello for Business

Un’azienda può decidere di non distribuire Windows Hello for Business e di utilizzare le chiavi di sicurezza FIDO2 come metodo principale per accedere ai computer di dominio.

In questo scenario la policy Use Windows Hello for Business non viene applicata agli utenti, evitando così la richiesta di configurazione del PIN. Sui computer viene invece distribuita la Group Policy Turn on security key sign-in, che abilita il credential provider FIDO2 nella schermata di accesso a Windows.

La chiave deve essere stata precedentemente registrata nell’account Microsoft Entra ID dell’utente, ma la registrazione può essere effettuata da un altro computer. La credenziale è infatti conservata nella chiavetta e associata all’identità dell’utente nel tenant, non alla macchina dalla quale è stata registrata.

Nell’esempio seguente si tratta del primo accesso dell’utente al computer, non del primo avvio o della prima configurazione del dispositivo. Il computer ha già completato il Microsoft Entra hybrid join e ha ricevuto le Group Policy necessarie, mentre l’utente non ha configurato alcun PIN di Windows Hello for Business. Nella schermata Sign-in options sono disponibili soltanto la password e la chiave di sicurezza; l’icona del PIN non è presente.

Figura 27: Chiave FIDO2 disponibile su un computer nel quale l’utente non ha mai effettuato l’accesso

Figura 28: Accesso a Windows completato tramite chiave di sicurezza FIDO2

L’utente deve semplicemente selezionare la chiave di sicurezza, inserirla nella porta USB, digitare il relativo PIN FIDO2 e toccare il dispositivo. Microsoft Entra ID identifica l’account associato alla chiave e Windows crea il profilo locale al primo accesso, senza richiedere la password e senza obbligare l’utente a configurare Windows Hello for Business.

Il computer deve aver già completato il Microsoft Entra hybrid join, aver ricevuto la Group Policy ed essere in grado di contattare sia Microsoft Entra ID sia un domain controller scrivibile. La sola abilitazione della chiave non rimuove comunque la password dalle opzioni di accesso: per impostazione predefinita rimane disponibile come metodo di emergenza.

E per gli accessi in desktop remoto?

Le credenziali Windows Hello for Business basate su key trust o Cloud Kerberos Trust non possono essere fornite direttamente a una normale sessione Remote Desktop. Il PIN o il dato biometrico sbloccano localmente una chiave privata protetta dal TPM e questa chiave non può essere trasferita al computer remoto. La stessa limitazione si applica all’utilizzo diretto di una chiave FIDO2 nella normale schermata di autenticazione RDP.

Nella documentazione Microsoft dedicata all’accesso RDP con Windows Hello for Business viene spiegato come utilizzare un certificato associato a Windows Hello for Business come credenziale per la connessione a un altro dispositivo Windows. In questo scenario il certificato viene presentato tramite le funzionalità di smart card reindirizzata del protocollo RDP.

Per le connessioni RDP è consigliabile utilizzare Windows Defender Remote Credential Guard, che offre il Single Sign-On tramite Kerberos senza trasmettere al computer remoto la password o altri segreti riutilizzabili.

Remote Credential Guard può quindi sfruttare la sessione aperta localmente con Windows Hello for Business o con la chiave FIDO2, mantenendo protette le credenziali anche se il computer remoto dovesse essere compromesso.

Per la configurazione e la verifica della funzionalità vi rimando alla mia guida Windows Defender Remote Credential Guard: connessioni RDP sicure e in SSO.

Conclusioni

Windows Hello for Business, Cloud Kerberos Trust e le chiavi FIDO2 permettono di accedere a Windows e alle risorse Active Directory senza utilizzare la password. Le aziende possono adottare entrambi i metodi oppure utilizzare le security key anche sui computer nei quali l’utente non ha configurato il PIN, ottenendo un’esperienza passwordless, resistente al phishing e compatibile con le risorse on-premises.