Microsoft Entra AVD Best Practices for Phishing Resistant Authentication
Microsoft Entra AVD is an excellent choice of VDI environment for security conscious organizations. The flexibility and broad compatibility of Azure with modern phishing-resistant authentication, combined with the familiar Windows desktop experience makes it a compelling solution. This guide will assist organizations that have already implemented AVD, or are currently evaluating it, understand the existing authentication capabilities, as well as provide guidance on how to architect their AVD deployment to support the strongest authentication methods.
Picking the right client for Phishing Resistant authentication
While there are a number of options when choosing clients, with differences in a broad range of features, this article will focus on the authentication-related features of AVD clients, and how they affect the user experience and security of AVD sessions.
In order to connect to an Microsoft Entra Virtual Desktop session, three distinct authentication stages need to take place. Service authentication, session host authentication and in-session authentication. That is - in order for a user to start actually using an application like Outlook, through AVD, they first need to authenticate to the Azure Virtual Desktop service, then from there authentication to a session host in their chosen workspace, and finally to Microsoft 365 to retrieve their email. For this reason, Single Sign-on is extremely important to usability. No matter how convenient the authentication mechanism is, asking a user to authenticate multiple times in a row is not a good user experience.
The client with the most capabilities for supporting Phishing Resistant authentication is Microsoft’s Windows Desktop Client for Remote Desktop. This client is available in traditional Microsoft Installer (MSI) packages, and provides both Microsoft Entra ID SSO, as well as device redirection for both PIV and FIDO2. Device redirection allows users to extend the phishing resistant authenticator plugged in to their local device to the Microsoft Entra Virtual Desktop - and log on to sites and services that are not federated with Microsoft Entra ID with their strong authenticators.
The AVD web client also has excellent single sign-on capabilities. As long as the authentication method is supported on the browser that’s being used to connect to the virtual desktop, that authentication method can be used with Microsoft Entra ID SSO to seamlessly log in to a session host, and access Microsoft Entra ID protected resources from that remote session. Unfortunately, for the web clients there are currently no viable device redirection options. Even with the lack of device redirection for web clients, they remain an excellent way to use Azure Virtual Desktop on any device that has a supported browser, a large screen and a keyboard and mouse.
The strong authentication options for other native clients on non-Windows platforms are mostly absent, which means that for the time being, connecting using the appropriate platform store app on an Android, ChromeOS, iOS or iPadOS device won’t allow for any strong authentication to the session host or any device redirection. MacOS is the only notable exception in this space, as it does allow for PIV device redirection, but not session authentication or even single sign-on.
Session Host compatibility
While there’s greater variety in session host selection, generally there are fewer caveats, all versions of Windows 11, Windows 10 20H2 (or later), and Windows Server 2022 all support both Microsoft Entra ID SSO, PIV and FIDO2 device redirection as long as the October 2022 CU is installed.
Ensure the Virtual Desktop Agent is up to date
The Microsoft Entra virtual desktop agent runs on the session host, and is responsible for ensuring the session host is usable and can accept remote desktop connections, as well as being responsible for self updating and installing other required components to enable AVD to work.
Ensure the session host is Microsoft Entra ID joined or Hybrid Microsoft Entra ID joined
To utilize either SSO option for AVD, the session host needs to be joined to either an Azure AD tenant or Hybrid Azure AD Domain joined. Without these options, the session host will be restricted to username and password, eliminating a lot of the potential security benefit from using Azure AVD in the first place.
Ensure the host pool is configured to allow modern authentication methods and device redirection
In order to support both SSO and device redirection, there are additional options that need to be supplied in the session configuration for AVD host pools. These configuration options are managed centrally, so there’s no need to make changes to clients to update these settings, but they need to be enabled to make sure that compatible clients will be able to utilize the SSO and device redirection capabilities in AVD.
Determine Single Sign-On Method
As mentioned in the section about clients, there are many different authentication steps that need to be completed in order for a user to make use of AVD. Single sign-on allows organizations to extend the benefits of strong, phishing resistant authentication to all of these steps, without re-prompting the user at each step. For Microsoft Entra Virtual Desktop, there are two paths for SSO to take.
Microsoft Entra ID Single Sign-On
The newer and more capable of the two is Azure AD SSO. This single sign-on accepts any authentication method that is usable by Microsoft Entra ID, and extends that not only to the AVD service and the session hosts themselves, but also within the session, making access to Microsoft 365 applications and applications joined to Microsoft Entra ID seamless. This SSO method also enables the use of Microsoft Entra ID Conditional Access authentication strength, which enables organizations to make access control decisions depending on what authentication method is used to log on. Even if an organization has to make a concession on allowing a certain client that doesn’t support phishing resistant authentication for a specific platform or use case, Conditional Access can afford the flexibility to ensure that strong authentication is used everywhere it is supported, and ensure that the use of weaker authentication methods is constrained to only where it’s technically required.
Active Directory Federation Services (AD FS) Single Sign-On
AD FS SSO for Microsoft Entra I AVD is therefore established of the two Single Sign-On methods. It relies on cooperation between AD FS and Active Directory Certificate Services (AD CS) to issue short-lived certificates upon a successful authentication to Microsoft Entra ID FS. The lack of support for FIDO2 and Microsoft Entra ID CBA, as well as additional configuration and maintenance requirements, and general lack of Conditional Access controls can make Microsoft Entra ID FS SSO a much less appealing choice for Microsoft Entra AVD, but it does have the advantage being generally available and fully supported by Microsoft.
A note on single sign-on availability.
Of the two options for single sign-on to AVD, Microsoft Entra ID SSO is the newer option, and at the time of writing still in Public Preview. It is also the only way to use Microsoft Entra ID CBA or Microsoft Entra ID FIDO2 Passwordless to authenticate to AVD session hosts in addition to supporting authentication through AD FS - or any other supported IdP federated with Microsoft Entra ID. AD FS SSO, while generally available, is limited to only authentication methods that already work with AD FS. As Microsoft and customers shift their focus away from AD FS and on-premises Active Directory deployments and towards Microsoft Entra ID, organizations that have a need for Phishing Resistant Authentication with Microsoft Entra Virtual Desktop should evaluate Microsoft Entra ID SSO - even if it is still in preview - as a way to understand the upcoming capabilities with Microsoft Entra Virtual Desktop.
Putting it all together
Microsoft Entra Virtual Desktop is a powerful virtual desktop offering for Microsoft Entra customers that can have a huge impact on knowledge worker’s ability to get work done securely on any device, anywhere. There are a number of pitfalls, and each of them generally lands the user in the same situation: having to enter a username and password to access the session host. While this is certainly not the end of the world, it is one more thing that would prevent an organization from eliminating passwords for normal users entirely. Careful selections of client, session host, and configuration settings can enable phishing resistant access to Azure Virtual Desktop infrastructure on a wide range of platforms, including BYOD scenarios.
Phishing Resistant AVD Checklist
- Clients have been chosen for their phishing resistant authentication support.
- Session hosts are using an operating system that is supported for SSO, and have applied the most recent cumulative update to ensure the best possible support for authentication and device redirection.
- Session hosts have up-to-date Microsoft Entra Virtual Desktop agents.
- Session hosts have been joined to Microsoft Entra ID or have been Hybrid Microsoft Entra ID Joined.
- Host pools have been configured to enable Microsoft Entra ID authentication and to support device redirection.
- An AVD SSO method has been configured.
- If Microsoft Entra ID SSO is used, conditional access authentication strengths have been configured to ensure that phishing resistant MFA is used whenever technically possible.