Supported identities and authentication methods
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 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.
Third-party identity providers
If you're using an Identity Provider (IdP) other than Microsoft Entra ID to manage your user accounts, you must ensure that:
- Your IdP is federated with Microsoft Entra ID.
- Your session hosts are Microsoft Entra joined or Microsoft Entra hybrid joined.
- You enable Microsoft Entra authentication to the session host.
External identity
Azure Virtual Desktop currently doesn't support external identities.
Authentication methods
For users connecting to a remote session, there are three separate authentication points:
Service authentication to Azure Virtual Desktop: retrieving a list of resources the user has access to when accessing the client. The experience depends on the Microsoft Entra account configuration. For example, if the user has multifactor authentication enabled, the user is prompted for their user account and a second form of authentication, in the same way as accessing other services.
Session host: when starting a remote session. A username and password is required for a session host, but this is seamless to the user if single sign-on (SSO) is enabled.
In-session authentication: connecting to other resources within a remote session.
The following sections explain each of these authentication points in more detail.
Service authentication
To access Azure Virtual Desktop resources, you must first authenticate to the service by signing in with a Microsoft Entra 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 Microsoft Entra ID.
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.
Passwordless authentication
You can use any authentication type supported by Microsoft Entra ID, 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 Microsoft Entra ID, you must first configure AD FS for user certificate authentication or configure Microsoft Entra 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. Some clients might require a specific version to be used, which you can find in the link for each authentication type.
Client | Supported authentication type(s) |
---|---|
Windows Desktop client | Username and password Smart card Windows Hello for Business certificate trust Windows Hello for Business key trust with certificates Microsoft Entra authentication |
Azure Virtual Desktop Store app | Username and password Smart card Windows Hello for Business certificate trust Windows Hello for Business key trust with certificates Microsoft Entra authentication |
Remote Desktop app | Username and password |
Web client | Username and password Microsoft Entra authentication |
Android client | Username and password Microsoft Entra authentication |
iOS client | Username and password Microsoft Entra authentication |
macOS client | 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. Microsoft Entra authentication |
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 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 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 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 passwordless authentication
Azure Virtual Desktop supports in-session passwordless authentication 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:
- Windows 11 single or multi-session with the 2022-10 Cumulative Updates for Windows 11 (KB5018418) or later installed.
- Windows 10 single or multi-session, versions 20H2 or later with the 2022-10 Cumulative Updates for Windows 10 (KB5018410) or later installed.
- Windows Server 2022 with the 2022-10 Cumulative Update for Microsoft server operating system (KB5018421) or later installed.
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 Microsoft Entra 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
- Curious about other ways to keep your deployment secure? Check out Security best practices.
- Having issues connecting to Microsoft Entra joined VMs? Look at Troubleshoot connections to Microsoft Entra joined VMs.
- Having issues with in-session passwordless authentication? See Troubleshoot WebAuthn redirection.
- Want to use smart cards from outside your corporate network? Review how to set up a KDC Proxy server.
Feedback
https://aka.ms/ContentUserFeedback.
Kommer snart: I hele 2024 udfaser vi GitHub-problemer som feedbackmekanisme for indhold og erstatter det med et nyt feedbacksystem. Du kan få flere oplysninger under:Indsend og få vist feedback om