When in Client Control mode and if User Consent is not established, Bootoptions API returns status 200 and results in unexpected behavior

[msbreton]

Describe the bug 🪲
When in Client Control mode and if User Consent is not established, Bootoptions API returns status 200 and results in unexpected behavior. Expected Bootoptions API to fail with appropriate status code if User Consent is not established, when in Client Control Mode. Instead, the API returns 200, boots or restarts the system, but resulting behavior is incorrect. See Repro steps for example.

To Reproduce 🪜
Steps to reproduce the behavior:

1. Activate device in Client Control Mode, configured for CIRA
2. Ensure device is connected
3. Issue /api/v1/amt/power/bootoptions/{guid} with action=101, which should Reset to BIOS
4. API returns 200 and device restarts but attempts PXE boot. Suspect exact failure scenario could be OEM dependent.
5. If you repeat these steps but establish User Consent before calling /api/v1/amt/power/bootoptions/{guid}, the API returns 200 and the device Boots to BIOS as expected.

Expected behavior
Bootoptions API should fail with appropriate status code if User Consent is not established, when in Client Control Mode.

Screenshots 🖼️
If applicable, add screenshots to help explain your problem.

AMT Device (please complete the following information): 🖥️

• OS: Windows 10
• OEM: Lenovo
• AMT Version: 14.1.53
• AMT Configuration Mode: Client Control Mode
• Network Configuration: Dynamic IP / CIRA

Service Deployment (please complete the following information): ⛈️

• Deployment Type:
• Node Version:
• Component & Version: MPS 2.13.10

Additional context
Add any other context about the problem here.

[bwendlandt-intel]

Hey! Can you also provide the MPS logs from when you are making this API call and seeing this interaction?

[msbreton]

I can get those, but I have new info that may negate this issue.
Turns out the booting to PXE was related to our test system/env. The behavior is the same as noted above but the system just restarts normally. It does not attempt any boot option. I think this may be expected behavior, although it would be very nice if the API knew if User Consent was needed, and not established, and returned a status code other than 200 - but I suspect that may be a limitation of AMT and not SW. Any thoughts?