Support userless (device-context) Windows MDM enrollment

[getvictor]

Goal

User story
As a Fleet administrator managing Windows hosts via fleetd,
I want Fleet to enroll a Windows host into Fleet MDM without requiring an interactive user to sign in,
so that I can send MDM commands (configuration profiles, disk encryption, scripts) to freshly imaged, headless, kiosk, and shared devices immediately.

Today fleetd enrolls a Windows host into Fleet MDM by calling the Windows user-enrollment API RegisterDeviceWithManagement. orbit runs as the SYSTEM account, and this API needs an interactive user security context. When no user is signed in, the call fails with 0x80070525 (ERROR_NO_SUCH_USER) and orbit retries on every config poll without ever enrolling. The host reports "MDM: Off", and any queued Windows MDM commands (including the disk encryption profile) stay pending until a user finally signs in, at which point the same call succeeds within about 30 seconds.

Fleet's MDM server advertises the OnPremise authentication policy, but its WSTEP handlers only accept a <wsse:BinarySecurityToken> (the orbit node key for programmatic fleetd enrollment, or an Entra AAD JWT for Entra-joined or Autopilot devices). The industry-standard userless path on Windows is a provisioning package (Microsoft bulk enrollment), applied by Install-ProvisioningPackage as SYSTEM with no user. That path presents a <wsse:UsernameToken> under the OnPremise policy, which Fleet explicitly rejects.

Changes

Product

• UI changes: TODO
• CLI (fleetctl) usage changes: TODO
• YAML changes: TODO
• REST API changes: TODO
• Fleet's agent (fleetd) changes: TODO
• Fleet server configuration changes: TODO
• Exposed, public API endpoint changes: TODO
• fleetdm.com changes: TODO
• GitOps mode UI changes: TODO
• GitOps generation changes: TODO
• Activity changes: TODO
• Permissions changes: TODO
• Changes to paid features or tiers: TODO
• My device and fleetdm.com/better changes: TODO
• Usage statistics: TODO
• Other reference documentation changes: TODO
• First draft of test plan added
• Once shipped, requester has been notified
• Once shipped, dogfooding issue has been filed

Engineering

• Test plan is finalized
• Contributor API changes: TODO
• Feature guide changes: TODO
• Database schema migrations: TODO
• Load testing: TODO
• Pre-QA load test: TODO
• Load testing/osquery-perf improvements: TODO

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

Risk assessment

• Requires testing in a hosted environment: TODO
• Requires load testing: TODO
• Risk level: Low / High TODO
• Risk description: TODO

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

Core flow

• TODO

Edge cases

• TODO

Supplemental testing

Testing notes

Confirmation

1. Engineer: Added comment to user story confirming successful completion of test plan (include any special setup, test data, or configuration used during development/testing if applicable).
2. QA: Added comment to user story confirming successful completion of test plan.
3. QA: Determined whether this story needs Playwright automation.
   • Needs automation: Yes / No
   • If yes, filed a follow-up issue in the :help-qa project with status "Needs automation":