Close

Step-by-Step Guide to Securing Windows Virtual Desktop in Azure with Conditional Access and MFA

One of my biggest complaints about using Azure AD P1 to issue Azure MFA challenges on a traditional RDS deployment via RADIUS authentication is that it issues an MFA challenge on every login. That’s almost as frustrating as trying to understand Microsoft Licensing.
Fortunately, securing Windows Virtual Desktop in Azure with Conditional Access and MFA is a breeze and dramatically improves the user experience!

Requirements for Securing Windows Virtual Desktop in Azure with Conditional Access and MFA

Here are a few prerequisites that you’ll need already configured in your lab:

  • An Azure CSP Subscription from Infused Innovations (Or any Azure Subscription will work too)
  • An existing deployment of Windows Virtual Desktop in Azure
  • In addition to the Windows Virtual Desktop licensing requirements, you’ll need one of the following SKUs for conditional access and Azure MFA:
    • Azure AD P1 / P2
      • Azure AD P2 includes risk-based conditional access
    • Enterprise Mobility + Security (EM+S) E3 / E5
      • EM+S E5 includes risk-based conditional access
    • Microsoft 365 E3 / E5
      • The Identity Threat Protection add-on SKU adds risk-based conditional access to Microsoft 365 E3
      • Microsoft 365 E5 includes risk-based conditional access
    • If you don’t own the proper licensing yet, you can compare all Microsoft 365 licensing options on our blog
  • Consider reviewing our Getting Started with Conditional Access and Azure MFA guide if you’re not familiar with conditional access

Configure Windows Virtual Desktop in Azure with Conditional Access and MFA

When you integrate any application with Azure SSO as either a SAML 2.0 endpoint or Enterprise Application, it’s simple to create a conditional access policy to enforce MFA challenges for that application.

Create a new Conditional Access Policy

1.PNGWindows Virtual Desktop with MFA Conditional Access Policy Screen.
  • Under Assignments, target All Users or choose a pilot group
  • SelectCloud Apps search for Windows Virtual Desktop and select the apps that are registered in your tenant:
Windows Virtual Desktop with MFA App Selection Screen.
  • Under Conditions exclude Devices marked as compliant to allow your enrolled and healthy devices to bypass MFA challenges:
Windows Virtual Desktop with MFA Device State Configuration Screen
  • Note: You can optionally target risky sign-ins only. Or if you’re using thin clients at an office, you might want to exempt a trusted location.
  • Under Access Control select Require multi-factor authentication
Windows Virtual Desktop with MFA Grant Access Screen

Closing Thoughts on Securing Windows Virtual Desktop in Azure with Conditional Access and MFA

The new Windows Virtual Desktop service delivers exactly the multifactor authentication experience that I want to deliver to all our clients at Infused Innovations. I can allow users to bypass MFA when they’re accessing corporate resources in an approved environment; otherwise require an MFA challenge when they’re not.

It takes less than 15 minutes to secure Windows Virtual Desktop in Azure with Conditional Access compared to at least two hours to configure the Azure MFA extension with NPS to protect a traditional RDS deployment. (That time estimate is assuming you’ve deployed RDS with NPS before.) That is extraordinary value with minimal effort!

The improvements that Microsoft continues to build into their cloud offerings are delivering enterprise-class security and features at values that any SMB can afford. Checkout our WVD pricing guide for additional details on the hidden costs of Windows Virtual Desktop.

4 thoughts on “Step-by-Step Guide to Securing Windows Virtual Desktop in Azure with Conditional Access and MFA

  1. Andy

    This only triggers MFA on subscription in the WVD remote desktop client.
    It does not trigger MFA on WVD session initiation or on restarting the WVD remote desktop app.
    This means that WVD remains invalid for environments where MFA must be used on every login.
    This remains a major security shortcoming in WVD.

    1. Dan Chemistruck

      I agree that Microsoft’s decision not to anger partners like Duo by not providing MFA challenges on every sign-in is frustrating. It is possible to restrict RDP access to the VM from the LAN via Network Security Groups, and then adjust the policy in this article to require MFA on every sign in for the WVD remote client. This likely still isn’t enough for NIST environments, but I would consider it sufficient for HIPAA if you also limited access to WVD from compliant and registered devices only.

      Using the NPS extension for Azure MFA on a traditional RDGW is a non-WVD but all-Microsoft option for triggering MFA on every sign-in: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension

      I am in 100% agreement that it would be ideal if Microsoft would just add MFA to the Windows logon process.

  2. Andy

    This policy above can’t be adjusted to require MFA for every login, because clearly MFA is not integrated into the process path for WVD session logins or (less good) each WVD RD client activation after the initial subscription. If it were possible, a CA policy requiring MFA for all apps from all locations would do it, but it doesn’t, at least not in my testing.
    It should be possible for MS to integrate something like AAD application proxy here, which is one of their solutions for MFA in RDS + NPS on Azure environments.
    This, the lack of an integrated management GUI (you can deploy one from git) and the need to still do some things in Powershell outside the git deployable mgmt. GUI show like WVD is still in beta (I know it’s still in preview … and that you could argue that most of their stuff is in perpetual beta).
    I’ve seen forum posts requesting the full MFA feature and have raised a query with MS about it.
    We’ll just have to watch and wait.

    1. Dan Chemistruck

      All of my contacts at Microsoft have collectively told me not to deploy WVD in production yet because internal builds are being updated at break-neck speed on a daily basis. The GA release will likely not look like the current preview.

      One of my biggest complaints about the current version of WVD is that it still requires AD. I’ve been moving our clients over to AAD and ripping out AD since the beginning of this year, and the lack of AAD support in WVD is why I haven’t deployed it anywhere yet.

      That said, I use WVD internally every day, and I love it.

Leave a Reply

Your email address will not be published. Required fields are marked *