Supported identities and authentication methods

  • Article

In this article, we'll give you a brief overview of what kinds of identities and authentication methods you can use in Azure Virtual Desktop.

Identities

Azure Virtual Desktop supports different types of identities depending on which configuration you choose. This section explains which identities you can use for each configuration.

Important

Azure Virtual Desktop doesn't support signing in to Microsoft Entra ID with one user account, then signing in to Windows with a separate user account. Signing in with two different accounts at the same time can lead to users reconnecting to the wrong session host, incorrect or missing information in the Azure portal, and error messages appearing while using app attach or MSIX app attach.

On-premises identity

Since users must be discoverable through Microsoft Entra ID to access the Azure Virtual Desktop, user identities that exist only in Active Directory Domain Services (AD DS) aren't supported. This includes standalone Active Directory deployments with Active Directory Federation Services (AD FS).

Hybrid identity

Azure Virtual Desktop supports hybrid identities through Microsoft Entra ID, including those federated using AD FS. You can manage these user identities in AD DS and sync them to Microsoft Entra ID using Microsoft Entra Connect. You can also use Microsoft Entra ID to manage these identities and sync them to Microsoft Entra Domain Services.

When accessing Azure Virtual Desktop using hybrid identities, sometimes the User Principal Name (UPN) or Security Identifier (SID) for the user in Active Directory (AD) and Microsoft Entra ID don't match. For example, the AD account user@contoso.local may correspond to user@contoso.com in Microsoft Entra ID. Azure Virtual Desktop only supports this type of configuration if either the UPN or SID for both your AD and Microsoft Entra ID accounts match. SID refers to the user object property "ObjectSID" in AD and "OnPremisesSecurityIdentifier" in Microsoft Entra ID.

Cloud-only identity

Azure Virtual Desktop supports cloud-only identities when using Microsoft Entra joined VMs. These users are created and managed directly in Microsoft Entra ID.

Note

You can also assign hybrid identities to Azure Virtual Desktop Application groups that host Session hosts of join type Microsoft Entra joined.

Federated identity

If you're using a third-party Identity Provider (IdP), other than Microsoft Entra ID or Active Directory Domain Services, to manage your user accounts, you must ensure that:

External identity

Azure Virtual Desktop currently doesn't support external identities.

Authentication methods

When accessing Azure Virtual Desktop resources, there are three separate authentication phases:

  • Cloud service authentication: Authenticating to the Azure Virtual Desktop service, which includes subscribing to resources and authenticating to the Gateway, is with Microsoft Entra ID.
  • Remote session authentication: Authenticating to the remote VM. There are multiple ways to authenticate to the remote session, including the recommended single sign-on (SSO).
  • In-session authentication: Authenticating to applications and web sites within the remote session.

For the list of credential available on the different clients for each of the authentication phase, compare the clients across platforms.

Important

In order for authentication to work properly, your local machine must also be able to access the required URLs for Remote Desktop clients.

The following sections provide more information on these authentication phases.

Cloud service authentication

To access Azure Virtual Desktop resources, you must first authenticate to the service by signing in with a Microsoft Entra ID account. Authentication happens whenever you subscribe to retrieve your resources, connect to the gateway when launching a connection or when sending diagnostic information to the service. The Microsoft Entra ID resource used for this authentication is Azure Virtual Desktop (app ID 9cdead84-a844-4324-93f2-b2e6bb768d07).

Multifactor authentication

Follow the instructions in Enforce Microsoft Entra multifactor authentication for Azure Virtual Desktop using Conditional Access to learn how to enforce Microsoft Entra multifactor authentication for your deployment. That article will also tell you how to configure how often your users are prompted to enter their credentials. When deploying Microsoft Entra joined VMs, note the extra steps for Microsoft Entra joined session host VMs.

Smart card authentication

To use a smart card to authenticate to Microsoft Entra ID, you must first configure AD FS for user certificate authentication.

Third-party identity providers

You can use third-party identity providers as long as they federate with Microsoft Entra ID.

Remote session authentication

If you haven't already enabled single sign-on or saved your credentials locally, you'll also need to authenticate to the session host when launching a connection.

Single sign-on (SSO)

SSO allows the connection to skip the session host credential prompt and automatically sign the user in to Windows through Microsoft Entra authentication. For session hosts that are Microsoft Entra joined or Microsoft Entra hybrid joined, it's recommended to enable SSO using Microsoft Entra authentication. Microsoft Entra authentication provides other benefits including passwordless authentication and support for third-party identity providers.

Azure Virtual Desktop also supports SSO using Active Directory Federation Services (AD FS) for the Windows Desktop and web clients.

Without SSO, the client prompts users for their session host credentials for every connection. The only way to avoid being prompted is to save the credentials in the client. We recommend you only save credentials on secure devices to prevent other users from accessing your resources.

Smart card and Windows Hello for Business

Azure Virtual Desktop supports both NT LAN Manager (NTLM) and Kerberos for session host authentication, however Smart card and Windows Hello for Business can only use Kerberos to sign in. To use Kerberos, the client needs to get Kerberos security tickets from a Key Distribution Center (KDC) service running on a domain controller. To get tickets, the client needs a direct networking line-of-sight to the domain controller. You can get a line-of-sight by connecting directly within your corporate network, using a VPN connection or setting up a KDC Proxy server.

In-session authentication

Once you're connected to your RemoteApp or desktop, you may be prompted for authentication inside the session. This section explains how to use credentials other than username and password in this scenario.

In-session smart card authentication

To use a smart card in your session, make sure you've installed the smart card drivers on the session host and enabled smart card redirection. Review the comparison charts for Windows App and the Remote Desktop app to make you can use smart card redirection.

Next steps