AutopilotMonitor/docs/backend/cloudpc-device-validation.md

type, title, description, resource, tags, timestamp

type	title	description	resource	tags	timestamp
Concept	W365 Cloud PC Device Validation — Cert-CN-Bound Fallback Validator	Why Windows 365 Cloud PCs can never pass the Autopilot serial lookup, and how the CloudPc validator admits exactly the tenant's service-provisioned Cloud PCs by binding the MDM certificate's Subject CN (= Intune device id) to the Graph virtualEndpoint/cloudPCs inventory.	src/Backend/AutopilotMonitor.Functions/Security/CloudPcDeviceValidator.cs	backend security device-validation windows365 cloudpc graph	2026-08-06T00:00:00+02:00

W365 Cloud PC Device Validation

Windows 365 Cloud PCs are provisioned headless by the Windows 365 service and are structurally never Autopilot-registered — the serial lookup against windowsAutopilotDeviceIdentities (and the Corporate Identifier fallback, whose serials nobody can pre-import for VMs minted at provisioning time) always misses. Before this validator, a Cloud PC agent died in the 403 "Device not registered" even though its mTLS cert was perfectly valid, so Cloud PC first-connect enrollment (Account Setup, RealmJoin, Hello) could not be monitored.

Schema — the validator chain

SecurityValidator.ValidateRequestAsync stage 4 runs the same chain for every device; there is no device-type routing and the local W365 markers (Windows365 registry key, CloudManagedDesktopExtension service) are never consulted for auth — they gain an attacker nothing:

1. Autopilot serial lookup (ValidateAutopilotDevice) — unchanged primary.
2. Corporate Identifier (ValidateCorporateIdentifier) — unchanged fallback.
3. CloudPc (ValidateCloudPcDevice, default off) — only reached when 1+2 missed. Extracts the Intune device id from the chain-validated client certificate's Subject CN (TryGetIntuneDeviceIdFromCertSubject: CN present AND canonical GUID, else definitive reject) and requires a cloudPC object with managedDeviceId eq <CN> in the claimed tenant (GET /v1.0/deviceManagement/virtualEndpoint/cloudPCs?$filter=…). ValidatedBy = ValidatorType.CloudPc (5).

Only machines actually provisioned by the Windows 365 service have a cloudPC object — a regular Intune-enrolled non-Autopilot device still ends in the 403, so the "Autopilot devices only" contract of stages 1–2 is not widened. The tenant hard gate accepts ValidateCloudPcDevice as a third satisfying flag.

Why the cert CN, not headers or local markers

Field-verified 2026-08-06 on a real W365 Enterprise Cloud PC (gktatooine.net):

• MDM client cert Subject CN=07623d56-… == Intune managedDevice.id == cloudPC.managedDeviceId. The CN cannot be forged without the Intune MDM Device CA (chain pinned to embedded roots, CustomRootTrust).
• $filter=managedDeviceId eq '…' is supported server-side on v1.0 — no paging fallback needed.
• managedDevice.serialNumber matches local Win32_BIOS.SerialNumber exactly; the "Cloud PC Enterprise …" model string exists only in Graph, never in local WMI (local WMI reports Manufacturer='Microsoft Corporation', Model='Virtual Machine').

Threat model: a valid Intune cert from a different tenant fails (its CN does not exist in the claimed tenant's Cloud PC inventory — this is a tenant binding the serial-based validators do not have); spoofed serial headers and faked local W365 markers are irrelevant (never consulted); a rogue enrolled VM with doctored SMBIOS cannot mint a cloudPC object (service-side state, not device-reported inventory — the reason the model-string gate was rejected). Retired/deprovisioned Cloud PCs disappear from the inventory and their validation dies with them (compensates the absent cert revocation check). Residual: a compromised legitimate Cloud PC of the tenant — same trust level as any tenant device today, rate-limited by cert thumbprint.

Graph permission plumbing

• Optional add-on permission CloudPC.Read.All — NOT part of the default consent set. Feature W365CloudPcValidation in GraphFeatureCatalog → surfaces automatically in the "Optional Graph capabilities" UI (the feature table and grant command are backend-driven) and in Grant-AutopilotMonitorAddOn.ps1 (-Features W365CloudPcValidation). GraphFeatureCatalogSyncTests pins C# catalog ↔ grant script (previously comment-only lock-step).
• A Graph 403 (permission not granted) is a definitive negative (cached 5 min), NOT transient — a 503 Retry-After loop cannot fix a missing grant. The error message names the add-on feature.
• Same resilience contract as AutopilotDeviceValidator: 30/5 min positive/negative cache, 2 attempts, transient → agent-facing 503.

Bootstrap script interplay (v2.3-dev.3)

The Cloud-PC relax in Install-AutopilotMonitor-dev.ps1 additionally exempts guard 4 (12 h uptime window): a Cloud PC runs headless for days before the user's first connect, and the monitorable phase (Account Setup) only starts at that first connect — the single-fresh-profile window (< 15 min) is the time anchor there, not boot uptime. The OOBE-restore trigger keeps the uptime guard.

Agent-side IsCloudPc flag + decision-engine expectation

Same change set, agent side. CloudPcDetector (V2.Core) re-uses the bootstrap's field-verified marker AND — HKLM\SOFTWARE\Microsoft\Windows365 key plus installed CloudManagedDesktopExtension service (probed via its HKLM\SYSTEM\CurrentControlSet\Services key; the agent deliberately has no System.ServiceProcess dependency). SKIP-safe: any error resolves false.

Three independent transport rails, never an auth input:

• Session metadata — SessionRegistration.IsCloudPc → Sessions table (sticky-true OR across re-registrations, like IsSelfDeployingProfile) → SessionsIndex full mirror → SessionSummary → search filter isCloudPc (portal, /api/search/sessions, /api/raw/sessions, MCP search_sessions/query_raw_sessions). Agent-reported and unverified — can legitimately disagree with the server-derived ValidatedBy = CloudPc (e.g. Cloud PC admitted via a stage that ran earlier).
• Distress channel — DistressReport.IsCloudPc (captured once at DistressReporter construction, BackendClientFactory) rides every pre-auth distress report → DistressReportEntry.IsCloudPc → the "Devices Not Registered" report aggregates it sticky-true per serial (GetDeviceNotRegisteredFunction) and the portal insight renders a Cloud PC badge plus a hint pointing at the Cloud PC validation toggle + the W365CloudPcValidation add-on. Same UNVERIFIED contract as all distress fields; rows from older agents read false. Fits the existing 1536-byte payload cap without a bump.
• Decision engine — the marker rides the EnrollmentFactsObserved payload (isCloudPc), is recorded set-once for BOTH values in EnrollmentScenarioObservations.CloudPc, and annotates the scenario profile reason cloud_pc_first_connect:no_device_esp_expected. That is the engine-recorded expectation "no Device ESP phase will appear": Device-ESP ran headless at provisioning, the session starts at Account Setup. Deliberately reason+observation only — no completion arm depends on DeviceSetup, Mode is still classified by AccountSetup/IME signals (Classic), and EspConfig keeps the configured FirstSync semantics. The positive marker surfaces as cloud_pc_marker in the terminal audit-trail signal census.

Citations

• src/Backend/AutopilotMonitor.Functions/Security/CloudPcDeviceValidator.cs
• src/Backend/AutopilotMonitor.Functions/Security/SecurityValidator.cs — stage 4 chain, TryGetIntuneDeviceIdFromCertSubject
• src/Shared/AutopilotMonitor.Shared/Models/Graph/GraphFeatureCatalog.cs — W365CloudPcValidation
• scripts/CustomerSetup/Grant-AutopilotMonitorAddOn.ps1 — customer-side grant
• scripts/Bootstrap/Install-AutopilotMonitor-dev.ps1 — Cloud-PC relax + guard-4 exemption
• src/Backend/AutopilotMonitor.Functions.Tests/CloudPcDeviceValidatorTests.cs, SecurityValidatorTests.cs, GraphFeatureCatalogSyncTests.cs
• src/Agent/AutopilotMonitor.Agent.V2.Core/Security/CloudPcDetector.cs — agent-side marker AND
• src/Shared/AutopilotMonitor.DecisionCore/State/EnrollmentScenarioObservations.cs — CloudPc fact; reason annotation in EnrollmentScenarioProfileUpdater