MFA for WVD, doesn’t that already exist through Azure AD conditional access? Yes, it does, but its limited to certain scenario’s. With the Azure AD MFA WVD access, you only need to MFA once in order to access any desktop published through WVD. Which got me thinking: what if I want to request an MFA every time I launch a desktop? What if I want an MFA on the Remote Desktop application when opening a desktop in order to avoid users switching username when they left their application open?
You see, there are many reasons why you would or would not want to request additional verification from a user when actually accessing data or applications. Now, I’ve dealt with Duo Security a few years ago when I integrated it with Microsoft TMG, but I noticed they now also (probably for some time now) have a local and RDP login verification method as well. This means that as soon as I want to open an RDP connection, I’m challenged for MFA. Given WVD is based on RDP, I thought lets give this a try.
Note that this post is in no way supported by Microsoft (AFAIK) and I haven’t heard anything yet from Duo Security, so I guess that’s a no-no as well.
We need to use Duo as we want to be able to use the RDP agent they have released to secure the connection itself. This means we need to spin-up a Duo instance (trial available). After getting your trial we need to onboard users. We can either manually add users, synchronize with AD or synchronize with Azure AD. I chose the last one as it doesn’t require any agents.
Make sure to make the connection (login with a Global AAD Admin when asked) and allow the service to read your attributes and such. Also, on the same page, make sure to select a Group in which all your users are to be synchronized, else your import will result in 0 users. And given your users will use their on-premises samAccountName we will also need to import that attribute as well, which we can configure in the import. This way Duo will be able to match the Netbios name of users to their Duo profile as well. For some reason I had to also include the domain name into the username, making the alias attribute look like DOMAIN\netbiosname
Alternatively, we can also import their configured phones (and send SMS invites to allow the users to download the Duo App configure the application).
Which brings us to the connection of the application (RDP configuration) itself. It’s an agent you can download from the Applications tab. Select it and choose Microsoft RDP. Follow the documentation for installing and configuring the Integration Key, Secret key and API hostname. This will allow the VM’s RDP agent to connect to the Duo cloud and register itself on your tenant.
Finally, what we need to do is disable normalization to ensure our usernames as sent/used as is:
Login Experience
First of all make sure that the user is onboarded with Duo and they have their application configured, else the user will get an error:
(Note that this error also occurs if the user doesn’t have the alias domain\username configured in the Duo Aliases list).
Now, starting the Remote Desktop application doesn’t require you to provide MFA / authentication every time you start it.
Now if the user would normally open the Desktop, the system would ask for username and password, but not an MFA. In our case, if the user is configured correctly, the Duo MFA prompt will show:
Followed by a prompt on the phone, which if validated will grant access to the desktop.
What to use this for?
Well, the possibilities are endless, except they aren’t. But at least we can make sure that pools that contain sensitive applications or data can be further protected by mandating addition MFA verification. Its just a shame that it’s not the Microsoft native Authenticator and that we need a 3rd party application.
It does resolve however one problem, while we may mandate MFA at Remote Desktop / Web page from Azure AD, the lack of SSO in WVD makes it possible to then still switch to another account. For example, I could login to Remote Desktop/Webpage with a regular user (with or without MFA) and then try to login to the desktop or application using a domain admin account or a completely different user. This solution at least mandates MFA on a second level as well, until SSO capabilities are available