L’autenticazione a più fattori (o MFA per gli amici) è praticamente lo standard relativo alla sicurezza per molti, se non tutti, i servizi SaaS.
Nonostante la certezza di cui sopra per l’accesso ai dispositivi dotati di OS Windows la maggior parte degli utilizzatori fa ancora uso dei canonici nome utente e password, ci si augura, complesse.
Il problema con le password complesse è risultano difficili da ricordarle e, data la difficoltà intrinseca, gli utenti adottano la tecnica del riutilizzo su più strumenti.
Windows Hello for Business sostituisce di fatto le password con l’autenticazione a due fattori appoggiandosi a MFA Auth di Microsoft Azure per prima attivazione e a strumenti locali quali PIN, TPM e dispositivi biometrici per l’uso comune.
Quindi quando ci si autentica sfruttando Windows Hello for Business, possono essere utilizzati per l’accesso a Windows strumenti di riconoscimento dell’impronta digitale, di riconoscimento del viso o il sempre presente codice PIN.
Quanto sopra riportato, in combinazione con il chip TPM integrato sui device offre di fatto un accesso sicuro di tipologia Multi Factor Authentication (MFA).
In questo articolo, esamineremo come funziona Windows Hello for Business e lo implementeremo sfruttando Cloud Kerberos Trust.
Windows Hello for Business: perché è sicuro?
Windows Hello for Business (da ora in poi WHfB) permette all’utente finale di evitare di inserire password complesse, ma difficili da ricordare, sostituendole con un valido, pratico e sicuro sistema di autenticazione a due fattori.
Le autenticazioni quotidiane avvengono quindi tramite biometria o PIN e sono strettamente legate allo specifico dispositivo.
Ciò significa che Windows Hello for Business deve essere configurato su ciascun dispositivo che l’utente utilizza in quanto il “protagonista” dell’attività di configurazione inziale è di fatto un apposito chip, dotato di acronimo TPM, presente sui sistemi hardware che ospitano gli OS Windows.
L’autenticazione 2FA sopra menzionata è quindi creata da qualcosa che l’utente conosce, come ad esempio il PIN, o che il sistema riconosce di lui, come ad esempio l’impronta digitale, oltre che a qualcosa che il sistema hardware possiede in sé, come ad esempio una chiave di sicurezza che viene generata e poi conservata nel chip TPM.
La combinazione delle due informazioni, quali ad esempio il PIN inserito correttamente più la chiave conservata in TPM, viene inviata al provider di identità, in questo specifico caso Microsoft Azure AD, per attivare il token di autenticazione e permettere l’accesso.
Qui un articolo ufficiale Microsoft che parla in maniera approfondita dell’argomento.
Ma un PIN è meglio di una Password?
Bella domanda che necessita della seguente risposta immediata.
La password complessa è, come è logico che sia, più “articolata” di un PIN che potrebbe essere composto anche solamente da numeri con lunghezza minima predefinita di 6 caratteri (che è tra l’altro l’impostazione predefinita per il PIN di WHfB).
Nota: è utile sapere che in ogni caso il PIN di WHfB non può essere composto da numerazioni semplici quali 123456 o 111111! L’algoritmo interno di assegnazione inibisce l’uso di tali pratiche intrinsecamente insicure.
La differenza sostanziale tra le due, che rende il PIN di WHfB la scelta migliore, è che la password può essere utilizzata su qualsiasi dispositivo, o addirittura online nel caso di Microsoft 365, mentre il PIN di WHfB risulta espressamente legato a un dispositivo specifico (grazie a TPM).
Di conseguenza chi dovesse entrare a conoscenza del PIN di WHfB per usarlo dovrà comunque avere accesso al dispositivo specifico e non gli sarà permesso un accesso globale su tutti i dispositivi aziendali.
Uno dei problemi essenziale di entrambi è che, ad esempio in posti pubblici, possono essere “rubati” tramite canonica tecnica di “shoulder surfing“.
In sostanza ci spiano e ci rubano le informazioni di accesso. Quindi è meglio che ci rubino la password, magari utilizzata nella globalità dei sistemi di dominio aziendali (e non solo), oppure esclusivamente un PIN che può essere utilizzato esclusivamente su di una singola postazione client?
Nota: è utile sapere che il PIN di WHfB, in presenza di biometria, può essere tranquillamente sostituito dall’uso di propria impronta digitale (o riconoscimento del volto). Pratico e sicuro.
Qui la relativa Wiki dedicata all’argomento.
Nota: occorre segnalare che in quel di WHfB esiste la possibilità, che non tratteremo in questo specifico articolo, di attivare un ulteriore layer di sicurezza oltre ai primi prima menzionati. Un esempio legato a tre layer di autenticazione utilizzabili per l’accesso:
- Layer 1: inserimento PIN
- Layer 2: chiave conservata in TPM
- Layer 3 (aggiuntivo): presenza di un Trusted Signal Bluetooth (es: smartphone connesso).
Qui il link diretto al documento ufficiale Microsoft.
Attivare Cloud Kerberos Trust per Domini in Hybrid
Quando si dispone di un ambiente di Dominio configurato in Hybrid, che lega Active Directory locale e Azure AD, Cloud Kerberos Trust è il metodo di implementazione consigliato da Microsoft. Il motivo è semplice: risulta essere meno complesso rispetto ai vecchi metodi (ancora utilizzabili) come “Key Trust” o “Certificate Trust”.
Per implementare Cloud KerberosTrust, occorrerà fare uso di PowerShell attraverso inserimento di poche istruzioni.
Per distribuirlo sui dispositivi, benché risulti possibile l’uso di Intune, prenderemo in considerazione le storiche e canoniche Group Policy (GPO).
Requisiti
Per utilizzare Cloud KerberosTrust, è necessario assicurarsi di soddisfare i seguenti requisiti:
- Dominio già attivo in modalità Hybrid con Azure AD Connect adeguatamente configurato.
- Autenticazione a più fattori abilitata in Azure AD.
- Sistemi operative Client dotati di Windows 10 21H2 o Windows 11.
- Accesso a controller di dominio Windows Server 2016 o superiore (aggiornato) sul quale già si trova presente Azure AD Connect.
- Account Azure AD avente ruolo di “Global Administrator”
- Account Active Directory avente ruolo di “Domain Admin”.
- Ultime versioni di ADMX contenenti strumenti per creazioni GPO per prodotti Microsoft (quale per l’appunto WHfB).
Attivazione di Azure AD Kerberos Server
ll primo passo è attivare Azure AD Kerberos nel proprio Dominio. L’attività creerà un oggetto “Domain Controller”, acceso in modalità Read Only, in quel di Active Directory. Tale strumento verrà utilizzato per generare TGT (ticket-granting-tickets) per l’autenticazione in locale.
Qui i passi da seguire:
- Accedere con il proprio utente Domain Admin al Domain Controller e avviare PowerShell in modalità amministrativa.
- Installare il modulo PowerShell di Azure AD Kerberos sfruttando quanto segue:
[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12 Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
- Avviare in powershell i seguenti comandi introducendo come variabile $userPrincipalName il nome completo del Global Admin di Azure (a seguito dell’invio verrà richiesta attività di accesso MFA):
Info in merito a dominio in uso $domain = $env:USERDNSDOMAIN #Recupero di credenziali relative a Domain Admin in uso su DC $domainCred = Get-Credential #Nome del Global Admin di Azure $userPrincipalName = “TUOADMIN@TUOID.onmicrosoft.com” #Creazione di DC AzureADKerberos Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred
- Una volta completata l’implementazione il nuovo strumento, definito AzureADKerberos, si troverà in proprio ambiente AD posizionato in OU Domain Controllers. Qui uno screenshot:
Configurare Windows Hello for Business via Group Policies (GPO)
In un ambiente Hybrid è possibile utilizzare le Group Policy di AD per configurare Windows Hello for Business sui dispositivi.
Dato che viene utilizzato il metodo Cloud Kerberos Trust risulta possibile agire direttamente sulle impostazioni di configurazione del computer saltando a piè pari, in quanto non utili, le configurazioni ad utente.
Qui la procedura:
- Accedere da Domain Controller a strumento Group Policy Management Editor e creare una nuova policy chiamandola ad esempio Attivazione_WHfB
- Modificare la policy portandosi in: Policy > Administrative Templates > Windows Components > Windows Hello for Business
- Abilitare (Enable) le seguenti tre impostazioni:
- Use Windows Hello for Business
- Use Cloud trust for on-premise authentication
- Use a Hardware security device
Qui uno screenshot:
Nota: le suddette tre impostazioni costituiscono la base necessaria per utilizzare Windows Hello for Business in un ambiente Hybrid ma risulta possibile ovviamente attivare anche altre funzioni tra le presenti in lista. Si raccomanda comunque di eseguire canonico Testing prima di attivare il tutto globalmente. A tal proposito per questo primo step, si consiglia di abilitare l’opzione “Do not start Windows Hello provisioning after sign-in” in voce “Use Windows Hello for Business”. In questo modo agli utenti non verrà richiesto dopo l’accesso di attivare PIN di WHfB e relativi sistemi biometrici (potranno configurarli quando lo riterranno opportuno).
- Assicurarsi di assegnare la policy appena creata su computer dedicati al test.
- Forzare via Azure AD Connect la situazione di sincronia tra Azure e Active Directory.
Ad esempio, per mera praticità, risulta possibile usare in quel di Powershell il seguente comando: Start-ADSyncSyncCycle
Testare la funzionalità di WHfB
Con la policy configurata e assegnata a una opportuna OU è possibile testare l’implementazione di Windows Hello for Business.
- Accedere al Client dedicato al Test e assicurarsi che le ultime GPO siano caricate via canonico comando gpupdate (da lanciare tramite powershell o CMD a propria discrezione).
- Se “Do not start Windows Hello provisioning after sign-in” non risulta attivo in GPO (vedi capitolo precedente), la successiva volta che un utente accederà al computer gli verrà richiesta la configurazione di Windows Hello (procedura guidata. In alternativa basterà richiamare da Impostazioni del proprio sistema operativo Windows la voce Opzioni di Accesso. Al suo interno si troverà quanto occorre per eseguire configurazione diretta.
- Dopo aver configurato PIN ed eventuale strumento biometrico (il Wizard in fase di login presenterà come elemento predefinito l’impronta digitale) si sarà infine autorizzati all’uso di WHfB.
Nota: a seguito di configurazione via Wizard in fase di login potrebbero essere necessari fino a 30 minuti affinché WHfB funzioni. Il motivo di ciò è che lo strumento Azure AD Connect presente su DC dovrà prima sincronizzare gli attributi necessari. Si può forzare una sincronizzazione di Azure AD, così come già segnalato in punto 5 di precedente capitolo, avviando via powershell, da DC contenente il client Azure AD Connect, il seguente comando: Start-ADSyncSyncCycle
Messa in produzione di WHfB
Per la messa in produzione di WHfB basterà ad esempio eseguire aggiunta, all’OU usata in fase di test, di tutti i dispositivi in Hybrid per i quali si intenderà attivare lo strumento.
La GPO creata e testata in precedenza andrà quindi ad “atterrare” su tutti i sistemi “target” della OU.
In caso di attivazione massiva si consiglia di istruire in precedenza, magari attraverso condivisione di una procedura creata appositamente, le utenze che verranno impattate.
Risulta più semplice descrivere passo passo l’uso del Wizard di onboarding a WHfB passando da successivo logon, ma anche l’implementazione autonoma è ovviamente valida (vedi i relativi contenuti di capitolo precedente).
Ogni metodo è utilizzabile e alcuni spunti possono essere recuperati direttamente in apposita documentazione ufficiale Microsoft. Qui il link diretto.
Conclusione
Implementare Windows Hello for Business con Cloud Kerberos Trust è, rispetto ai vecchi metodi di messa in opera, semplice e rapido. Windows Hello for Business non è solo un miglioramento della sicurezza, e non è poco, ma rende anche l’accesso più comodo per tutti gli utenti finali.
Questo concetto è qualcosa che aiuterà notevolmente l’adozione dello strumento. Buona implementazione!
