• Cloud, Guide
• 29 Maggio 2026

Negli ultimi anni, il concetto di virtualizzazione del desktop ha subito una trasformazione profonda, passando da modelli fortemente ancorati all’infrastruttura on-premises a soluzioni completamente orientate al cloud. In questo percorso evolutivo, Azure Virtual Desktop (AVD) si è affermato come uno dei principali abilitatori del digital workplace moderno, offrendo flessibilità, scalabilità e integrazione nativa con l’ecosistema Microsoft.

Nato come evoluzione dei servizi Remote Desktop Services (RDS) e successivamente introdotto come Windows Virtual Desktop, AVD rappresenta oggi una piattaforma matura per la distribuzione di desktop e applicazioni in modalità servizio. Tuttavia, nelle sue prime implementazioni, l’adozione di AVD richiedeva ancora una forte dipendenza da componenti tradizionali, come Active Directory Domain Services (AD DS), spesso estesi nel cloud tramite macchine virtuali o connessi in modalità ibrida attraverso VPN o ExpressRoute.

Oggi, questo scenario sta cambiando rapidamente. Microsoft sta guidando un’evoluzione significativa della piattaforma introducendo nuove funzionalità che permettono di ridurre (fino a eliminare) la dipendenza da Active Directory tradizionale, abilitando architetture completamente basate su Microsoft Entra ID.

In questo contesto, due elementi emergono come pilastri fondamentali della trasformazione:

• Il supporto al cloud join ( o Entra ID join) per le session host AVD
• L’integrazione avanzata di FSLogix con Azure Filese Entra Only Identities (Azure Files Entra-Only identities: Advancing cloud-native identity and security | Microsoft Azure Blog)

L’obiettivo di questo articolo è analizzare in dettaglio questa nuova direzione, approfondendo come il paradigma cloud-only, combinato con l’utilizzo di FSLogix su Azure Files, stia ridefinendo le architetture di riferimento per Azure Virtual Desktop.

Architettura Azure Virtual Desktop

Per comprendere appieno il valore introdotto dalle nuove funzionalità di Azure Virtual Desktop, è fondamentale partire da un’analisi dell’architettura tradizionale e delle sue evoluzioni.

Figura 1: Schema architetturale classico di un ambiente Azure Virtual Desktop con esternalizzazione del profilo tramite FSLOGIX

Quella che vedete è una tipica installazione Azure Virtual Desktop; analizziamola meglio:

• In alto abbiamo il nostro Domain Controller in Sync tramite Entra Connect Sync (ex Azure AD Connect) con il nostro Entra ID
• Il Session Host è legato al dominio tramite una Hybrid Join (e di conseguenza a Entra ID)
• Il Session Host gestisce l’esternalizzazione del profilo tramite FSLOGIX e andiamo ad utilizzare un Azure Files come repository SMB per il profilo.
• Il nostro utente quindi:

1. Si collegherà al servizio di Azure Virtual Desktop,
2. Si autentica tramite Entra ID
3. La sessione viene stabilita sul Session Host
4. L’accesso alle risorse (es. file share FSLogix) passa tramite Kerberos gestito da AD DS.

In linea di massima questo è il funzionamento… Ora andiamo un po’ più a fondo.

Quando un utente accede a un ambiente Azure Virtual Desktop in configurazione ibrida, l’esperienza di login è conseguita tramite Single Sign-On (se ovviamente ben configurato): l’utente si autentica una sola volta e accede direttamente al proprio desktop e alle risorse aziendali, sul suo profilo FSLogix.

Dietro le quinte, però, questo processo coinvolge due sistemi di identità diversi che collaborano tra loro:

• Microsoft Entra ID, che gestisce l’accesso al servizio AVD
• Active Directory (AD DS), che gestisce l’autenticazione Windows e l’accesso alle risorse

Primo step: accesso tramite Microsoft Entra ID

Il processo inizia quando l’utente apre il client AVD e si autentica tramite Entra ID (password, MFA, Windows Hello, ecc.). In questa fase:

• Entra ID verifica l’identità dell’utente
• autorizza l’accesso al servizio Azure Virtual Desktop

A questo punto l’utente è “dentro” il servizio AVD, ma non ancora autenticato sul sistema operativo Windows.

Secondo step: Connessione al session host e login

Una volta che l’utente si è autenticato il servizio AVD assegna all’utente una session host ( che ricordo essere Hybrid Join per implementare il meccanismo di SSOn).

Quando la sessione viene stabilita il sistema effettua automaticamente il login sulla VM; questo succede perchè vengono utilizzate una combinazione di fattori (utenza ibrida + device trusted) che di fatto autorizzano il SSOn sulla risorsa. Data la complessità tecnologica sottostante del tema non tratteremo in questo articolo il processo di SSOn.

Terzo step: Ottenimento token Kerberos

Una volta autenticato su Active Directory la macchina ottiene un Kerberos Ticket (TGT): questo ticket rappresenta l’identità dell’utente nel dominio.
A questo punto FSLogix tenta di montare il profilo utente su una share SMB, utilizza il ticket Kerberos per autenticarsi e, se tutto è fatto come si deve, l’utente accede al suo desktop remoto con il profilo correttamente caricato.

Perché nasce Microsoft Entra Kerberos?

Figura 2: Schema architetturale Azure Virtual Desktop “Cloud Only”. In questa configurazione è stato completamente eliminata la dipendenza da Active Directory

Se ora vi mostrassi questa immagine molti di voi potrebbero dire “Hey! manca qualcosa!” e non vi nego che le prime volte faticavo a comprendere come questo effettivamente potesse funzionare. In realtà il tutto è più facile e chiaro di quanto non sembri (anche se il nostro Domain Controller ci mancherà tanto).

Di fatto ci è ben chiaro una cosa: FSLogix -> SMB -> Kerberos -> Domain Controller

L’idea alla base è tanto semplice quanto incisiva: mantenere il modello di autenticazione Kerberos, eliminando però la dipendenza dal Domain Controller.

Il nuovo ruolo di Entra ID

Nel modello moderno, Microsoft Entra ID non si limita più a gestire l’autenticazione verso applicazioni cloud, ma assume un ruolo più ampio: diventa infatti l’autorità in grado di emettere ticket Kerberos utilizzabili per l’accesso a risorse SMB, come Azure Files.

Questo non significa introdurre un nuovo protocollo o modificare quello esistente. Kerberos continua a funzionare esattamente come prima, ma cambia completamente l’origine dei ticket.

Nel modello tradizionale, ogni ticket viene generato dal Domain Controller; nel nuovo modello, lo stesso processo avviene nel cloud, direttamente tramite Entra ID

Nota architetturale: il ruolo del realm nel cambiamento verso Entra Kerberos

Per comprendere appieno la portata dell’introduzione di Microsoft Entra Kerberos, è utile soffermarsi su un elemento spesso trascurato ma fondamentale nel funzionamento del protocollo: il realm Kerberos.

Nel modello tradizionale, il realm rappresenta il dominio di autenticazione ed è strettamente associato ad Active Directory. In pratica, ogni ticket Kerberos è emesso all’interno di uno specifico realm e può essere considerato valido solo se il servizio che lo riceve riconosce quell’autorità come trusted.

Questo implica che:

• il Domain Controller è l’unica autorità valida per quel realm
• tutti i client e servizi devono appartenere o fidarsi di quel dominio
• il Kerberos realm coincide, nella pratica, con il perimetro di Active Directory

È proprio questa associazione diretta tra realm Kerberos e dominio AD che ha reso storicamente impossibile separare protocolli come SMB dall’infrastruttura domain-based.

Con l’introduzione di Microsoft Entra Kerberos, questo legame viene spezzato.

Il cambiamento non consiste semplicemente nel fatto che Entra ID emette ticket Kerberos, ma nel fatto che introduce un nuovo tipo di realm, gestito nel cloud. (Microsoft Entra Kerberos)

In questo modello:

• il realm non è più implicitamente legato a un dominio Active Directory
• l’autorità che emette i ticket è Microsoft Entra ID
• i servizi (come Azure Files) sono configurati per fidarsi di questo nuovo realm

Su quest’ ultimo punto va però aperta una piccola discriminante: dipende da come lo si configura!

Figura 3: Configurazione Join Azure Files con Active Directory Domain Services

In questo caso andiamo di fatto a fare quello che in molti (me compreso) definiscono il Join ad Active Directory dell’Azure Files (Come si fa?). Nello specifico andiamo a dire che il realm accettato per questo Azure Files è quello gestito dal nostro Active Directory

Figura 4: Configurazione Join Azure FIles con Microsoft Entra Kerberos

In quest’ altro caso invece andiamo a configurare il fatto che il realm di appartenenza di questo Azure Files sia proprio Entra ID e sarà lui che ci fornirà il ticket kerberos per autenticarci.

Analisi del ticket Kerberos

Un modo estremamente efficace per comprendere il cambiamento introdotto da Microsoft Entra Kerberos è analizzare direttamente i ticket Kerberos presenti sul sistema utilizzando il comando klist.

Osservando l’output, emergono alcuni elementi chiave.

In primo luogo, il Ticket Granting Ticket mostra come realm di emissione:

KERBEROS.MICROSOFTONLINE.COM

Figura 5: Dimostrazione Realm Microsoft Entra Kerberos via klist

Questo dettaglio è fondamentale, perché indica chiaramente che il ticket non è stato emesso da un Domain Controller Active Directory, ma da un’autorità Kerberos gestita nel cloud. In un ambiente tradizionale, infatti, il realm corrisponderebbe al dominio AD (ad esempio contoso.local).

Un secondo elemento significativo è il service ticket utilizzato per accedere a Azure Files, che presenta anch’esso lo stesso realm cloud. Questo dimostra che la risorsa SMB accetta ticket emessi da Entra ID, senza necessità di integrazione con Active Directory.

Infine, il campo relativo al KDC evidenzia che la richiesta è stata gestita tramite un endpoint Microsoft (login.microsoftonline.com), confermando che l’intero flusso Kerberos è stato soddisfatto nel cloud e non da un Domain Controller.

Nasce ora il dubbio: ok, ho passato l’autenticazione in cloud, ma come posso gestire le ACL?

Autorizzazione e ACL: come cambia il modello con Azure Files

Se Microsoft Entra Kerberos rappresenta il cambiamento nel modo in cui vengono emessi i ticket, il tema delle autorizzazioni rappresenta l’altro lato della medaglia: una volta autenticato l’utente, come viene autorizzato l’accesso ai dati?

Nel modello tradizionale, autenticazione e autorizzazione sono entrambe gestite all’interno di Active Directory. Nel modello cloud-native, invece, questi due aspetti vengono parzialmente disaccoppiati, introducendo una combinazione tra controlli Azure e meccanismi NTFS.

Autorizzazione a livello Azure (RBAC)

Prima ancora di valutare le ACL NTFS, Azure Files verifica se l’utente ha accesso allo share tramite Azure RBAC.

Questo livello controlla:

• chi può accedere alla share
• con quale livello (Reader, Contributor, ecc.)

Esempio

• Storage File Data SMB Share Reader
• Storage File Data SMB Share Contributor

Figura 6: Configurazione Default Share Permission Azure Files

Nota: In questo caso io ho fornito a tutti gli utenti autenticati il ruolo di Storage File Data SMB Share Contributor. Consiglio invece di Disabilitare le default permission e di garantire un accesso granulare sfruttando le Access Control (IAM) su gruppi personalizzati.

Autorizzazione a livello NTFS (ACL)

Una volta superato il controllo a livello Azure RBAC, entra in gioco il modello classico di autorizzazione Windows. A questo punto sono le ACL NTFS a determinare in modo preciso cosa l’utente può effettivamente fare all’interno dello share, governando accesso a file e cartelle, eredità e granularità dei permessi.

Figura 7: Gestione ACL dentro Azure Files

Figura 8: Gestione ACL dentro Azure Files – Edit Permission

È proprio in questa fase che Kerberos torna ad avere un ruolo centrale. Il ticket presentato dal client non serve solamente a dimostrare l’identità dell’utente, ma trasporta anche le informazioni necessarie per la valutazione delle ACL, in particolare l’insieme dei SID associati all’utente stesso. Azure Files utilizza questo contesto per eseguire i controlli di autorizzazione in modo del tutto analogo a quanto avverrebbe in un ambiente Active Directory tradizionale.

Gestione e governance dei session host: il ruolo di Microsoft Intune

Nel modello cloud-native basato su Microsoft Entra ID, la configurazione dei session host non può più essere affidata a Group Policy tradizionali. La gestione passa completamente attraverso Microsoft Intune, che diventa il punto centrale per definire il comportamento del sistema operativo e abilitare le funzionalità necessarie al corretto funzionamento dell’architettura.

Dato che l’autorizzazione all’ accesso al Session Host sarà gestito tramite il Cloud-native SSO Protocol (RDS AAD Auth puro), l’ unica configurazione che dovremo gestire sarà unicamente quella per abilitare FSLOGIX; di seguito la mia configurazione nel mio ambiente (ovviamente vi invito a modificarla come più congeniale alle vostre esigenze)

Figura 9: Configurazione FSLOGIX Policy Intune – PT 1

Figura 10: Configurazione FSLOGIX Policy Intune – PT 2

Figura 11: Configurazione FSLOGIX Policy Intune – PT 3

La configurazione delle policy FSLogix in ambiente cloud-native non differisce in modo sostanziale da quella tradizionale, ma viene distribuita tramite Intune invece che tramite Group Policy. Questo include la definizione dei parametri principali per il profile container, come il percorso dello share Azure Files e le impostazioni di comportamento del profilo.

Nel momento in cui l’utente effettua il login:

• FSLogix intercetta il processo di logon
• identifica il percorso del profile container configurato
• tenta la connessione allo share Azure Files
• utilizza il ticket Kerberos ottenuto da Entra ID per autenticarsi
• monta il VHD/VHDX associato all’utente

Se il flusso è stato configurato correttamente, l’intero processo avviene in modo trasparente e senza alcuna dipendenza da Active Directory.

Conclusioni

Il vero valore di questo approccio non risiede nella singola feature, ma nella convergenza di tutti questi elementi in un modello coerente.

Nel paradigma tradizionale:

• Active Directory rappresenta il centro di autenticazione, autorizzazione e gestione

Nel paradigma moderno:

• Entra ID gestisce l’identità e l’autenticazione
• Azure gestisce l’accesso alle risorse
• NTFS continua a garantire il controllo sui dati
• Intune governa il comportamento dei dispositivi

E vi dirò di più! Con questo meccanismo possiamo portare inoltre la gestione di utenze Guest su AVD su un ulteriore livello in quanto anche queste sono supportate all’ utilizzo di FSLOGIX! ma questo probabilmente lo leggerete in un mio altro articolo 🙂

Enea