Azure Virtual Desktop identities and authentication – Azure

Table of Contents0.1 In this article1 Identities1.1 On-premises identity1.2 Hybrid identity1.3 Cloud-only identity1.4 External identity2 Service authentication2.1 Multi-factor authentication2.2 Smart card authentication3 Session host authentication3.1 Single sign-on (SSO)4 In-session authentication4.1 Smart cards4.2 FIDO2 and Windows Hello for Business5 Next steps Article 06/13/2022 4 minutes to […]

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.


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.

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) are not 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 Directory 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 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.

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 to an Azure AD account. Authentication happens when subscribing to a workspace to retrieve your resources or every time you 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.

Smart card authentication

To use a smart card to authenticate to Azure AD, you must first configure AD FS for user certificate 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. These are the sign-in methods for the session host that the Azure Virtual Desktop clients currently support:

  • Windows Desktop client
  • Windows Store client
  • Web client
  • Android
  • iOS
  • macOS

Azure Virtual Desktop supports both NT LAN Manager (NTLM) and Kerberos for session host authentication. 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.

Single sign-on (SSO)

Azure Virtual Desktop supports SSO using Active Directory Federation Services (ADFS) for the Windows and web clients. SSO allows you to skip the session host authentication.

Otherwise, the only way to avoid being prompted for your credentials for the session host is to save them in the client. We recommend you only do this with secure devices to prevent other users from accessing your resources.

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.

Smart cards

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

FIDO2 and Windows Hello for Business

Azure Virtual Desktop doesn’t currently support in-session authentication with FIDO2 or Windows Hello for Business.

Next steps

Source Article

Next Post

Cost Management automation overview - Microsoft Cost Management

Mon Aug 1 , 2022
Table of Contents0.1 In this article1 Available APIs1.1 Cost Details APIs1.2 Pricing APIs1.3 Budgets and Alerts APIs1.4 Invoicing APIs1.5 Reservation APIs2 Common API scenarios2.1 Invoice reconciliation2.2 Cross-charging2.3 Azure spending prior to invoice closure2.4 Cost trend reporting2.5 Reservation related investigations3 Next steps Article 07/17/2022 6 minutes […]
Exit mobile version