Windows MDM enrollment: UI Policy Configuration and Fleetd enrollment trigger

[lukeheath]

Goal

As an IT Admin, I want my Windows devices running Fleetd to enroll in the Fleet MDM server via MDM automatically. The MDM enrollment of Windows devices should occur once Windows MDM is activated through configuration. I should be able to select which teams should be enrolled in MDM. The Windows device end user should not receive any visual indication that the device has been enrolled in MDM.

Tasks

• [ ] Windows MDM can be activated through configuration for specific teams. See UI issue #11952 for more details.
  • [ ] Enable button for Windows MDM
  • [ ] Windows Host Count
  • [ ] MDM profile status
• [ ] Fleetd receives the new settings indicating that MDM enrollment is enabled for the Windows device and triggers the MDM enrollment process.
  • [ ] Fleetd will know that MDM enrollment is enabled for the running host after receiving a policy update.
  • [ ] Fleetd should trigger the MDM programmatic enrollment by calling into the OS API RegisterDeviceWithManagement(). See PoC implementation here.
  • [ ] Fleetd should pass the following JSON payload as part of the ppzsAccessToken parameter. This will be used to authenticate the host and ensure that only valid Windows devices are enrolled. The format is meant to be extensible to support different enrollment scenarios. The RegisterDeviceWithManagement() API will b64 encode this data and send it as part of the wsse:BinarySecurityToken field. This is an opaque value that is carried by the protocol as a blob, see a protocol example here. Suggested format for this payload:

    
    {
    "type": 1, 
    "payload": { 
    "host_uuid": "example-uuid",
    "auth_token": "example-auth-token"
    }
    }

Type 1 means programmatic enrollment, 2 user-driven enrollment, 3 auto-pilot enrollment Payload can be different based on message type

- [ ] There should not be any visual indication that MDM enrollment was performed.

## Context
- Requestor(s): Marcos Oviedo

## QA

### Risk assessment

Risk level: Low / High TODO <!-- Choose one. -->

Risk description: TODO <!-- If risk level is high, explain why. If low, remove. -->

#### Automated:

- Fleet: Cover / Will not cover <!-- Choose one. -->
- QAWolf: Cover / Will not cover <!-- Choose one. -->

### Manual testing steps
<!-- 
Add detailed manual testing steps for all affected user roles. 
-->

1. Enable Windows MDM enrollment on the Fleet UI
2. Check that MDM enrollment is triggered by looking into Fleetd and Fleet server logs
3. On the windows device, go to Settings, "Access Work or School" and check that device appears as enrolled.

<!-- Consider: Do the steps above apply to all global access roles, including admin, maintainer, observer, observer+, and GitOps?  Do the steps above apply to all team-level access roles?  If not, write the steps used to test each variation.
-->

### Testing notes
<!-- Any additional testing notes relevant to this story or tools required for testing. -->

### Confirmation
<!-- The engineer responsible for implementing this user story completes the test plan before moving to the "Ready for QA" column. -->

1. [ ] Engineer (@____): Added comment to user story confirming succesful completion of QA.
2. [ ] QA (@____): Added comment to user story confirming succesful completion of QA.

[lukeheath]

@zhumo - We are creating a few technical foundation user stories for Windows MDM. Because there is no NanoMDM equivalent for Windows, we'll have more foundational work to complete in order to enable feature stories coming from product. @georgekarrv will work with you to bring to MDM design review ASAP this week so we can get started on this in the next sprint.

[zhumo]

@lukeheath thanks! does this block work Automatic or programmatic enrollment? Or, where do we need to slot this in? I think after automatic and programmatic enrollment, we will look at profiles.

[lukeheath]

@zhumo My understanding is the three ~engineering-initiated stories created today are all required to allow any MDM enrollment. @georgekarrv @marcosd4h is that correct?

1. MDM Enrollment: Implement IDiscoveryService (this story)
2. MDM enrollment: Implement MS-XCEP enrollment policy
3. MDM enrollment: Implement certification creation phase (MS-WSTEP)

Because these are required to support MDM enrollment, they must be tackled before any other Windows stories. Following the user story drafting process, we need to bring these to an MDM design review ASAP to be prioritized, estimated, and brought into the upcoming sprint.

[marcosd4h]

@marcosd4h is that correct?

Yes, these 3 stories are required to support MDM windows device enrollment

[zhumo]

OK. And the other two are sub-stories of this one or they're separate stories?

[marcosd4h]

They are separate stories that tackle the functional stages of the Windows MDM enrollment protocol

[zhumo]

@georgekarrv I removed the product label to take it off the board. We're gonna make a subtask of #11952.

[noahtalerman]

@georgekarrv do we still need this for programmatic enrollment to work? My guess is no if programmatic enrollment works as expected.

[georgekarrv]

Closing this as it's no longer needed.

[fleet-release]

Fleetd whispers soft, Windows MDM dance begins, Silent strength shines bright.