Edit

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 Azure AD 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 MSIX app attach.

On-premises identity

Since users must be discoverable through Azure Active Directory (Azure AD) 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 Azure AD, including those federated using AD FS. You can manage these user identities in AD DS and sync them to Azure AD using Azure AD Connect. You can also use Azure AD to manage these identities and sync them to Azure AD Domain Services (Azure AD DS).

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 Azure AD don't match. For example, the AD account user@contoso.local may correspond to user@contoso.com in Azure AD. Azure Virtual Desktop only supports this type of configuration if either the UPN or SID for both your AD and Azure AD accounts match. SID refers to the user object property "ObjectSID" in AD and "OnPremisesSecurityIdentifier" in Azure AD.

Cloud-only identity

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

Note

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

Third-party identity providers

If you're using an Identity Provider (IdP) other than Azure AD to manage your user accounts, you must ensure that:

External identity

Azure Virtual Desktop currently doesn't support external identities.

Service authentication

To access Azure Virtual Desktop resources, you must first authenticate to the service by signing in with an Azure AD account. Authentication happens whenever you subscribe to a workspace to retrieve your resources and connect to apps or desktops. You can use third-party identity providers as long as they federate with Azure AD.

Multi-factor authentication

Follow the instructions in Enforce Azure Active Directory Multi-Factor Authentication for Azure Virtual Desktop using Conditional Access to learn how to enforce Azure AD Multi-Factor 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 Azure AD-joined VMs, note the extra steps for Azure AD-joined session host VMs.

Passwordless authentication

You can use any authentication type supported by Azure AD, such as Windows Hello for Business and other passwordless authentication options (for example, FIDO keys), to authenticate to the service.

Smart card authentication

To use a smart card to authenticate to Azure AD, you must first configure AD FS for user certificate authentication or configure Azure AD certificate-based authentication.

Session host 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. The following list describes which types of authentication each Azure Virtual Desktop client currently supports.

  • The Windows Desktop client and Azure Virtual Desktop Store app both support the following authentication methods:
  • The Remote Desktop app supports the following authentication method:
    • Username and password
  • The web client supports the following authentication method:
    • Username and password
  • The Android client supports the following authentication method:
    • Username and password
  • The iOS client supports the following authentication method:
    • Username and password
  • The macOS client supports the following authentication method:
    • Username and password
    • Smart card: support for smart card-based sign in using smart card redirection at the Winlogon prompt when NLA is not negotiated.

Important

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

Single sign-on (SSO)

SSO allows the connection to skip the session host credential prompt and automatically sign the user in to Windows. For session hosts that are Azure AD-joined or Hybrid Azure AD-joined, it's recommended to enable SSO using Azure AD authentication. Azure AD 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 will prompt 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 remote app 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 passwordless authentication (preview)

Important

In-session passwordless authentication is currently in public preview. This preview version is provided without a service level agreement, and is not recommended for production workloads. Certain features might not be supported or might have constrained capabilities. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

Azure Virtual Desktop supports in-session passwordless authentication (preview) using Windows Hello for Business or security devices like FIDO keys when using the Windows Desktop client. Passwordless authentication is enabled automatically when the session host and local PC are using the following operating systems:

To disable passwordless authentication on your host pool, you must customize an RDP property. You can find the WebAuthn redirection property under the Device redirection tab in the Azure portal or set the redirectwebauthn property to 0 using PowerShell.

When enabled, all WebAuthn requests in the session are redirected to the local PC. You can use Windows Hello for Business or locally attached security devices to complete the authentication process.

To access Azure AD resources with Windows Hello for Business or security devices, you must enable the FIDO2 Security Key as an authentication method for your users. To enable this method, follow the steps in Enable FIDO2 security key method.

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 client comparison chart to make sure your client supports smart card redirection.

Next steps