macOS local account: add support for standard or no account for end user

[melpike]

Goal

User story
As an IT admin,
I want the option for the macOS local admin account to be created first
so that it can force the second account (end user) to be a standard account or skip account creation.

Changes

UPDATE: we are adding support for skip account creation into this issue.

Product

• UI changes: Figma
• CLI (fleetctl) usage changes: No changes
• YAML changes:
  • Allow end_user_local_account_type to accept admin, standard, or none as account type
• REST API changes:
  • Allow end_user_local_account_type to accept admin, standard, or none as account type
• Fleet's agent (fleetd) changes: No changes
• Fleet server configuration changes: No changes
• Exposed, public API endpoint changes: No changes
• fleetdm.com changes: No changes
• GitOps mode UI changes: All options under Controls > Setup experience > Users should be disabled in GitOps mode
• GitOps generation changes: No changes
• Activity changes: No changes
• Permissions changes: No changes
• Changes to paid features or tiers: No changes
• My device and fleetdm.com/better changes: No changes
• Usage statistics: No changes
• Other reference documentation changes:
  • [Docs] Rename 'End user authentication' to 'Require IdP authentication' in docs #44830
  • [Route] Add route for end user accounts guide #45249
• First draft of test plan added
• Once shipped, requester has been notified
• Once shipped, dogfooding issue has been filed Dogfood: ____macOS local account: add support for standard or no account for end user #48094

Engineering

• Test plan is finalized
• Contributor API changes: No changes
• Feature guide changes: http://github.com/fleetdm/fleet/pull/44855
• This is a premium only feature: Yes

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

Risk assessment

• Risk level: Low

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

MDM

• Turn Apple MDM on / off: Verify the account type setting persists correctly when toggling MDM.
• SSO enabled for DEP enrollment: Test that "admin", "standard", and "none" account types work correctly with SSO-based DEP enrollment.
• SSO not enabled for DEP enrollment: Test that "admin", "standard", and "none" account types work correctly with SSO-based DEP enrollment.
• Setup experience software / scripts: Confirm the managed local account creation (with both types) works alongside other setup experience items for each account type. Check local managed account password still works as expected.

Host

• Wiped host: Re-enroll after wipe and confirm the account type is respected on re-setup.

User Permissions

• Premium vs. Free: This is a Premium-only feature. Verify Free users get a clear error message when attempting to set it via API.
• Global user roles (Admin, Maintainer, Observer, Observer+, API only): Verify only admins can change the account type setting.
• Team-level user roles: Same permission checks at the team level.

Config

• Fleet (Team) operations:
  • Create team:
    • Set account type to "standard" at team creation; confirm it persists.
    • Set account type to "none" at team creation; confirm it persists.
  • Transfer host to/from team: Host moves between teams with different account types; verify next DEP enrollment uses the correct team's setting.
  • Unassigned:
    • Confirm the no-team (app-level) config also supports "standard".
    • Confirm the no-team (app-level) config also supports "none".
  • Validate that account type is respected whether the host is on a team or unassigned. Test setup with both

Accessibility

• Keyboard accessibility: The new account type selector (dropdown/radio) should be navigable via keyboard.

UI

• Verify that all UI changes specified in the Figma wireframes are correctly implemented
• Verify expected UI states (loading, empty, error states if applicable)
• Empty states: If end_user_local_account_type is not set, confirm the default ("admin") is displayed correctly.
• Error states: Test submitting an invalid end_user_local_account_type value (e.g., "foo") via API and UI. Verify clear error messages (client-side and server-side).
• Confirm if Standard/Skip is selected:
  • "create hidden admin" is auto selected and disabled
  • if you deselect standard/skip and pick admin, revert to previous settings for "create hidden admin"

API

• Test all API endpoints added or modified in the API changes section of this issue
• Verify error handling for invalid inputs where applicable
• If standard/skip is selected, we want to force user to also enable the "create hidden admin".
• Test with fleet and unassigned

GitOps (generate + run)

• SKIP THIS(Unless gitops-generate now includes setup_experience info) Confirm the generated .yml includes the expected fields (compare with YAML changes in the Product section)
• Modify the generated .yml and run fleetctl gitops
• Confirm the configuration updates correctly in Fleet
• Enable GitOps mode and verify the feature behaves correctly
• Disable certain actions with GitOps mode tooltip: When GitOps mode is active, all options should be disabled with standard GitOps tooltip.
• Test with fleet and unassigned
• Copy changes:
  • Verify end_user_local_account_type: "standard" round-trips correctly through fleetctl apply.
  • Verify end_user_local_account_type: "none" round-trips correctly through fleetctl apply.

Permissions

• Verify role restrictions are applied correctly for global roles
• Verify role restrictions are applied correctly for fleet-level roles

Edge cases

• Does this test make sense?: If the end user is a standard user and prompted to enable FileVault on a device with an invisible admin, confirm the key can not be used to reset the password of any account on the device, including the invisible admin.

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.