Stefano Nieri

Windows Hello for Business: vantaggi, limiti e come risolvere i problemi più comuni

Visualizzazioni: 652

Molti clienti desiderano portare l’esperienza MFA anche sul logon di Windows, ma scoprono presto che non è così semplice. Il motivo è che il logon locale non supporta lo stesso flusso MFA che utilizziamo per accedere alle risorse cloud con un bel pop-up-one da MS Authenticator. Per rispondere a questa esigenza, Microsoft ha introdotto Windows Hello for Business (WHfB), una soluzione passwordless che negli anni si è evoluta per accompagnare le aziende verso il cloud-first. Ma, come spesso accade, la teoria è una cosa e la pratica un’altra: implementare WHfB in ambienti reali porta con sé vantaggi, limiti e una serie di domande che meritano risposte concrete.

In questo articolo condivido le lezioni apprese “sul campo”, affrontando i dubbi più comuni, le best practice e le soluzioni ai problemi che emergono quando si porta WHfB nelle realtà italiane, tra cloud, ambienti ibridi e legacy che non vogliono proprio andare in pensione.

Ma la licenza? Davvero posso scroccarla a MS? Dici che è facile implementarlo?

Windows Hello for Business non richiede necessariamente una licenza Microsoft Entra ID P1 visto che può essere utilizzato anche con un tenant gratuito di Microsoft Entra ID in scenari semplici, come:

  • Ambienti cloud-only, dove non è necessario accedere a risorse on-premises;
  • Dispositivi gestiti tramite MDM (Mobile Device Management), come Microsoft Intune o altri MDM supportati.

Tuttavia, se vogliamo parlare del mondo reale, dove sono richieste funzionalità avanzate come provisioning automatico, Conditional Access o l’implementazione WHfB in scenari ibridi complessi, una licenza Entra ID P1 diventa praticamente indispensabile.

Disporre di Entra ID P1 (e possibilmente Intune) permette una corretta e graduale distribuzione di WHfB. Questo approccio è utile ad evitare che WHfB venga attivato automaticamente su tutti i dispositivi nuovi o impostato tramite Autopilot. Per questo motivo la rimozione o disabilitazione tenant-wide enrollment policy del parametro di configurazione di WHfB in Microsoft Intune Admin Center può essere una scelta strategica per una distribuzione più graduale e controllata. Al seguente url trovate informazioni inibirlo con un click Configure a tenant-wide Windows Hello for Business policy with Microsoft Intune – Microsoft Intune | Microsoft Learn

Figura 1 – Windows Hello for Business Cloud kerberos Trust


Da anni propongo principalmente l’implementazione di WHfB in modalità Cloud Kerberos Trust, ideale per ambienti ibridi con una forte spinta verso il cloud-first. Diciamo che “va via come il pane” perché pensata per semplificare l’autenticazione in ambienti in cui Entra è centrale, ma esiste ancora una dipendenza da Active Directory. In Italia, dove gli ambienti ibridi sono ancora molto diffusi, questa soluzione è estremamente richiesta: consente ai dispositivi Hybrid Entra AD Join di autenticarsi usando Kerberos senza la necessità di un’infrastruttura PKI (Certificate Trust) o della configurazione Key Trust.

Morale: due click di setup e tutti felici!
(poche storie, setup rapido, poca infrastruttura, poca manutenzione)

Se volete approfondire come implementare WHFB in modalità Cloud Kerberos Trust vi rimando a questo articolo di Roberto Adozione del modello Hybrid Cloud Trust (preview) per Windows Hello for Business – ICT Power

Il caso shoulder surfing

Il tempo passava sereno, anni di spensieratezza a distribuire pagnotte di WHfB dal forno Cloud Kerberos Trust, fino a quando sento bussare alla mia porta una famosa multinazionale italiana a farmi pelo e contro pelo in merito agli aspetti legati alla sicurezza della soluzione.

Questa azienda, con una forte sensibilità riguardo alla proprietà intellettuale e sicurezza dei brevetti, voleva evitare ogni fianco aperto riguardo furto di dati. Quello che mi hanno evidenziato è che WHFB, se configurato base permette il login sul device con il solo PIN.
“Giusto!” dico io e siccome stiamo facendo un cammino verso il mondo passwordless, WHfB con PIN porta tutta questa serie di benefici… “siamo in una botte di ferro”:

“Caro SNieri” mi dicono “per noi non è sufficiente. Il nostro personale è in giro in tutti il mondo, in posti molto affollati e non possiamo permetterci attacchi shoulder surfer” …

Per completezza, il “shoulder surfer attack” è una forma di attacco visivo molto spesso sottovalutato; si riferisce a una persona che cerca di rubare informazioni sensibili osservando lo schermo o la tastiera di qualcun altro, tipicamente mentre digita una password, un PIN o altri dati riservati.

A quel punto mi è apparsa in testa un’immagine distinta che mi ha fatto preoccupare sia per le spalle che per altre zone del corpo. Purtroppo, Copilot non mi ha permesso di utilizzare una foto di Rocco: vabbeh, rende comunque l’idea del pericolo!

Figura 2 – Shoulder surfer attack

Ok, per venire in contro alle esigenze del cliente e proteggerlo innalzando ulteriormente il livello di sicurezza dagli attacchi shoulder surfer, MS mette a disposizione una funzionalità chiamata Multi-factor unlock. Per approfondire l’implementazione di Multi-Factor Unlock al seguente link trovate l’articolo di Nicola Configurare il Multi-factor Unlock con Windows Hello for Business e il proprio smartphone – ICT Power

Si tratta di un’estensione avanzata della sicurezza che consente di richiedere più fattori di autenticazione per sbloccare un dispositivo Windows, andando oltre il semplice utilizzo di PIN o biometria. Lo sblocco multi-factor comporta necessariamente un secondo fattore di unlock. La funzionalità Multi-factor unlock prevede che:

  • I provider di credenziali di sblocco utilizzabili per il primo fattore siano:
    • PIN
    • Impronta digitale
    • Riconoscimento facciale
  • I provider di credenziali di sblocco per il secondo fattore siano:
    • Segnale attendibile (Phone proximity, Network location)
    • PIN

Qualsiasi fattore usato per soddisfare il primo sblocco non può essere usato per soddisfare il secondo sblocco: ogni fattore può pertanto essere utilizzato una sola volta.

I provider di segnale attendibili (Phone proximity, Network location) possono essere specificati come parte dell’elenco di provider di credenziali solamente nel secondo fattore sblocco.

Grazie a questa funzionalità estesa di WHfB il cliente ha scelto il metodo di autenticazione con digitazione PIN + un segnale Bluetooth per effettuare il login ad un dispositivo (diventando a tutti gli effetti un’autenticazione a due fattori).

Questo tipo di configurazione sul cliente ha:

  • Consentito di configurare l’accesso diretto ai devices tramite fingerprint o facial recognition
  • Vincolato il PIN il secondo fattore – qualcosa che l’utente conosce (il PIN) con qualcosa che l’utente possiede (il dispositivo Bluetooth) – incrementando la sicurezza evitando possibili attacchi shoulder surfer. 
  • Cliente soddisfatto
  • Io felice

Figura 3 – Multi-factor unlock con Windows Hello for Business

Ehh ma provisioning non parte in automatico e tra l’altro con la VPN da problemi!

Altra dinamica interessante che succede spesso con clienti “legacy”, con forte utilizzo della di VPN e “non usiamo Intune come MDE” è il seguente.

Implementazione WHfB ovviamente in Cloud Kerberos Trust, soliti due click con setting WH gestiti by GPO e dopo una settimana chiamano allarmati “SNieri, la soluzione implementata NON funziona”, abbiamo questi problemi:

  • il provisioning iniziale dell’utente in WHfB va saltuariamente
  • Quando i colleghi si connettono da casa by VPN, gli si presenta un messaggio che gli dice di mettere in lock il device e di riautenticarsi

WHfB first provisioning

Dando per scontato che tutti i requisiti siano soddisfatti (OS device, Entra Join e Hybrid Join, TPM, connettività verso Internet e verso i DC e settings WHfB applicati) il primo provisioning in WHfB potrebbe non avvenire al primo login.

Figura 4 – Windows Hello for Business first provisioning

WHfB Cloud Trust è progettato per funzionare in ambienti ibridi, ma la modalità di login può influenzare il flusso di provisioning. Quando si accede al device loggandosi con dominio\username, il sistema potrebbe non riconoscere immediatamente l’utente come Entra joined o hybrid joined, e quindi non attivare il provisioning WHfB. Al contrario, l’uso del UPN forza il riconoscimento dell’identità cloud e attiva correttamente il flusso WHfB. Per questo motivo è fondamentale verificare che i dispositivi siano Hybrid Azure AD Joined e che il Primary Refresh Token (PRT) sia presente controllando lo stato del PRT attraverso il comando dsregcmd /status.

Tecnicismi NERD a parte, se il cliente ha fretta e non vuole vedere e sapere cosa c’è sotto il cofano la risolve velocemente con i seguenti comandi powershell per il provisioning immediato:

Figura 5 – Windows Hello for Business manual provisioning command

VPN “Issues” con WHfB

Quando un utente fa login con WHfB da casa (o da qualsiasi punto in cui non c’è un collegamento diretto alla LAN e quindi ai Domain Controllers) effettua l’accesso offline tramite PIN o i sistemi biometrici configurati ma, nel momento in cui il PC si riconnette alla rete attraverso la connessione VPN, viene richiesto di bloccare e sbloccare il PC inserendo la password. Fino a che non si esegue questa procedura viene presentato il popup con la richiesta.

Figura 6 – Windows Hello for Business autenticazione con VPN

Questo è un comportamento conosciuto e documentato di WHfB con Cloud Trust. Quando il dispositivo torna online, il sistema tenta di rinnovare i ticket Kerberos e validare l’identità. Se il PIN è stato usato offline, il sistema può richiedere una ri-autenticazione per garantire la sicurezza. Capita spesso quando il ticket TGT non può essere rinnovato automaticamente oppure se il DC AzureADKerberos non è raggiungibile per completare l’autenticazione. Tutto questo processo è documentato in questo articolo Microsoft Entra hybrid join authentication using cloud Kerberos trust
ed passaggio in cui avviene il blocco è proprio sul punto F.

Ne approfitto per lasciarvi i riferimenti alla documentazione e qualche url interessante su cui approfondire:

Almeno con WHfB posso scordarmi della password

La domanda del “mi posso scordare delle password?” mi viene sempre posta.

Si, è vero che posso scordarmela ma risponderei più con un NI.

Windows Hello for Business utilizza un modello di autenticazione basato su chiavi asimmetriche, eliminando di fatto la necessità di inviare la password al domain controller o ad Entra. Questo ha implicazioni importanti siccome l’utente può autenticarsi su app moderne anche se la password è scaduta. Le app che supportano Modern Authentication utilizzano il token ottenuto tramite WHfB e tanto gli basta.

Se però accediamo a legcy apps, il comportamento è completamente diverso perché si basano su protocolli come NTLM, Kerberos o Basic Auth. In questi casi l’app tenta di usare la password dell’utente per autenticarsi e, se la password è scaduta, l’autenticazione ovviamente fallisce.

Figura 7 – Windows Hello for Business scadenza password

Considerazioni operative

  • VPN non Always-On: Se la password è scaduta e l’utente è remoto, può trovarsi bloccato fuori dal sistema. WHfB non può aggiornare la password, e il tunnel VPN potrebbe non attivarsi prima del login.microsoft (con questo caso racchiudo il 90% delle VPN che ho visto implementate nei clienti).
  • SSPR (Self-Service Password Reset) può aiutare, ma solo se il dispositivo ha line-of-sight (connettività) al Domain Controller o è configurato per usare Entra ID direttamente.
  • N.B.: stiamo parlando di password scaduta quindi
    nel caso di utente scaduto (o disabled) riceveremo un bel Ciaone al login.

Capite quindi che se nelle realtà aziendali in cui operiamo è molto improbabile dimenticarsi completamente della password. WHfB migliora la user experience e la sicurezza, ma la compatibilità con app legacy può creare frizioni.

Ne approfitto per lasciarvi i riferimenti alla documentazione e qualche url interessante su cui approfondire:

Conclusioni

Windows Hello for Business rappresenta oggi una delle soluzioni più efficaci per abilitare l’autenticazione passwordless in ambienti aziendali, sia cloud che ibridi. L’esperienza sul campo dimostra che, con la giusta pianificazione e attenzione ai dettagli (licenze, modalità di trust, gestione dei device e delle VPN), è possibile ottenere un livello di sicurezza superiore e una user experience moderna.

Tuttavia, è importante ricordare che la transizione verso il passwordless non è sempre “plug & play”: la compatibilità con applicazioni legacy, le dinamiche di provisioning e le esigenze di sicurezza avanzata (come la protezione dagli attacchi shoulder surfer) richiedono un approccio consapevole e personalizzato.

La chiave del successo è la capacità di ascoltare le esigenze specifiche del cliente, scegliere la modalità di implementazione più adatta e sfruttare le funzionalità avanzate come il Multi-factor Unlock. Solo così è possibile garantire una migrazione graduale, sicura e senza sorprese.

Figura 8 – Windows Hello for Business soluzione passwordless

In sintesi: WHfB è “pane quotidiano” per chi lavora nell’IT moderno, ma come ogni buon pane, va preparato con cura, attenzione e gli ingredienti giusti. E tu, sei pronto a sfornare la tua soluzione passwordless?