Identità e metodi di autenticazione supportati

  • Articolo

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

Identità

Desktop virtuale Azure supporta diversi tipi di identità a seconda della configurazione scelta. Questa sezione illustra 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 accedere a Windows con un account utente separato. L'accesso con due account diversi contemporaneamente può causare la riconnessione degli utenti all'host sessione errato, informazioni non corrette o mancanti nella portale di Azure e messaggi di errore visualizzati durante l'uso del collegamento dell'app MSIX.

Identità locale

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

Identità ibrida

Desktop virtuale Azure supporta le identità ibride tramite Microsoft Entra ID, incluse quelle federate con AD FS. È possibile gestire queste identità utente in Servizi di dominio Active Directory e sincronizzarle con Microsoft Entra ID usando Microsoft Entra Connessione. È 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, talvolta il nome dell'entità utente (UPN) o l'IDENTIFICATORe di sicurezza (SID) per l'utente in Active Directory (AD) e l'ID Microsoft Entra 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 fa riferimento 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 join aggiunti a Microsoft Entra.

Provider di identità di terze parti

Se si usa un provider di identità (IdP) diverso da Microsoft Entra ID per gestire gli account utente, è necessario assicurarsi che:

  • Il provider di identità è federato con Microsoft Entra ID.
  • Gli host di sessione sono aggiunti a Microsoft Entra o aggiunti a Microsoft Entra ibrido.
  • Si abilita l'autenticazione di Microsoft Entra nell'host di sessione.

Identità esterna

Desktop virtuale Azure attualmente non supporta le identità esterne.

Autenticazione servizio

Per accedere alle risorse di Desktop virtuale Azure, è prima necessario eseguire l'autenticazione al servizio eseguendo l'accesso con un account Microsoft Entra. L'autenticazione avviene ogni volta che si sottoscrive un'area di lavoro per recuperare le risorse e connettersi alle app o ai desktop. È possibile usare provider di identità di terze parti purché si federazioneno con Microsoft Entra ID.

Autenticazione a più fattori

Seguire le istruzioni in Applicare l'autenticazione a più fattori Di Microsoft Entra per Desktop virtuale Azure usando l'accesso condizionale per informazioni su come applicare l'autenticazione a più fattori Di Microsoft Entra per la distribuzione. Questo articolo illustra 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 di sessione aggiunte a Microsoft Entra.

Autenticazione senza password

È 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, chiavi FIDO), per eseguire l'autenticazione al servizio.

Autenticazione con smart card

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

Autenticazione host sessione

Se non è già stato abilitato l'accesso Single Sign-On o le credenziali salvate in locale, sarà necessario eseguire l'autenticazione anche all'host della sessione quando si avvia una connessione. L'elenco seguente descrive i tipi di autenticazione attualmente supportati da ogni client desktop virtuale Azure. Alcuni client potrebbero richiedere l'uso di una versione specifica, disponibile nel collegamento per ogni tipo di autenticazione.

Client Tipi di autenticazione supportati
Client desktop di Windows Nome utente e password
Smart card
Attendibilità del certificato di Windows Hello for Business
Attendibilità della chiave di Windows Hello for Business con certificati
Autenticazione Microsoft Entra
App Azure Virtual Desktop Store Nome utente e password
Smart card
Attendibilità del certificato di Windows Hello for Business
Attendibilità della chiave di Windows Hello for Business con certificati
Autenticazione Microsoft Entra
App Desktop remoto Nome utente e password
Client Web Nome utente e password
Autenticazione Microsoft Entra
Client Android Nome utente e password
Autenticazione Microsoft Entra
Client iOS Nome utente e password
Autenticazione Microsoft Entra
Client macOS Nome utente e password
Smart card: supporto per l'accesso basato su smart card usando il reindirizzamento di smart card al prompt winlogon quando NLA non viene negoziata.
Autenticazione Microsoft Entra

Importante

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

Single sign-on (SSO)

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

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

Senza SSO, il client richiederà agli utenti le credenziali dell'host di sessione per ogni connessione. L'unico modo per evitare di essere richiesto consiste nel salvare le credenziali nel client. È consigliabile salvare solo le credenziali nei 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 host sessione, ma Smart card e Windows Hello for Business possono usare Kerberos solo per accedere. Per usare Kerberos, il client deve ottenere ticket di sicurezza Kerberos da un servizio KDC (Key Distribution Center) in esecuzione in un controller di dominio. Per ottenere i ticket, il client necessita 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 desktop, potrebbe essere richiesta l'autenticazione all'interno della sessione. Questa sezione illustra 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 il client Desktop di 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à di reindirizzamento WebAuthn nella scheda Reindirizzamento del dispositivo nella 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. È possibile usare Windows Hello for Business o i 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, è 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 smart card nella sessione

Per usare una smart card nella sessione, assicurarsi di aver installato i driver di smart card nell'host sessione e di abilitare il reindirizzamento delle smart card. Esaminare il grafico di confronto client per assicurarsi che il client supporti il reindirizzamento delle smart card.

Passaggi successivi