- Entra Conditional Access policy details
- User Experience
- Why No Prompts for Re-Authn?
- Addressing Secure Requirements
- Improving the End-user Experience
Here’s a quick post on configuring strong authentication requirements for Azure Virtual Desktop and Windows 365 using Entra Conditional Access.
Customers may want to protect these virtual desktop resources because these desktops provide access to sensitive resources. For example, you could be using AVD as a protected administrator workstation or providing access to internal applications. To provide confidence that these resources are protected, strong authentication requirements are needed.
In this article, I’ll walk through configuring a Conditional Access policy that requires strong multi-factor authentication every time these resources are accessed, to govern virtual desktop access.
This configuration is specifically tailored for high security requirements, so I’ll also demonstrate the client experience with this policy in place, along with some considerations.
Entra Conditional Access policy details
Assignments
To configure authentication requirements, let’s create a new Conditional Access policy:
- Policy name - I’ve given this policy a descriptive name: Require strong authentication for Azure Virtual Desktop and Windows 365
- Users - I want to target All Users with this policy so that any user with access to AVD or Windows 365 is covered with strong authentication. We could exclude a break glass account in this policy; however, there may be other methods to access to Entra ID; therefore there may not be a need to exclude specific accounts.
- Target resources - select Azure Virtual Desktop and Windows 365. If your tenant was previously enabled for Windows Virtual Desktop, you may see that application instead of Azure Virtual Desktop.
- Network - select Any network or location. The intention of this policy will be to require strong authentication regardless of location. The network you are connected to should not be an indicator of trust in this scenario.
Access controls
- Grant - select Grant access, choose Require authentication strength and select Phishing-resistant MFA, then choose For multiple controls / Require all the selected controls. The last setting is not necessarily required but a good practice in the event this policy is updated with additional controls.
- Session - select Sign-in frequency and then choose Every time. This will require reauthentication each time these resources are accessed and will impact end users who need to provide MFA responses.
User Experience
Here’s a look at the end-user experience. In this demo, I’m signing into the Windows 365 web client and authenticating with a FIDO2 key for strong authentication and connecting to my Cloud PC a couple of times. You’ll see that the sign-in experience is fast and simple, but I am not asked to reauthenticate each time I launch a Cloud PC:
Let’s try again after a period of time - this time we can see that I am asked to re-authenticate to access my Cloud PC:
Why No Prompts for Re-Authn?
At first glance, it might look like our policy is not working and is allowing the user to re-launch their desktop without being re-authenticated. Behind the scenes, the user still has a valid Entra ID token with a claim for strong authentication which satisfies the requirement.
This access still works because Entra ID tokens have a minimum lifetime of 10 mins as listed here: Access, ID, and SAML2 token lifetime policy properties. This document covers an in-preview feature configurable token lifetimes and has an important consideration for these lifetimes:
Reducing the Access Token Lifetime property mitigates the risk of an access token or ID token being used by a malicious actor for an extended period of time. (These tokens can’t be revoked.) The trade-off is that performance is adversely affected, because the tokens have to be replaced more often.
So after 10 minutes, the lifetime expires and the user is asked to re-authenticate. For all but the most restrictive customer environments, this behaviour should be OK.
Addressing Secure Requirements
In scenarios where the requirement for re-authentication cannot be met and access to Azure Virtual Desktop or Windows 365 needs to be protected, you could consider implementing additional requirements:
Grant controls - where you are protecting access to sensitive information and privileged access workstations, select Require device to be marked as compliant in addition to Require authentication strength. This ensures that access is only allowed from a trusted, managed device that meets Intune compliance policies.
Session controls - enable Require token protection for sign-in sessions. This feature can further protect from token theft, and supports the Windows App on a Windows client OS now (with macOS in preview): Token Protection in Microsoft Entra Conditional Access.
Enabling this session control also requires you to update the CA policy to support only Windows, macOS, and iOS (optionally, with a separate policy that blocks other platforms). This requirement will also prevent users from using the Windows 365 web client. I did encounter issues getting this to work with the current Windows app on macOS (I haven’t tested with a preview client).
Improving the End-user Experience
This type of policy is typically required for highly secure environments and isn’t necessarily used to support general access to Azure Virtual Desktop or Windows 365 for most users. To improve the authentication experience, here are few considerations:
- Scope the policy to Entra ID administrator roles - policies that include strict sign-in frequency requirements would be best scoped to accounts with privileged roles with a separate policy for longer sign-in frequency for general users.
- Use separate Azure Virtual Desktop host pools for general end-users and administrator accounts. Users with access to both could then have a simplified sign-in experience on a corporate desktop with stricter sign-in to an administrator desktop.
- All users should use at least password-less authentication with the Microsoft Authenticator to speed, simplify and secure sign-ins.
- Don’t use Sign-in frequency with high sign-in frequencies without number matching or password-less authentication in the Microsoft Authenticator. Making it easier on users to sign-in will help balance experience with security.
- Follow the recommended authentication scenarios from Microsoft: Conditional Access adaptive session lifetime policies.
