Windows365

Configure Windows 365 SSO

Leon Chung

• 3 min read
Share
Configure Windows 365 SSO
Photo by Georg Bommeli / Unsplash

If you've stood up Windows 365 Cloud PCs, you've probably hit the double sign-in: users log in to the Windows 365 portal or your SSO of choice, then get asked to sign in again once the Cloud PC session actually launches. Single sign-on (SSO) via Microsoft Entra ID fixes this, but the setup guides out there don't agree with each other, and Microsoft updates their UI quite often.

This post walks through what I did this year 2026 in July.

The three moving parts

The MS Docs references multiple things, but here's what worked for me in three pieces:

  1. A tenant-wide service principal flag that allows Microsoft Entra authentication for RDP at all.
  2. A device group that controls whether users get a connection-consent prompt.
  3. An enablement toggle that actually turns SSO on — and where this toggle lives depends on which Windows 365 edition you're running.

The toggle isn't where you think it is (depends on edition)

The two guides I followed describe an org-wide switch: Windows 365 admin center → your org's Cloud PC settings → flip SSO on. Seems to only be available for Windows 365 Business.

If you're on Windows 365 Enterprise with Intune managed provisioning policies, that switch doesn't exist for you. Instead SSO lives per provisioning policy, under General settings ("Use Microsoft Entra single sign-on").

You probably only need one service principal, not two

Microsoft's own setup scripts touch isRemoteDesktopProtocolEnabled on two service principals: Windows Cloud Login and Microsoft Remote Desktop. Seeing both in the same PowerShell block makes it look like you need both.

In practice, Windows Cloud Login is the one you need if you're only using the web or Windows App; it's what lets Entra ID issue RDP access tokens in the first place. Microsoft Remote Desktop only matters for older Remote Desktop client versions. If your users are on the current Windows App or a modern client, SSO works fine without ever touching that second service principal.

Worth testing in your own tenant before blindly configuring both, it's the kind of assumption you carry over from a script and never notice was unnecessary.

Step-by-step

Prerequisites: Application Administrator or Cloud Application Administrator role in Entra ID, Cloud PCs on a supported Windows 10/11 build, and either the Microsoft Graph PowerShell SDK or just Graph Explorer if you'd rather not deal with PowerShell.

  1. Enable RDP auth on the Windows Cloud Login service principal. You can do this via Graph Explorer or PowerShell, figure out your WCL GUID, and set the the required properties. I personally followed Jan's blog (linked on the bottom) using Graph Explorer. Make sure to grant permission for Graph Explorer for your GET / POST / PATCH needs. Once you've found the GUID, you'll want to expand into the remoteDesktopSecurityConfiguration object on the service principal and set isRemoteDesktopProtocolEnabled to true.
    1. Get GUID: GET https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appId eq '270efc09-cd0d-444b-a71f-39af4910ec45'
      This App ID is the same across all tenants.
    2. Get your WCL's actual ID in your tenant and verify if the protocol is enabled or not: GET https://graph.microsoft.com/v1.0/servicePrincipals/YOUR-WCL-ACTUAL-ID?$expand=remoteDesktopSecurityConfiguration
    3. Enable it if it isn't using PATCH. PATCH https://graph.microsoft.com/v1.0/servicePrincipals/YOUR-WCL-ACTUAL-ID/remoteDesktopSecurityConfiguration
      with the request body:
      {
      "isRemoteDesktopProtocolEnabled": true
      }
  2. Create a dynamic device group. Scoped to your Cloud PCs, added as a targetDeviceGroup on the same service principal.
    1. Create your dynamic group in Entra ID with the rule for all Windows 365 CPC using "deviceModel Starts With Cloud PC". Rule looks like this: device.deviceModel -startsWith "Cloud PC"
    2. Add it to your SP in Graph
      POST https://graph.microsoft.com/v1.0/servicePrincipals/YOUR-WCL-ACTUAL-ID/remoteDesktopSecurityConfiguration/targetDeviceGroups
      with the Request Body:
      {
      "@odata.type":"#microsoft.graph.targetDeviceGroup",
      "id":"YOUR-GROUP-GUID",
      "displayName":"Your Dynamic Group name"
      }
    3. You can verify your work by running 1b a couple steps ago again in Graph Explorer
  3. Turn on SSO:
    Intune → Devices → [Left nav] Manage Windows 365 Cloud PCs/Provision Cloud PCs → Provisioning policies → [select policy] → Properties → Edit General → tick "Use Microsoft Entra single sign-on." → Next and Update → Apply this configuration → Select "Microsoft Entra single sign-on for all devices" → Apply
  4. Reprovision NOT required. macOS users with Windows App might need to sign back in to the app but it was unclear if that was just an SSO token needing a refresh or if a simple re-launch would have worked. On Windows, a relaunch was not needed and the web version went straight through on all OSes.

Sources