AVD with AAD only support with MFA from a device not associated with the same tenant?

Copper Contributor

Hi,

 

From what I gather in the documentation AVD with AAD only does not support MFA from client which is not AAD Registered/Joined (or Hybrid joined) to the same tenant. 

Important note.png

But, is authentication from devices not in the same tenant the very situation where MFA would be beneficial? 

 

So, if I would create some kind of BYOD scenario where the physical hardware are only used as a jump station to the AVD, I would not be able to enable MFA during login? Sure, when subscribing to the workspace I would be prompted once - but for subsequent turns I would login automatically, since I'd be forced to exclude the 'Azure Windows VM Sign-In' from my Conditional Access policy to be able to login. 

 

Or am I missing something obvious here? 

 

Looking forward to your kind reply,

Theodor

8 Replies

This isn't exactly what you're looking for, but would get you close: you can ensure that per-user MFA is not enabled on any users, and make sure your MFA conditional access policy is only set to the Cloud apps or actions of Windows Virtual Desktop, and not Azure Windows VM Sign-In. 

 

As you noted, this will allow relaunches of the desktops without MFA.  To mitigate this, you can then set the Access Controls > Session > Sign-in frequency to a short timeout.  This will ensure that the user has to sign back into the AVD client app itself once the set timeout has expired, when they try to launch a connection.  (https://docs.microsoft.com/en-us/azure/virtual-desktop/set-up-mfa)

 

The effect of this is that MFA is still enforced at desktop launch or reconnection provided you set your sign-in frequency low enough, but is enforced at the layer of communication between the AVD client and the control plane (e.g. when retrieving the RDP connection data), instead of on the RDP connection / Windows login process itself. 

Hi Smaiberger,

many thanks for your reply!

I read through the article you share and I attempted it in practice, but I just can't get it to work. To simplify I created 1 CA policy which enforce MFA for everything except 'Azure Windows VM Sign-In' and set the sessions 'Sign-in frequency' to 1 hour. After this I noticed that for my portal.azure.com experience I am prompted to refresh my session, but the SessionDesktop experience keps working without having to re-authenticate using MFA.

So, more accurately: I can keep an active session in my Remote Desktop Client without being prompted to re-authenticate for more than two hours. After more than two hours I can also restart my PC and still not being prompted.

Any suggestions?

I spun up an AAD-joined host pool and ran some tests with the timeout set to 1 hour to validate the behavior you're seeing. 

 

I need to do more testing, but they do seem to indicate that there's something like a background refresh of the token happening as long as the session is actively connected from the client as you noted.  If the sign-in frequency is set to 1 hour and a session is not actively connected, the timeout takes effect as expected after the 1 hour of disconnection.  Here's the timeline of tests I've run so far:

 

5:09 PM: Remote desktop app is open and I've recently launched a desktop, then disconnectced the session, and left the Remote Desktop app open. I implement a conditional access policy with a 1 hour timeout

 

6:10 PM: In the already-open Remote Desktop app, I click to reconnect to the desktop. I am prompted for auth including 2FA by the Remote Desktop application before the desktop starts to connect, followed by the normal password prompt from the RDP connection. I disconnect from the desktop.

 

6:17 PM: Reconnect to desktop, which was last authed to 7 minutes ago. I receive no login prompt from the Remote Desktop app side (and did not expect one, since I'd just authed 7 minutes ago), only the normal password prompt from the RDP connection. I minimize the session to my taskbar.

 

7:18 PM: I disconnect from the desktop and try to reconnect to the desktop from the Remote Desktop app. I do not receive a prompt for auth from the Remote Desktop app, only the normal password prompt from the RDP connection. However, if I try to refresh the workspace, I am then prompted for auth, and if I don't auth successfully, I can't then attempt another launch of the desktop without having to auth (including MFA). I connect to the desktop and leave it minimized.

 

8:20 PM: (Repeat of previous test) Remote desktop app open, session was reconnected to > 1 hour ago, and left minimized in my taskbar. I disconnect from the desktop and try to reconnect to the desktop from the Remote Desktop app. I do not receive a prompt for auth from the Remote Desktop app, only the normal password prompt from the RDP connection. However, if I try to refresh the workspace, I am then prompted for auth, and if I don't auth successfully, I can't then attempt another launch of the desktop without having to auth (including MFA). I connect to the desktop, then disconnect from it.

 

9:31 PM: Remote desktop app is open, session has been disconnected for > 1h. I try to reconnect to the desktop. I am prompted for auth by the Remote Desktop application before the desktop starts to connect, including 2FA required. I disconnect from the desktop.

 

If you open the RD app, connect to a desktop, then disconnect from it, wait over an hour, and reconnect to it, are you then prompted for 2FA like I'm seeing?  Or do you not receive the 2FA prompt on reconnect in that case either?

Hi, that does indeed sound promising! I had to fix an urgent issue today, so I didn't have time to review this in detail yet. I'll get back to you with an update on Monday.

If it works I'll buy you a batman costume, because you'll be my new superhero!

Hi @ShawnMaiberger,

So unfortunately I am unable to completely replicate your experience. Or maybe I am misunderstanding how you are prompted? We have configured a session timeout, but when it is reached and I try to reconnect to my VM I just get an error message "Couldn't connect" as per image below. The only way to connect to the VM again is to unsubscribe and subscribe to the same workspace. This seem like to much a hazzle for the everyday user and is such not a valid scenario. 

 

 

t.png

 

When I click the Workspace details button I see that "We need your sign in information to refresh this feed. Click refresh to get started." - but nothing happens when I click refresh. tt.png

 

Just to clarify, I have 1 CA policy with require MFA for everyone but have excluded "Azure Windows VM Sign-In". 

 

Any thoughts? 

BR

Theodor

@TheodorBrander That's definitely not the behavior I'm getting.  I created and annotated a video with what I get for you here, so you can see how it works for me.  https://www.youtube.com/watch?v=cuSXPkCJlKo

 

The video starts with me having an invalid token (it's been > 1 hour since I last had a desktop connected), as you can see from the details tab.  Instead of clicking refresh, I just try to open a desktop, and get the expected 2FA prompt, followed by the RDP connection's U/P (since you'll always get U/P prompt in this configuration).  Then I show that after disconnect, I can refresh the feed and launch the desktop again without prompt, since doing the 2FA on desktop launch successfully refreshed my token for an hour.

 

Alternatively (not shown), the opposite order works.  If it's been more than an hour and I see my last refresh was not successful, I can click refresh on the feed first, and get a prompt for 2FA when doing that.  Then once I do that, I do not get a 2FA prompt on launching the desktop, since I have a valid token for 1 hour for anything I do with that identity within the Remote Desktop app.

 

My gut instinct says there's something being applied at the Conditional Access policy that isn't quite matching, i.e. being applied too broadly.  There are multiple services involved, and I'm thinking that maybe doing an include all, exclude only on VM sign-in might be causing some issues with the feed refresh.  I know back in WVD classic, for example, there was a separate entry for both the desktop and the feed both on the AVD side, separate from the VM sign-in on the Azure VM side.  So there may be some other services your policy is applying to since you're doing all by default that are making things not quite work as expected.

 

What you might try doing is setting your Cloud Apps and Actions as a test to exclude: none, include: only Windows Virtual Desktop (make sure it's the same GUID as the one below, as there are a few for AVD classic as well that aren't the ones you want).

 

The following are my CAP settings that lead to the results as in the video:

 

Users or workload identities settings

CAP - User Settings.png

 

Cloud apps or actions settings

CAP - Actions Settings.png

Grant settings

CAP - Grant Settings.png

 

Session settings

CAP - Session Settings.png

 

Also, what version of the AVD client are you using?  I don't think it should matter, but I'm on the latest, 1.2.2687.0.

Thank you for your reply @ShawnMaiberger! Unfortunately, I do not know where I messed up (or if there is some other problem/root cause). So, I have now downloaded the latest version of remote app and changed so that I only have 1 CAP, identical to what you have below. But no cigar. I still have the issue where after the time-out is reached, the error message I posted earlier ("We need your sign in information to refresh this feed.") where I am unable to login without unsubscribing and then resubscribing. 

 

I have looked through the sign-in logs in Azure Active Directory and the only two entries I have are from "Azure Virtual Desktop Client" when i subscribe and then from the "Windows Sign In" during the RDP authentication. I thought it might be something with my devices being enrolled to Intune, so I created some new Session Hosts that was not enrolled, but ye - still no change. Maybe MS support next? 

Did you get this sorted? I have similar issue. I just found that the MS Store version of Microsoft Remote Desktop is not supported for AVD. You have to use the Desktop version: https://learn.microsoft.com/en-gb/azure/virtual-desktop/whats-new-client-windows