Condividi tramite

Identità e metodi di autenticazione supportati

In questo articolo verrà fornita una breve panoramica dei tipi di identità e metodi di autenticazione che è possibile usare in desktop virtuale Azure.

Identità

Azure Desktop virtuale supporta diversi tipi di identità a seconda della configurazione scelta. Questa sezione illustra le identità che è possibile usare per ogni configurazione.

Importante

Azure Desktop virtuale non supporta l'accesso a Microsoft Entra ID con un account utente, quindi l'accesso a Windows con un account utente separato. L'accesso con due account diversi contemporaneamente può comportare la riconnessione degli utenti all'host di sessione errato, informazioni errate o mancanti nel portale di Azure e la visualizzazione di messaggi di errore durante l'uso di Collegamento app.

Identità locale

Poiché gli utenti devono essere individuabili tramite Microsoft Entra ID per accedere al desktop virtuale Azure, le identità utente esistenti solo in Active Directory Domain Services (AD DS) non sono supportate. Sono incluse distribuzioni autonome di Active Directory con Active Directory Federation Services (AD FS).

Identità ibrida

Azure Desktop virtuale supporta le identità ibride tramite Microsoft Entra ID, incluse quelle federate con AD FS. È possibile gestire queste identità utente in Active Directory Domain Services e sincronizzarle con Microsoft Entra ID usando Microsoft Entra Connect. È anche possibile usare Microsoft Entra ID per gestire queste identità e sincronizzarle con Microsoft Entra Domain Services.

Quando si accede Azure Desktop virtuale usando identità ibride, a volte il nome dell'entità utente (UPN) o l'identificatore di sicurezza (SID) per l'utente in Active Directory (AD) e Microsoft Entra ID non corrispondono. Ad esempio, l'account user@contoso.local AD può corrispondere a user@contoso.com in Microsoft Entra ID. Azure Desktop virtuale supporta questo tipo di configurazione solo se l'UPN o il SID per gli account AD e Microsoft Entra ID corrispondono. SID fa riferimento alla proprietà dell'oggetto utente "ObjectSID" in AD e "OnPremisesSecurityIdentifier" in Microsoft Entra ID.

Identità solo cloud

Azure Desktop virtuale supporta le identità solo cloud quando si usano Microsoft Entra macchine virtuali unite. Questi utenti vengono creati e gestiti direttamente in Microsoft Entra ID.

Nota

È anche possibile assegnare identità ibride a Azure gruppi di applicazioni desktop virtuale che ospitano host di sessione di tipo join Microsoft Entra aggiunti.

Identità federativa

Se si usa un provider di identità di terze parti, diverso da Microsoft Entra ID o Active Directory Domain Services, per gestire gli account utente, è necessario assicurarsi che:

Identità esterna

Il supporto delle identità esterne consente di invitare gli utenti al tenant di Entra ID e di fornirli Azure risorse di Desktop virtuale. Esistono diversi requisiti e limitazioni quando si forniscono risorse alle identità esterne:

  • Requisiti
    • Sistema operativo host sessione: l'host sessione deve eseguire Windows 11 Enterprise, versioni 24H2 o successive con il Aggiornamenti cumulativo 2025-09 per Windows 11 (KB5065789) o versioni successive installate.
    • Tipo di join host sessione: l'host di sessione deve essere aggiunto a Entra.
    • Single Sign-On: l'accesso Single Sign-On deve essere configurato per il pool di host.
    • Windows App client: l'identità esterna deve connettersi dal Windows App in Windows o in un Web browser.
  • Limitazioni

    • FSLogix: il supporto di FSLogix è in anteprima per le identità esterne. Altre informazioni su come archiviare i contenitori del profilo FSLogix in File di Azure usando Microsoft Entra ID.

    • Intune criteri di configurazione del dispositivo: i criteri di configurazione del dispositivo assegnati all'identità esterna non verranno applicati all'utente nell'host della sessione. Assegnare invece i criteri di configurazione del dispositivo al dispositivo.

    • Disponibilità cloud: questa funzionalità è disponibile solo nel cloud pubblico Azure, ma non nel cloud per enti pubblici o Azure gestito da 21Vianet.

    • Inviti tra cloud: gli utenti tra cloud non sono supportati. È possibile fornire l'accesso alle risorse di Desktop virtuale Azure solo agli utenti invitati da provider di identità di social networking, Microsoft Entra utenti del cloud commerciale microsoft Azure o di altri provider di identità registrati nel tenant della forza lavoro. Non è possibile assegnare Azure risorse di Desktop virtuale per gli utenti invitati da Microsoft Azure per enti pubblici o Microsoft Azure gestito da 21Vianet.

    • Protezione dei token: Microsoft Entra presenta alcune limitazioni per la protezione dei token per le identità esterne. Altre informazioni sul supporto Windows App per la protezione dei token per piattaforma.

    • Autenticazione Kerberos: le identità esterne non possono eseguire l'autenticazione alle risorse locali usando protocolli Kerberos o NTLM.

    • App di Microsoft 365: è possibile accedere alla versione desktop di Windows delle app di Microsoft 365 solo se:

      1. L'utente invitato è un account basato su Entra o un account Microsoft concesso in licenza per Microsoft 365 Apps.
      2. All'utente invitato non viene impedito di accedere alle app di Microsoft 365 da un criterio di accesso condizionale dall'organizzazione principale.

      Indipendentemente dall'account invitato, è possibile accedere ai file di Microsoft 365 condivisi con l'utente usando l'app Microsoft 365 appropriata nel Web browser dell'host della sessione.

Vedere Microsoft Entra procedure consigliate B2B per consigli sulla configurazione dell'ambiente per le identità esterne e Licenze per le linee guida sulle licenze.

Metodi di autenticazione

Quando si accede alle risorse di Desktop virtuale Azure, esistono tre fasi di autenticazione separate:

  • Autenticazione del servizio cloud: l'autenticazione al servizio Desktop virtuale Azure, che include la sottoscrizione alle risorse e l'autenticazione al gateway, è con Microsoft Entra ID.
  • Autenticazione sessione remota: autenticazione alla macchina virtuale remota. Esistono diversi modi per eseguire l'autenticazione alla sessione remota, tra cui l'accesso Single Sign-On (SSO) consigliato.
  • Autenticazione in sessione: autenticazione ad applicazioni e siti Web all'interno della sessione remota.

Per l'elenco delle credenziali disponibili nei diversi client per ogni fase di autenticazione, confrontare i client tra piattaforme.

Importante

Affinché l'autenticazione funzioni correttamente, il computer locale deve anche essere in grado di accedere agli URL necessari per i client Desktop remoto.

Le sezioni seguenti forniscono altre informazioni su queste fasi di autenticazione.

Autenticazione del servizio cloud

Per accedere Azure risorse di Desktop virtuale, è innanzitutto necessario eseguire l'autenticazione al servizio accedendo con un account Microsoft Entra ID. L'autenticazione viene eseguita ogni volta che si effettua la sottoscrizione per recuperare le risorse, connettersi al gateway quando si avvia una connessione o quando si inviano informazioni di diagnostica al servizio. La risorsa Microsoft Entra ID usata per questa autenticazione è Azure Desktop virtuale (ID app 9cdead84-a844-4324-93f2-b2e6bb768d07).

Autenticazione a più fattori

Seguire le istruzioni in Imponi autenticazione a più fattori Microsoft Entra per Azure Desktop virtuale usando l'accesso condizionale per informazioni su come applicare l'autenticazione a più fattori Microsoft Entra per la distribuzione. Questo articolo spiega anche come configurare la frequenza con cui agli utenti viene richiesto di immettere le credenziali. Quando si distribuiscono Microsoft Entra macchine virtuali aggiunte, prendere nota dei passaggi aggiuntivi per Microsoft Entra macchine virtuali host sessione aggiunti.

Autenticazione senza password

Per eseguire l'autenticazione al servizio, è possibile usare qualsiasi tipo di autenticazione supportato da Microsoft Entra ID, ad esempio Windows Hello for Business e altre opzioni di autenticazione senza password, ad esempio le chiavi FIDO.

Autenticazione con smart card

Per usare una smart card per l'autenticazione in Microsoft Entra ID, è necessario innanzitutto configurare Microsoft Entra autenticazione basata su certificato o configurare AD FS per l'autenticazione del certificato utente.

Provider di identità di terze parti

È possibile usare provider di identità di terze parti purché siano federati con Microsoft Entra ID.

Autenticazione della sessione remota

Se non è già stato abilitato l'accesso Single Sign-On o non sono state salvate le credenziali in locale, sarà anche necessario eseguire l'autenticazione nell'host della sessione quando si avvia una connessione.

Single Sign-On

L'accesso SSO consente alla connessione di ignorare la richiesta di credenziali dell'host di sessione e di accedere automaticamente all'utente a Windows tramite l'autenticazione Microsoft Entra. Per gli host di sessione Microsoft Entra aggiunti o Microsoft Entra aggiunti ibridi, è consigliabile abilitare l'accesso SSO usando l'autenticazione Microsoft Entra. Microsoft Entra l'autenticazione offre altri vantaggi, tra cui l'autenticazione senza password e il supporto per i provider di identità di terze parti.

Azure Desktop virtuale supporta anche l'accesso SSO tramite Active Directory Federation Services (AD FS) per i client Desktop e Web Windows.

Senza SSO, il client richiede agli utenti le credenziali dell'host sessione per ogni connessione. L'unico modo per evitare di essere richiesto è salvare le credenziali nel client. È consigliabile salvare le credenziali solo nei dispositivi sicuri per impedire ad altri utenti di accedere alle risorse.

Smart card e Windows Hello for Business

Azure Desktop virtuale supporta sia NT LAN Manager (NTLM) che Kerberos per l'autenticazione dell'host di sessione, tuttavia smart card e Windows Hello for Business possono usare Kerberos solo per accedere. Per usare Kerberos, il client deve ottenere i ticket di sicurezza Kerberos da un servizio KDC (Key Distribution Center) in esecuzione in un controller di dominio. Per ottenere i ticket, il client ha bisogno di una linea di rete diretta per il controller di dominio. È possibile ottenere una linea di vista connettendosi direttamente all'interno della rete aziendale, usando una connessione VPN o configurando un server proxy KDC.

Autenticazione in sessione

Dopo aver eseguito la connessione a RemoteApp o al desktop, è possibile che venga richiesta l'autenticazione all'interno della sessione. In questa sezione viene illustrato come usare credenziali diverse da nome utente e password in questo scenario.

Autenticazione senza password in sessione

Azure Desktop virtuale supporta l'autenticazione senza password in sessione usando Windows Hello for Business o dispositivi di sicurezza come le chiavi FIDO quando si usa il client Desktop Windows. L'autenticazione senza password viene abilitata automaticamente quando l'host sessione e il PC locale usano i sistemi operativi seguenti:

Per disabilitare l'autenticazione senza password nel pool di host, è necessario personalizzare una proprietà RDP. È possibile trovare la proprietà reindirizzamento WebAuthn nella scheda Reindirizzamento del dispositivo nel portale di Azure o impostare la proprietà redirectwebauthn su 0 tramite PowerShell.

Se abilitata, tutte le richieste WebAuthn nella sessione vengono reindirizzate al PC locale. È possibile usare Windows Hello for Business o dispositivi di sicurezza collegati in locale per completare il processo di autenticazione.

Per accedere Microsoft Entra risorse con Windows Hello for Business o dispositivi di sicurezza, è necessario abilitare la chiave di sicurezza FIDO2 come metodo di autenticazione per gli utenti. Per abilitare questo metodo, seguire la procedura descritta in Abilitare il metodo della chiave di sicurezza FIDO2.

Autenticazione della smart card in sessione

Per usare una smart card nella sessione, assicurarsi di aver installato i driver delle smart card nell'host della sessione e aver abilitato il reindirizzamento delle smart card. Esaminare i grafici di confronto per Windows App e l'app Desktop remoto per consentire l'uso del reindirizzamento delle smart card.

Passaggi successivi

  • Last updated on