Windows 365 (and Azure Virtual Desktop) Conditional Access Deep-Dive
Recently, I had the pleasure of troubleshooting Windows 365 Single Sign-On (SSO) – the issue was quite odd. When you open the Windows 365 website (windows365.microsoft.com) or the "Windows App", authentication is requested as expected. However, when establishing a session with one of the virtual desktops, instead of being seamlessly logged in, another authentication prompt appeared.
This task was assigned to me because after reviewing the Windows 365 SSO configuration, it was suspected that the issue might be related to Conditional Access (CA). Several hours later, the suspicion was partially confirmed, and I ended up with a deeper understanding of the behavior than I might have wanted.
But before I get ahead of myself, let’s take a look at the results of the analysis.
⚠️ While writing this article, the original issue in Windows was likely (temporarily?) fixed by an update. The problem persisted from around April 2024 until early September 2024 (sigh) ⚠️
Although the issue has been resolved, the information in this article may still be helpful in addressing similar or recurring problems. From personal experience, I know how valuable older Troubleshootings can be, which is why I wanted to leave this article mostly unchanged as a sort of ‘time capsule.’
"Azure Virtual Desktop" is in parentheses because I did not repeat the tests with AVD. However, since the Enterprise Apps configured in CA are the same, I am making an educated guess that the behavior is similar.
I assume you are always configuring Entra ID SSO for Windows 365 – the benefits of modern authentication methods like FIDO2 keys and Hello for Business should be strong enough arguments, not to mention seamless SSO when there are no issues. The same applies to AVD.
Tests
I’ll spare you the full, unstructured test protocol and instead provide an overview of the approach.
⚠️ The full test catalog was performed on a device that was neither Entra Registered nor Joined. Why this is relevant will be explained later. ⚠️
First, a test user was set up, who was exempt from all other CA policies. This user was always subject to a CA policy, with varying targeting of the Enterprise Applications which are listed in the documentation of Windows 365 login (see chapter "Involved Applications"). Grant and Condition behaviors were also tested.
My hope was that by setting "Sign-In Frequency: Every Time," I could avoid having to log out and log back in every time, as well as prevent caching issues. However, this turned out to be a mistake, which I will explain in the SSO Fix.
Conditional Access Reference: Control Setting Target resources Varying: [Windows 365, Azure Virtual Desktop, Microsoft Remote Desktop, Windows Cloud Login] Conditions Varying: [Mobile apps and desktop clients, Web Browser] Grant Varying: [Require MFA, Require Authentication Strength] Session Sign-In Frequency: Every Time, Varying: Browser Persistence
Another challenge during the tests was that I left 10 minutes between each step to avoid Prompt Tolerance. Entra would not trigger a repeated login when requests come in too quickly, to prevent overloading users and services when there are misconfigured apps or policies.
Once the policy was set, the following tasks were repeated for both W365 Web and the Windows App:
- Open the client, note if (multi-factor) authentication is required
- Start a session, either directly in the browser or via the Remote Desktop App; if the W365 App is installed, I assumed it would be used as the client and not just for the session
- Directly start a session, via URL in W365 Web (
https://windows365.microsoft.com/webclient/[GUID]) or from the Windows App pinned desktop - Log out of the client
- Directly start a session again (to check if the client login is fully separated from the session)
- Review the sign-in logs for any anomalies and new applications/resources
Findings
- The client login and the session establishment are separate processes, even with SSO configuration
- This means that for a seamless SSO experience without interruptions, the endpoint must be able to carry the login forward.
- With the Windows 365 App, a session cannot be started directly from a "favorite"; you must first log in to the W365 client
- In contrast, session initiation via W365 Web does not require prior authentication in the client
- It’s crucial to apply the strictest security controls to the "Azure Virtual Desktop" or, with active SSO, the "Microsoft Remote Desktop / Windows Cloud Login" Enterprise App, as these generally serve as the gateway to the "trusted" session
- Saving the link to the open browser session (
https://windows365.microsoft.com/webclient/[GUID]) can be a legitimate workaround for SSO issues, provided you don’t need the benefits of the Windows App.
- A CA policy that prohibits browser persistence naturally also affects W365 Web – you’ll need to log in every time unless the device is registered and supports SSO
Besides the listed findings, I also gathered a detailed list of the involved app registrations and login flows. Since I currently see no practical use for this table, I placed it at the end of the article.
The SSO Fix
⚠️ As mentioned in the introduction, this behavior has since been resolved. ⚠️
First, an overview of my starting point: Our company’s internal configuration of Windows 365 / AVD had a completely smooth SSO experience, even on an unmanaged device. Once logged in via W365 Web or the Windows 365 App, there was no need to authenticate again when establishing a session.
The problem existed only with a specific customer, where all my tests led to no improvement. My preliminary conclusion was that the issue likely lay in the customer’s configuration.
While structuring and analyzing the test results, I had an epiphany. A constant in all tests was the setting ‘Sign-In Frequency (SIF): Every Time’. And since I had encountered issues with SIF in the past, I wanted to see how things behaved without it.
And behold – when I logged into the desktop app without Sign-In Frequency, I didn’t have to authenticate again during the session.
We had already experienced a similar issue elsewhere, while troubleshooting the Entra ID Error Code 9002341 – Sign-In Frequency seems to destabilize session management on unregistered devices, leading to problems with advanced SSO functionality.
Remember the word "unregistered" – When a device receives a Primary Refresh Token, these issues do not occur. I verified this by using another test device and adding the customer’s user account to Windows (Settings -> Accounts) – and indeed, the issues disappeared.
How I Now Configure Conditional Access
As a foundation for this topic, I recommend the Microsoft documentation. Here’s a summary:
Clients: Windows 365 (app ID 0af06dc6-e4b5-4f28-818e-e78e62d137a5)
Session: Azure Virtual Desktop / Windows Virtual Desktop (app ID 9cdead84-a844-4324-93f2-b2e6bb768d07)
SSO: Microsoft Remote Desktop (app ID a4a365df-50f1-4397-bc59-1a1564b8bb9c) + Windows Cloud Login (app ID 270efc09-cd0d-444b-a71f-39af4910ec45)These grouped apps should be treated uniformly. Both the session and SSO should always require at least MFA, and be configured similarly for Sign-In Frequency. Typically, this is already covered by an All Applications policy. Right?
⚠️ Since the SIF issue has now been resolved, the workarounds listed below are no longer necessary. ⚠️ However, it may still be useful to configure clients with a longer Sign-In Frequency than the session, especially for Android and iOS devices, where a longer Sign-In Frequency is often allowed. Oftentimes longer than what might be wanted for a session with a "trusted" Windows PC.
If there are no Sign-In Frequency requirements, I don’t see any necessary "workarounds" for Windows 365. However, it’s often part of the virtual desktop use case, that non-compliant devices are allowed access (i.e., an exception to rules requiring "Require Compliant Device"). In such cases, sessions should time out as quickly as possible.
If Sign-In Frequency is mandatory, devices should ideally be Entra ID registered or joined and managed through Intune. In this scenario, no special configuration for Windows 365 is necessary. However, if unmanaged devices are the primary use case for Windows 365 or AVD, this cannot be assumed.
To improve registration, a user campaign could be considered. (Here’s an example FAQ from the University of Illinois – in Germany, however, privacy and workers’ council regulations must be carefully followed).
If Sign-In Frequency is required, I recommend a Conditional Access exception for the "Windows 365" Enterprise App, at least until SIF behavior improves. I choose this app because only basic desktop controls are available in it. For example, if the session is only renewed in the clients every two weeks, the user generally only has to authenticate when starting a new session.
If this is not an option, either users will need to sign in twice, or the workaround mentioned in the findings can be used: using the browser session via https://windows365.microsoft.com/webclient/[GUID] with the corresponding limitations.
Final Words
During my research, I also came across several other interesting articles offering advanced tips/tricks around W365 Conditional Access, which I certainly don’t want to withhold:
- You can explicitly set the Windows App or W365 Web as the client
- If you are not confident with the SIF "Every Time" Conditional Access setting since it is in Public Preview, it might be better to simply disable SSO
If you’re interested in seeing how W365 looks in the Entra ID Sign-In Logs, I’ve collected the known apps at the end of the article, along with how to retrieve the current status.
If this article closed a knowledge gap or solved a problem for you, or if you have further questions, feel free to let me know on LinkedIn.
Terminology
To distinguish between the often very similar-sounding terms, I have tried to adhere to the existing documentation as closely as possible. For clarity, here is an explanation of the terms I am using:
Windows App
The Windows App is the new desktop (or mobile) client for Windows Remote sessions, including AVD and W365 apps and desktops. For users of other VDI environments, it corresponds roughly to the Citrix Workspace App or VMware Horizon Client.
Windows 365 Website
(Short: W365 Web)
The pure web interface for Windows 365 (https://windows365.com), with the option to open a session in Windows Remote Desktop or directly in the browser.
Session
A session refers to the active connection to a remote PC. In the two previous screenshots, this is effectively everything that happens once you click the "Connect" button (or open in W365 Web Browser / Desktop App).
Client
The term ‘client’ encompasses both W365 Web and the Windows App (probably also Windows Remote Desktop, but this was not part of my tests). Sessions are started from here.
Involved Applications in Detail
Here are the application and resource IDs that I observed in the Sign-In logs:
The "Windows 365" application selectable in Conditional Access aggregates various frontend endpoints (think "Office 365," which includes Exchange, Teams, etc.):
- Windows 365 Portal: 3b511579-5e00-46e1-a89e-a6f0870e2f5a
- Windows 365 IW Service: 7c0a6aea-533c-458c-9f81-15568f10f6e4
- Windows 365 Client: 4fb5cc57-dbbc-4cdc-9595-748adff5f414
- (likely more that I did not observe in detail)
From this collection, I learned that it is difficult to fully trace how these interact via Sign-In Logs, which complicates reporting on Windows 365 usage. Additionally, this list might help someone associate an Application ID with its corresponding service.
The resources used are always associated with the first application listed, and the IDs always correspond to the display name above. For example, the Windows 365 Client has the ID 4fb5cc57-dbbc-4cdc-9595-748adff5f414.
| Application | Utilized Resources |
|---|---|
| Windows 365 Client | Azure Virtual Desktop |
| 4fb5cc57-dbbc-4cdc-9595-748adff5f414 | Microsoft Graph |
| Windows 365 IW Service | |
| Windows 365 Portal | |
| Windows 365 Portal | Azure Virtual Desktop |
| 3b511579-5e00-46e1-a89e-a6f0870e2f5a | Windows 365 Portal |
| Microsoft Remote Desktop | |
| Office365 Shell WCSS-Server | |
| Microsoft Graph | |
| Windows 365 IW Service | |
| Windows Cloud Login | |
| OCaaS Client Interaction Service |
| Resource | Accessing Applications/Clients |
|---|---|
| Azure Virtual Desktop | Azure Virtual Desktop Client |
| 9cdead84-a844-4324-93f2-b2e6bb768d07 | Windows 365 Portal |
| Windows 365 Client | |
| Windows 365 Client – iOS | |
| Windows 365 Client – Web | |
| Microsoft Remote Desktop | Windows 365 Portal |
| a4a365df-50f1-4397-bc59-1a1564b8bb9c | Azure Virtual Desktop Client |
| Windows 365 IW Service | Windows 365 Portal |
| 7c0a6aea-533c-458c-9f81-15568f10f6e4 | Windows 365 Client |
| Windows Cloud Login | Azure Virtual Desktop Client |
| 270efc09-cd0d-444b-a71f-39af4910ec45 | Windows 365 Portal |
| Windows 365 Portal | Windows 365 Portal |
| 3b511579-5e00-46e1-a89e-a6f0870e2f5a | Windows 365 Client |
A complete sign-in configuration can be evaluated with KQL as follows:
The initial list of App IDs came from observing the Sign-In Logs in my tests.
A view is more efficient as it does not store the data in a temporary variable but directly uses it in the query.
let involvedApps = dynamic(["0af06dc6-e4b5-4f28-818e-e78e62d137a5","9cdead84-a844-4324-93f2-b2e6bb768d07","a4a365df-50f1-4397-bc59-1a1564b8bb9c","7c0a6aea-533c-458c-9f81-15568f10f6e4","4fb5cc57-dbbc-4cdc-9595-748adff5f414","3b511579-5e00-46e1-a89e-a6f0870e2f5a","270efc09-cd0d-444b-a71f-39af4910ec45"]);
let accessedAsResource = view()
{ AADSignInEventsBeta
| where ResourceId in (involvedApps)
| summarize make_set(Application), make_set(ResourceDisplayName) by ResourceId
};
let accessedAsApp = view()
{ AADSignInEventsBeta
| where ApplicationId in (involvedApps)
| summarize make_set(Application), make_set(ResourceDisplayName) by ApplicationId
};
union withsource = "SourceTable" accessedAsApp, accessedAsResource
| project ApplicationId, ResourceId, Applications = set_Application, Resources = set_ResourceDisplayName
Comments