Azure Virtual Desktop senza Active Directory:
come funziona e quando conviene

In breve: con Microsoft Entra Kerberos, Azure Virtual Desktop (AVD) e i profili FSLogix su Azure Files possono funzionare senza domain controller: è sempre Kerberos, ma a emettere i biglietti è il cloud anziché Active Directory. Per scenari nuovi o «solo cloud» è una vera semplificazione; per chi ha applicativi di dominio (gestionali, SQL Server) non significa «via i domain controller», ma una modernizzazione ibrida. Vediamo come funziona davvero e — soprattutto — quando ha senso.

Dal desktop ancorato ad Active Directory al cloud

Azure Virtual Desktop nasce come evoluzione dei Remote Desktop Services: prima «Windows Virtual Desktop», oggi una piattaforma matura per erogare desktop e applicazioni come servizio. Nelle prime implementazioni, però, serviva ancora Active Directory Domain Services (AD DS): domain controller su macchine virtuali, oppure il dominio on-premise esteso al cloud via VPN o ExpressRoute.

Microsoft sta riducendo questa dipendenza: con i session host aggiunti a Microsoft Entra ID e con Entra Kerberos, si può arrivare a non avere più bisogno del domain controller. Una precisazione utile: il session host tipico di AVD è Windows 11 Enterprise multi-session — un OS client che accetta più utenti contemporanei, l’erede moderno del ruolo RDSH su Windows Server (che resta comunque supportato).

Il modello tradizionale: due identità che collaborano

Nel modello classico (ibrido) lavorano insieme due sistemi di identità: Microsoft Entra ID gestisce l’accesso al servizio AVD, mentre Active Directory gestisce l’autenticazione di Windows e l’accesso al profilo. Dietro un’esperienza di single sign-on, succede questo:

• 1L’utente apre il client AVD e si autentica su Entra ID (password, MFA, Windows Hello).
• 2Il servizio assegna un session host e stabilisce la sessione sulla macchina.
• 3Per accedere alle risorse Windows, la macchina ottiene un ticket Kerberos dal domain controller.
• 4FSLogix usa quel ticket per montare il profilo utente su una share SMB. Tutto ruota intorno al domain controller: FSLogix → SMB → Kerberos → domain controller.

Entra Kerberos: lo stesso Kerberos, senza domain controller

L’idea è tanto semplice quanto incisiva: mantenere Kerberos, togliere la dipendenza dal domain controller. Microsoft Entra ID diventa l’autorità capace di emettere i ticket Kerberos per accedere a risorse SMB come Azure Files. Il protocollo non cambia: cambia chi emette i biglietti.

Nel modello tradizionale ogni ticket nasce dal domain controller, in un realm legato al dominio Active Directory (es. azienda.local). Con Entra Kerberos nasce un realm nel cloud — KERBEROS.MICROSOFTONLINE.COM — e il KDC è raggiungibile via internet. Lo si vede con klist: il ticket non arriva da un domain controller, ma da un’autorità Kerberos gestita nel cloud. I session host Entra-joined non hanno più bisogno di linea di vista verso un DC, e il modello funziona sia con identità ibride (sincronizzate da AD) sia cloud-only.

Autenticazione non è autorizzazione: RBAC e ACL NTFS

Una volta autenticato l’utente, come viene autorizzato l’accesso ai dati? Azure Files usa due livelli che lavorano in sequenza:

• Livello share — Azure RBAC. Prima di tutto si verifica chi può accedere alla share e con quale livello (ad esempio Storage File Data SMB Share Reader o Contributor). Conviene disattivare i permessi di default e assegnare accessi granulari a gruppi dedicati.
• Livello file e cartella — ACL NTFS. Superato il controllo RBAC, valgono le classiche autorizzazioni Windows. Qui il ticket Kerberos torna centrale: oltre a provare l’identità, trasporta i SID dell’utente, così Azure Files valuta le ACL esattamente come farebbe un ambiente Active Directory. Per le identità cloud-only la configurazione consigliata è il pannello Manage access.

Gestione cloud-native: Intune al posto delle GPO

Senza dominio non ci sono Group Policy: i session host Entra-joined si governano con Microsoft Intune. È da lì che si abilita il recupero del ticket Kerberos cloud (l’impostazione CloudKerberosTicketRetrievalEnabled, via Settings Catalog) e si distribuiscono le policy di FSLogix che prima passavano dalle GPO.

Un punto che abbassa molto la barriera d’ingresso: FSLogix è lo stesso agent che si usa già su Windows Server o RDSH. Cambiano soltanto lo storage (da file server a Azure Files) e la sorgente dei ticket (da domain controller a Entra Kerberos), e lo strumento di deploy (da GPO a Intune). I concetti di profile container, redirezioni ed esclusioni restano identici: chi gestisce già FSLogix non riparte da zero.

Serve davvero alla tua azienda? Quando conviene (e quando è solo moda)

Qui sta il punto che spesso manca: «senza domain controller» non è un upgrade universale. Il modello cloud-only (zero DC) conviene davvero solo in scenari precisi, accomunati dall’assenza di applicativi di dominio:

• Greenfield — aziende o filiali nuove, nate in cloud, senza eredità on-premise.
• Lavoratori SaaS-only / frontline — chi vive di Microsoft 365, desktop AVD e una share, senza gestionali legacy.
• Identità esterne / B2B — il cloud-only è l’unico modello che le supporta con FSLogix.
• Ambienti isolati — un progetto, una DMZ o un perimetro che vuoi separato dal tuo Active Directory, in ottica zero trust.

Se invece in azienda ci sono applicativi membri di dominio — un gestionale, SQL Server in autenticazione Windows, un file server di dominio — quei sistemi tengono in vita i domain controller. Per loro la mossa giusta non è inseguire il «senza DC», ma una modernizzazione ibrida: session host Entra-joined, Entra Kerberos e FSLogix su Azure Files per il layer desktop, e attorno a un core Active Directory snellito:

• RD Gateway → ZTNA. Al posto di un gateway RDP esposto su internet, un accesso Zero Trust Network Access che pubblica la singola risorsa per-utente, verificando identità e dispositivo, senza esporre nulla.
• NPS per l’MFA → Conditional Access. L’MFA passa a Entra ID, che valuta identità, dispositivo e rischio, anziché un MFA «cieco» via RADIUS.
• GPO → Intune. Migrazione progressiva delle policy verso Intune, lasciando in AD solo ciò che serve davvero ai server di dominio.

Restano poi alcune insidie da conoscere prima di partire: ogni storage account accetta un solo identity source (non si mescolano AD DS ed Entra Kerberos); con identità ibride, le ACL della share vanno impostate da una macchina che vede il domain controller (i session host no), e utenti e gruppi vanno sincronizzati a Entra ID; per le identità cloud-only servono l’abilitazione dei gruppi cloud (limite di 1.010 SID per ticket) e la disabilitazione dell’MFA sull’app dello storage account, con disponibilità ancora limitata ad alcune region. Infine, l’hardening Kerberos di aprile 2026 (da RC4 ad AES) può rompere i profili FSLogix su SMB non aggiornati: vale la pena allinearsi prima, come spieghiamo nell’articolo sull’ addio alla cifratura RC4 in Kerberos.

Come AtWorkStudio aiuta

Partiamo sempre da un audit delle dipendenze da Active Directory prima di promettere semplificazioni: cosa aggancia davvero il dominio (gestionali, SQL Server, GPO, gateway, MFA) e cosa si può spostare. Da lì progettiamo il percorso giusto — desktop AVD, identità ibrida, gestione dell’identità digitale con Entra ID, Intune, Conditional Access e accesso zero trust — coerente con i requisiti di NIS2 e le best practice ISO/IEC 27001. Niente esercizi di stile: solo ciò che porta valore.

Operiamo da Piacenza dal 2000. Siamo certificati ISO/IEC 27001, 27017, 27018 e ISO 9001, qualificati ACN per servizi cloud, membri di Clusit (Associazione Italiana per la Sicurezza Informatica) e associati a Confindustria Piacenza nel cluster RICT.