L’identità è la prima decisione

In un progetto Azure Virtual Desktop la domanda “a quale directory si uniscono i session host?” viene prima di tutte le altre: condiziona chi riesce ad autenticarsi, dove possono stare i profili FSLogix, quale storage è utilizzabile e quali metodi di autenticazione sono disponibili. Un errore qui non si corregge con una configurazione: si ricostruisce l’host pool.

Tieni distinte due identità: l’utente che si connette e il computer account del session host. Il servizio autentica l’utente in cloud, Windows sull’host secondo la directory a cui appartiene.

Le tre strade

AD DS. Il session host si unisce a un dominio Active Directory tradizionale, esteso in Azure con domain controller in una virtual network oppure raggiunto via VPN o ExpressRoute. È la scelta obbligata quando servono Group Policy complete, estensioni di schema, trust esistenti o applicazioni legacy. Gli utenti devono essere identità ibride, sincronizzate fra AD DS e Microsoft Entra ID. Il costo è operativo: i domain controller restano a carico tuo.

Microsoft Entra Domain Services. Un dominio gestito da Microsoft, popolato dagli oggetti di Entra ID. Elimina la manutenzione dei domain controller e conserva LDAP, Kerberos, NTLM e un sottoinsieme di Group Policy. In cambio si cede controllo: la sincronizzazione va solo dal tenant verso il dominio gestito e lo schema non è estendibile.

Microsoft Entra ID. Il session host si unisce direttamente a Entra ID, senza alcun dominio. È lo scenario più snello, l’unico compatibile con utenti cloud-only, e quello che si integra con la gestione via Intune. Il prezzo è l’accesso alle risorse on-premises, da progettare a parte anziché ereditarlo dal dominio.

Dove si complica: lo storage dei profili

In un host pool pooled il profilo non può restare sul disco locale: serve una share SMB per i FSLogix profile container, e la share deve autenticare con la stessa logica dei session host. Su Azure Files l’autenticazione basata su identità può essere AD DS, Microsoft Entra Domain Services o Microsoft Entra Kerberos, quest’ultima l’opzione degli host Entra ID joined. Azure NetApp Files richiede invece una connessione a un dominio AD DS, che da solo esclude alcune combinazioni.

I permessi restano poi su due livelli: il ruolo RBAC sulla file share e le ACL NTFS dentro la share. Impostarne uno solo produce un accesso negato che sembra un problema di rete e non lo è.

Accessi: RBAC, accesso condizionale e SSO

Azure RBAC governa il piano di controllo. Ruoli come Desktop Virtualization Contributor o Desktop Virtualization Host Pool Contributor servono a chi amministra host pool, application group e workspace; il ruolo Desktop Virtualization User, assegnato sull’application group, permette all’utente di vedere e avviare la risorsa pubblicata. Sono piani diversi: amministrare non dà il diritto di connettersi, e connettersi non concede privilegi sulle risorse Azure né diritti locali sull’host.

Le policy di accesso condizionale si applicano alle connessioni verso Azure Virtual Desktop e impongono MFA, valutano condizioni di rischio, richiedono un dispositivo compliant o Entra hybrid joined, limitano le reti di provenienza e regolano la sign-in frequency. Attenzione: una sign-in frequency troppo aggressiva produce prompt ripetuti, perché autenticazione al servizio e alla sessione sono momenti distinti. Oltre alla password ci sono opzioni passwordless come Windows Hello for Business e le chiavi FIDO2, più le smart card basate su certificati, con prerequisiti diversi per ogni scenario di identità.

Il single sign-on Microsoft Entra elimina la seconda richiesta di credenziali all’apertura della sessione, autenticando l’utente al session host a partire dal token già ottenuto. Va abilitato sull’host pool e, con AD DS, presuppone la configurazione Kerberos lato dominio.

Trappole tipiche d’esame

  • Utenti cloud-only e nessun dominio on-premises → session host Entra ID joined: con AD DS o Entra Domain Services l’utente deve esistere anche nel dominio, e un’identità solo cloud non si autentica su un host domain-joined.
  • FSLogix su Azure Files con host Entra ID joined → Microsoft Entra Kerberos: “AD DS authentication” è il distrattore ricorrente, ma senza domain controller raggiungibile non è praticabile.
  • Ruolo RBAC assegnato sulla share eppure accesso al profilo negato → mancano le ACL NTFS: i due livelli di permessi sono cumulativi, uno solo non basta.
  • “Dare accesso al desktop agli utenti” → Desktop Virtualization User sull’application group: gli utenti si assegnano al gruppo di applicazioni, non all’host pool; un ruolo amministrativo non abilita la connessione.
  • Serve un dominio ma nessuno vuole gestire domain controller → Entra Domain Services: se però lo scenario cita estensioni di schema o trust, la risposta torna AD DS.
  • Doppia richiesta di credenziali all’apertura del desktop → SSO Microsoft Entra: non è una questione di password policy: senza SSO le autenticazioni sono legittimamente due.