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à

Desktop virtuale Azure supporta diversi tipi di identità a seconda della configurazione scelta. In questa sezione vengono illustrate le identità che è possibile usare per ogni configurazione.

Importante

Desktop virtuale Azure non supporta l'accesso a Microsoft Entra ID con un account utente, quindi l'accesso a Windows con un account utente separato. Ciò include l'uso di account Windows locali o altre identità non rappresentate in Microsoft Entra ID per accedere agli host di sessione. L'accesso con identità diverse contemporaneamente può causare la riconnessione degli utenti all'host di sessione errato, informazioni errate o mancanti nel portale di Azure, messaggi di errore durante l'uso di Collegamento app e bypassare l'autenticazione di Microsoft Entra ID e l'applicazione dell'accesso condizionale. Desktop virtuale Azure supporta scenari in cui la stessa identità Microsoft Entra ID viene usata per eseguire l'autenticazione al servizio e accedere all'host di sessione. Microsoft consiglia di usare Single Sign-on (SSO) con l'autenticazione Microsoft Entra.

Identità locale

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

Identità ibrida

Desktop virtuale Azure supporta le identità ibride tramite Microsoft Entra ID, incluse quelle federate tramite ADFS. È possibile gestire queste identità utente in Servizi di dominio Active Directory 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 a Desktop virtuale Azure 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. Desktop virtuale Azure supporta questo tipo di configurazione solo se l'UPN o il SID per gli account AD e Microsoft Entra ID corrispondono. SID si riferisce alla proprietà dell'oggetto utente "ObjectSID" in AD e "OnPremisesSecurityIdentifier" in Microsoft Entra ID.

Identità solo cloud

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

Nota

È anche possibile assegnare identità ibride ai gruppi di applicazioni Desktop virtuale Azure che ospitano host di sessione di tipo Microsoft Entra aggiunto.

Identità federativa

Se si utilizza un provider di identità (IdP) 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 dell'identità esterna consente di invitare gli utenti nel tenant Entra ID e fornire loro le risorse di Desktop virtuale Azure. Esistono diversi requisiti e limitazioni quando si forniscono risorse a identità esterne:

  • Requisiti
    • Sistema operativo host sessione: l'host sessione deve eseguire uno dei sistemi operativi seguenti:
    • Tipo di join host sessione: l'host della sessione deve essere aggiunto a Entra.
    • Single Sign-On: il Single Sign-On deve essere configurato per il pool di host.
    • Client di app di Windows: Il supporto per l'identità esterna è disponibile a livello generale nell'app app di Windows in Windows, Android o un Web browser. Il supporto per l'identità esterna è in anteprima nell'app app di Windows di macOS. Per altri dettagli, vedi la sezione Identità della documentazione dell'app di app di Windows.
  • Limitazioni

    • 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. Assegna invece i criteri di configurazione del dispositivo al dispositivo.

    • Disponibilità del cloud: questa funzionalità è disponibile nel cloud pubblico di Azure e in Azure per il governo degli Stati Uniti, ma non in Azure gestito da 21Vianet. La connessione come identità esterna a un tenant in Azure per il governo degli Stati Uniti è supportata nel client Desktop remoto, nel app di Windows in Windows e nel app di Windows in Android.

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

    • Protezione token: Microsoft Entra presenta alcune limitazioni per la protezione token per le identità esterne. Altre informazioni sul supporto delle app di app di Windows per la protezione tramite token in base alla piattaforma.

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

    • App Microsoft 365: è possibile accedere alla versione desktop per Windows delle app 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 l'accesso alle app di Microsoft 365 da un criterio di accesso condizionale dall'organizzazione di appartenenza.

      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.

    • Provider di identità: è possibile accedere come identità esterna con uno qualsiasi dei provider di identità elencati, ad eccezione dell'accesso con passcode monouso. I client delle app di app di Windows seguenti presentano limitazioni aggiuntive:

      • Android: l'unico provider di identità social supportato con cui è possibile accedere è un account Microsoft configurato come account connesso nell'app Microsoft Authenticator in esecuzione nello stesso dispositivo del client. Non è possibile accedere con Facebook o Google.

    • Federazione senza dominio: Desktop virtuale Azure supporta le identità esterne tramite la federazione IdP SAML senza dominio, tuttavia questi utenti devono riscattare l'invito (incluso il domain_hint parametro) prima di avviare l'app di app di Windows. Se l'utente si connette all'app di app di Windows ma non ha ancora riscattato l'invito per l'IdP SAML senza dominio, l'utente non sarà in grado di autenticarsi o accettare l'invito.

Per indicazioni sulle licenze vedere le procedure consigliate B2B di Microsoft Entra per suggerimenti sulla configurazione dell'ambiente per le identità esterne e 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, è tramite Microsoft Entra ID. Qui è possibile applicare i criteri di accesso condizionato di Entra ID. Inoltre, qui è possibile eseguire la federazione da Entra ID a un provider di identità di terze parti.
  • Autenticazione della sessione remota: autenticazione alla macchina virtuale remota. Esistono diversi modi per eseguire l'autenticazione nella sessione remota, tra cui il Single Sign-On (SSO) consigliato.
  • Autenticazione in sessione: autenticazione alle applicazioni e ai siti Web all'interno della sessione remota.

Di seguito è riportato un breve confronto delle opzioni di autenticazione utente in ogni fase di autenticazione:

Autenticazione del servizio cloud Autenticazione della sessione remota Autenticazione in-session
  • Autenticazione senza password (incluse chiavi di sicurezza FIDO, Windows Hello for Business con Cloud Kerberos o Key trust, autenticazione a più fattori Microsoft Authenticator e altro ancora)
  • Federazione a provider di identità di terze parti
  • Smartcard (inclusi l'autenticazione basata su certificato Entra e l'attendibilità del certificato Windows Hello for Business)
  • Password
  • Qualsiasi metodo di autenticazione del servizio cloud, se configurato con Single Sign-On
  • Smartcard (incluso l'attendibilità del certificato di Windows Hello for Business)
  • Password
  • Autenticazione senza password, se configurata per senza password nella sessione
  • Smartcard (incluso l'attendibilità del certificato di Windows Hello for Business)
  • Password

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

Importante

Per il corretto funzionamento dell'autenticazione, il computer locale deve anche essere in grado di accedere agli URL richiesti per i client Desktop remoto.

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

Autenticazione del servizio cloud

Per accedere alle risorse di Desktop virtuale Azure, è necessario prima eseguire l'autenticazione al servizio accedendo con un account Microsoft Entra ID. L'autenticazione viene eseguita ogni volta che si esegue 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 è Desktop virtuale Azure (ID app 9cdead84-a844-4324-93f2-b2e6bb768d07).

Autenticazione a più fattori

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

Autenticazione senza password

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

Autenticazione con smart card

Per utilizzare una smart card per eseguire l'autenticazione in Microsoft Entra ID, è necessario prima configurare l'autenticazione basata su certificati di Microsoft Entra 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 hai ancora abilitato l'accesso Single Sign-On o salvato le credenziali in locale, dovrai anche eseguire l'autenticazione presso l'host della sessione quando avvii una connessione.

Single Sign-On

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

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

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

Smart card e Windows Hello for Business

Desktop virtuale Azure 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 solo Kerberos per accedere. Per usare Kerberos, il client deve ottenere ticket di sicurezza Kerberos da un servizio del Centro distribuzione chiavi (KDC) in esecuzione su un controller di dominio. Per ottenere i ticket, il client deve disporre di una linea di vista di rete diretta con 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-session

Dopo la connessione alla RemoteApp o al desktop, potrebbe essere richiesta l'autenticazione all'interno della sessione. In questa sezione viene spiegato come usare credenziali diverse da nome utente e password in questo scenario.

Autenticazione senza password nella sessione

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

Per il comportamento di autenticazione senza password nella sessione e i requisiti dell'app quando ci si connette da altri client app di app di Windows, vedere la documentazione relativa al comportamento di reindirizzamento di WebAuthn in app di Windows.

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

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

Per accedere alle risorse di Microsoft Entra con Windows Hello for Business o dispositivi di sicurezza, devi 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 con smart card in sessione

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

Passaggi successivi

  • Last updated on