Nicola FerriniAccedere alle risorse Active Directory on-premises da un dispositivo Microsoft Entra joined
Dopo la pubblicazione della guida dedicata a Windows Hello for Business e alle chiavi FIDO2 Utilizzare Windows Hello for Business e le chiavi FIDO2 per gestire la MFA on-premises in un ambiente Active Directory ibrido – ICT Power, un lettore mi ha posto una domanda interessante: un utente sincronizzato da Active Directory può accedere a un file server on-premises utilizzando un dispositivo completamente Microsoft Entra joined?
La risposta è sì. Il dispositivo non deve necessariamente essere aggiunto al dominio Active Directory o configurato come Microsoft Entra hybrid joined.
Il laboratorio utilizzato per questa guida è composto da un dominio Active Directory on-premises, sincronizzato con Microsoft Entra ID tramite Microsoft Entra Connect Sync.
Il domain controller ospita anche il servizio DNS del dominio, mentre il file server è un normale server membro sul quale è stata pubblicata una condivisione SMB. Gli utenti vengono creati in Active Directory e successivamente sincronizzati in Microsoft Entra ID.
Il computer Windows 11 utilizzato per la prova è invece esclusivamente Microsoft Entra joined. Non è aggiunto al dominio Active Directory e non possiede quindi un computer account in AD DS.
Figura 1: Schema dell’architettura utilizzata nel laboratorio
L’utente accede a Windows utilizzando la password dell’account sincronizzato. Quando prova ad aprire la condivisione, il client contatta il domain controller per ottenere i ticket Kerberos necessari e li presenta al file server durante la connessione SMB.
Perché questo meccanismo funzioni, il dispositivo deve poter risolvere i nomi DNS del dominio e raggiungere sia il domain controller sia il file server. Il client può trovarsi direttamente sulla rete aziendale oppure collegarsi tramite una VPN che garantisca la corretta risoluzione DNS e la connettività verso l’infrastruttura on-premises.
Nella prima parte utilizzeremo la password dell’utente sincronizzato. Successivamente ripeteremo la prova con Windows Hello for Business e una chiave di sicurezza FIDO2, analizzando le configurazioni necessarie per mantenere il Single Sign-On passwordless.
Come funziona il Single Sign-On verso Active Directory
Un dispositivo Microsoft Entra joined non conosce direttamente il dominio Active Directory on-premises, perché non ne è membro. Le informazioni necessarie vengono fornite al client da Microsoft Entra ID.
Durante l’accesso dell’utente, Microsoft Entra ID restituisce al dispositivo anche le informazioni relative al dominio Active Directory dal quale proviene l’identità sincronizzata. Windows può così individuare il dominio e utilizzare Kerberos o NTLM quando l’utente prova a raggiungere una risorsa on-premises.
Il meccanismo si basa sugli attributi sincronizzati per l’utente. Durante la sincronizzazione, Microsoft Entra Connect replica in Microsoft Entra ID alcuni attributi identificativi del dominio Active Directory, tra cui il SAM Account Name, il Domain Name e lo UPN. Sono proprio questi attributi a permettere, in un secondo momento, al dispositivo di individuare il dominio corretto.
Quando il dispositivo riceve dal Primary Refresh Token le informazioni sul dominio on-premises dell’utente, Windows avvia il processo DCLocator, che si occupa di individuare un domain controller effettivamente raggiungibile per quel dominio. Questa ricerca avviene tramite interrogazioni DNS sui record SRV pubblicati dai domain controller (storicamente, in reti più datate, anche tramite broadcast NetBIOS). Una volta individuato il domain controller, il servizio LSA abilita sul dispositivo l’autenticazione Kerberos e NTLM, dando così il via alla normale richiesta del TGT descritta in precedenza.
Nel nostro caso, quando l’utente apre il percorso \\FS01.demo.lab\Dati il client contatta un domain controller e richiede un Ticket-Granting Ticket, comunemente chiamato TGT. Successivamente ottiene un ticket Kerberos per il servizio CIFS pubblicato dal file server cifs/FS01.demo.lab
Il ticket viene presentato al file server, che identifica l’utente e verifica le autorizzazioni configurate sulla condivisione e sul file system NTFS. Se la configurazione è corretta, la cartella viene aperta senza chiedere nuovamente la password.
È importante ricordare che il Single Sign-On riguarda l’identità dell’utente. Il computer continua a non essere membro del dominio e non utilizza un account computer di Active Directory.
Verifica dell’utente sincronizzato
L’utente utilizzato per la prova è stato creato in Active Directory e successivamente sincronizzato in Microsoft Entra ID tramite Microsoft Entra Connect Sync.
Per verificarlo, collegatevi al Microsoft Entra admin center, selezionate Entra ID > Users > All users e cercate l’account che verrà utilizzato per accedere al dispositivo.
Come si può vedere nella figura, il valore On-premises sync enabled è impostato su Yes. Questo conferma che l’account non è stato creato direttamente nel cloud, ma proviene dall’Active Directory on-premises.
Figura 2: Verifica dell’utente Active Directory sincronizzato in Microsoft Entra ID
Windows utilizzerà le informazioni associate a questa identità per individuare il dominio Active Directory e richiedere i ticket Kerberos necessari per accedere alle risorse on-premises.
Verifica dello stato del dispositivo
Il computer Windows 11 utilizzato per la prova è stato aggiunto esclusivamente a Microsoft Entra ID. Per verificarlo ho eseguito il comando:
|
1 2 |
dsregcmd /status |
Nella sezione Device State il valore AzureAdJoined : YES conferma che il dispositivo è Microsoft Entra joined, mentre DomainJoined : NO indica che non appartiene al dominio Active Directory.
Nella sezione SSO State possiamo inoltre vedere che il valore AzureAdPrt è impostato su YES. Il dispositivo dispone quindi di un Primary Refresh Token valido per l’utente connesso.
Figura 3: Verifica dello stato Microsoft Entra joined del dispositivo e dei ticket disponibili per l’utente
Nel mio laboratorio sono già configurati Windows Hello for Business e Cloud Kerberos trust. Il valore NgcSet : YES, visibile nella sezione User State, conferma infatti che l’utente ha registrato una credenziale Windows Hello.
Questa configurazione permette all’utente di accedere alla condivisione anche dopo aver effettuato il login con PIN o biometria. Se invece l’utente accede a Windows utilizzando la propria password, l’accesso alle risorse Active Directory può funzionare anche senza Microsoft Entra Kerberos, perché il client può contattare direttamente un domain controller e ottenere i ticket Kerberos necessari.
Nel nostro scenario la condivisione sarà quindi accessibile sia utilizzando la password sia utilizzando Windows Hello for Business. A cambiare è il modo con cui viene ottenuto il ticket Kerberos, non il fatto che il dispositivo sia esclusivamente Microsoft Entra joined.
Accesso al dispositivo con la password
Per eseguire la prova ho disconnesso l’utente e, nella schermata di accesso di Windows, ho selezionato Sign-in options e quindi l’icona della password.
Questo passaggio è importante perché sul dispositivo è configurato anche Windows Hello for Business e, per impostazione predefinita, Windows potrebbe proporre il PIN o il riconoscimento biometrico.
Figura 4: Selezione della password come metodo di accesso a Windows
Ho quindi effettuato l’accesso utilizzando la password dell’account sincronizzato da Active Directory. Una volta visualizzato il desktop, non ho inserito altre credenziali e non ho configurato account aggiuntivi in Gestione credenziali.
Accesso alla condivisione on-premises
Da Esplora file ho digitato il percorso UNC della condivisione ospitata sul file server \\FS01.demo.lab\Dati
La cartella è stata aperta immediatamente, senza mostrare una nuova richiesta di autenticazione.
Figura 5: Accesso alla condivisione SMB senza reinserire le credenziali
Il dispositivo non è membro del dominio Active Directory, ma Windows ha utilizzato l’identità on-premises associata all’utente sincronizzato per effettuare il Single Sign-On verso la condivisione.
Verifica dei ticket Kerberos
Dopo aver aperto la condivisione ho eseguito il comando:
|
1 2 |
klist |
Il comando mostra i ticket Kerberos presenti nella cache dell’utente. Nella figura possiamo vedere il Ticket-Granting Ticket relativo al dominio DEMO.LAB: krbtgt/DEMO.LAB
È inoltre presente il ticket richiesto per accedere al servizio CIFS del file server: cifs/FS01.demo.lab
Figura 6: Verifica dei ticket Kerberos ottenuti dall’utente per accedere alla condivisione SMB
La presenza del ticket cifs/FS01.demo.lab conferma che Windows ha utilizzato Kerberos per autenticare l’utente verso il file server. Nel campo Kdc Called è inoltre indicato il domain controller che ha gestito la richiesta: DC01.demo.lab
Il file server riceve quindi un ticket associato all’account [email protected] e può applicare normalmente le autorizzazioni configurate sulla condivisione e sul file system NTFS.
Accesso con Windows Hello for Business e chiavi FIDO2
Dopo aver verificato l’accesso con la password, possiamo ripetere la stessa prova utilizzando una credenziale passwordless, come Windows Hello for Business o una chiave di sicurezza FIDO2.
In questo caso è necessario configurare Microsoft Entra Kerberos nel dominio Active Directory. La procedura prevede la creazione dell’oggetto AzureADKerberos, utilizzato da Microsoft Entra ID per generare i Ticket-Granting Ticket destinati al dominio on-premises.
Ho già descritto questa configurazione nella guida Utilizzare Windows Hello for Business e le chiavi FIDO2 per gestire la MFA on-premises in un ambiente Active Directory ibrido, alla quale vi rimando per tutti i passaggi necessari.
Cosa succede senza il Cloud Kerberos trust
Se Microsoft Entra Kerberos non è stato configurato nel dominio, oppure Windows Hello for Business non è stato configurato per utilizzare il Cloud Kerberos trust, l’utente può comunque accedere al dispositivo con PIN o biometria.
Il problema si presenta quando prova ad aprire una risorsa protetta da Active Directory. In assenza di un altro modello di trust, la credenziale Windows Hello non può essere utilizzata per completare il Single Sign-On e Windows mostra una richiesta di credenziali.
Come si può vedere nella figura, nel mio test Windows ha mostrato il messaggio The system cannot contact a domain controller to service the authentication request. Il messaggio visualizzato può cambiare in base alla configurazione e alla connettività del client: l’elemento importante è che l’accesso alla condivisione non viene completato automaticamente.
L’inserimento del PIN non risolve il problema. Il PIN protegge la chiave privata di Windows Hello for Business presente sul dispositivo e non è una password che può essere inviata al domain controller.
Figura 7: Richiesta di credenziali durante l’accesso alla condivisione senza Cloud Kerberos trust
Selezionando More choices, l’utente può inserire manualmente il nome e la password dell’account Active Directory. In questo modo può accedere alla condivisione, ma viene meno l’esperienza passwordless e non viene effettuato il Single Sign-On.
Per consentire a Windows Hello for Business di effettuare il Single Sign-On verso le risorse Active Directory sono necessarie due configurazioni: Microsoft Entra Kerberos deve essere presente nel dominio on-premises e il dispositivo deve utilizzare il modello Cloud Kerberos trust.
La prima configurazione è stata descritta nella guida precedente. Vediamo quindi come abilitare sul client la policy Use Cloud Trust For On Prem Auth, necessaria per permettere a Windows Hello for Business di ottenere i ticket Kerberos senza richiedere la password dell’utente.
La modalità consigliata consiste nel distribuire la configurazione tramite Microsoft Intune. Dal Microsoft Intune admin center create una nuova policy per Windows utilizzando il Settings catalog e cercate la categoria Windows Hello for Business. Le impostazioni da configurare sono:
- Use Windows Hello For Business True
- Use Cloud Trust For On Prem Auth Enabled
- Require Security Device True
L’impostazione Require Security Device non è indispensabile per il funzionamento del Cloud Kerberos trust, ma è consigliata perché richiede che le chiavi di Windows Hello for Business siano protette dal TPM.
Figura 8: Configurazione del Cloud Kerberos trust tramite Microsoft Intune
Se Windows Hello for Business è già stato abilitato mediante un’altra policy, è sufficiente configurare Use Cloud Trust For On Prem Auth. Verificate inoltre che non sia abilitata l’impostazione Use certificate for on-premises authentication, perché il certificate trust ha la precedenza sul Cloud Kerberos trust.
Se non disponete di Microsoft Intune, potete configurare singolarmente ogni dispositivo Microsoft Entra joined utilizzando l’Editor Criteri di gruppo locali. Avviate gpedit.msc e raggiungete il percorso Computer Configuration> Administrative Templates > Windows Components > Windows Hello for Business
Abilitate quindi il criterio Use cloud Kerberos trust for on-premises authentication.
Figura 9: Abilitazione del Cloud Kerberos trust tramite l’Editor Criteri di gruppo locali
La policy è una configurazione del computer e deve quindi essere applicata a ogni dispositivo dal quale si vuole utilizzare Windows Hello for Business per accedere alle risorse Active Directory.
Per le chiavi di sicurezza FIDO2 non è invece necessario abilitare la policy Cloud Kerberos trust di Windows Hello for Business. È comunque necessario aver configurato Microsoft Entra Kerberos e aver abilitato l’accesso a Windows tramite security key, come mostrato nella guida precedente.
Dopo aver applicato la configurazione, disconnettete l’utente ed effettuate nuovamente l’accesso utilizzando il PIN, la biometria o la chiave FIDO2.
Aprite quindi la stessa condivisione \\FS01.demo.lab\Dati. Anche in questo caso la cartella viene aperta senza richiedere la password dell’utente.
Microsoft Entra ID fornisce al dispositivo un TGT parziale per il dominio Active Directory. Il client lo presenta a un domain controller, che restituisce il TGT completo e permette di richiedere il ticket per il servizio cifs/FS01.demo.lab.
L’esperienza per l’utente rimane quindi la stessa, ma l’accesso alle risorse on-premises avviene senza utilizzare o trasmettere la password.
Limiti dello scenario
La possibilità di accedere alle risorse Active Directory non trasforma il dispositivo Microsoft Entra joined in un computer membro del dominio.
Il dispositivo non possiede un computer account in Active Directory, non riceve le Group Policy di dominio e non può utilizzare le applicazioni che richiedono esplicitamente l’autenticazione del computer.
Il Single Sign-On descritto in questa guida riguarda esclusivamente l’identità dell’utente. Può essere utilizzato con condivisioni SMB e applicazioni configurate per l’autenticazione integrata di Windows, purché il client possa raggiungere un domain controller e la risorsa on-premises.
Conclusioni
Un utente creato in Active Directory e sincronizzato in Microsoft Entra ID può accedere alle risorse on-premises anche da un dispositivo esclusivamente Microsoft Entra joined.
Se l’utente accede a Windows utilizzando la propria password, il client può contattare un domain controller e ottenere i ticket Kerberos necessari. Non è quindi obbligatorio aggiungere il dispositivo al dominio o configurarlo come Microsoft Entra hybrid joined.
Se l’utente accede con Windows Hello for Business o con una chiave di sicurezza FIDO2, Microsoft Entra Kerberos permette invece di mantenere un’esperienza completamente passwordless. Per Windows Hello for Business è necessario configurare anche il dispositivo affinché utilizzi il modello Cloud Kerberos trust.
In entrambi i casi il dispositivo rimane esclusivamente Microsoft Entra joined: a cambiare è il modo con cui viene ottenuto il ticket Kerberos necessario per accedere alle risorse Active Directory.