<!-- Add the related story/sub-task/bug number, like Resolves#123, or
remove if NA -->
**Related issue:** Resolves#49655
Documentation-only change. No server behavior changes.
## What's happening
On a personally-owned work profile (BYOD), Android applies the biometric
values of `keyguardDisabledFeatures` to the work profile lock. By
default the end user has one lock for both the work profile and the host
("Use one lock"), so there is no separate work profile lock to restrict,
and Android restricts the host's lock instead. Fingerprint and face
unlock turn off for the whole host, including the end user's personal
apps.
This is documented Android behavior, per
[`setKeyguardDisabledFeatures`](https://developer.android.com/reference/android/app/admin/DevicePolicyManager#setKeyguardDisabledFeatures(android.content.ComponentName,%20int)):
> `KEYGUARD_DISABLE_FINGERPRINT`, `KEYGUARD_DISABLE_FACE` or
`KEYGUARD_DISABLE_IRIS` which affects the managed profile challenge if
there is one, **or the parent user otherwise**.
Fleet never sets `keyguardDisabledFeatures` itself. Fleet's default
Android policy sets only `StatusReportingSettings`, and admin-authored
AMAPI policy is passed through as-is. The reason this still lands on
Fleet is that the profile in the bug report is byte-for-byte the example
Fleet publishes at
`docs/solutions/android/configuration-profiles/disable-face-and-biometrics-unlock.json`,
with no note about the BYOD side effect.
## What changed
- `articles/custom-os-settings.md`: new "Biometric unlock on
personally-owned (BYOD) hosts" subsection under "Special Android
behavior", covering the behavior and the configuration that scopes the
restriction to work.
- `docs/solutions/android/configuration-profiles/README.md`: entries for
the biometrics profile (carrying the caveat) and for the new example.
-
`docs/solutions/android/configuration-profiles/require-separate-work-profile-lock.json`:
new example using `passwordScope: SCOPE_PROFILE` and
`unifiedLockSettings: REQUIRE_SEPARATE_WORK_LOCK`.
The remedy needs no Fleet change: `passwordPolicies` is already in the
Android policy field mask
(`server/mdm/android/service/androidmgmt/policy_field_mask_test.go`), so
Fleet already delivers it.
## Testing
- [ ] QA'd all new/changed functionality manually
Docs-only, so no automated tests were added. Verification done:
- Both the new example profile and the combined snippet in the guide
decode into the real `androidmanagement.Policy` struct with
`DisallowUnknownFields`, confirming every key and nesting level matches
the AMAPI schema Fleet ships.
- The documented status flow (`USER_ACTION` non-compliance on
`passwordPolicies` marks the profile "Failed", then "Verified" once the
end user sets the work lock) is confirmed against
`server/mdm/android/service/pubsub_test.go`.
**Not yet verified on hardware.** I have not run the repro on a physical
BYOD Android host. Before merge, this is worth confirming:
1. On a BYOD Android host with fingerprint unlock configured and a work
profile enrolled, apply `disable-face-and-biometrics-unlock.json`.
Confirm fingerprint disappears as an unlock method device-wide.
2. Add the `passwordPolicies` block from
`require-separate-work-profile-lock.json` to that profile and re-upload.
Confirm Android prompts for a separate work profile lock, and that Fleet
shows the profile "Failed" with `USER_ACTION` on **Host > OS settings**
until the end user sets it.
3. After the end user sets the work lock, confirm the profile moves to
"Verified", fingerprint unlock works again on the personal side, and the
work profile still requires PIN/password.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added an Android configuration profile option that requires a separate
lock for the work profile.
* Applies password policy settings specifically to the work profile
scope.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- Adds a **Target hosts with labels** section to the Configuration
profiles guide (`articles/custom-os-settings.md`).
- Documents the three targeting modes (**Include all**, **Include any**,
**Exclude any**), that only one can be used per profile, and that
profiles are inherently platform-scoped (no label needed to keep a
profile on the right platform).
- Shows the flow across Fleet UI, GitOps (`labels_include_all` /
`labels_include_any` / `labels_exclude_any`, with a YAML example), and
the Fleet API.
- Bumps `publishedOn` to the current date. Author unchanged.
## Why
Prospects and customers hit this gap when trying to scope a profile to a
subset of hosts: the label include/exclude syntax lived only in the YAML
and REST API reference docs, with no walkthrough in the guide.
## Test plan
- [ ] Article renders correctly on the fleetdm.com preview
- [ ] All links resolve
- [ ] Meta tags present with updated `publishedOn` date
- [ ] Style guide compliance verified
- `articles/custom-os-settings.md`: Added one sentence to the Windows
section: "For local testing on Windows,
[SyncMLViewer](https://github.com/okieselbach/SyncMLViewer/releases) is
a useful GUI tool for inspecting MDM traffic."
- `website/views/pages/os-settings.ejs`: Added a matching list item to
the Windows platform section on the `fleetdm.com/os-settings` page,
mirroring the iMazing mention in the Apple section.
- Main goal is to clarify "Verifying" v. "Verified" for user-scoped
Windows profiles
- Also reorganize/update the heading to improve the guides flow
- "user-scoped" and "device-scoped" get a hyphen
We had duplicate section for user scoped profiles.
Besides that, removed the section where we mention that we'll work soon
on #30043 as we decided that we'll document that it's necessary to
re-enroll manually enrolled hosts.
Related to:
- #30043
Related to #29322
docs for delivering config profiles to host user channels
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Documentation**
* Added detailed instructions for deploying certificates to a user's
login keychain on macOS devices.
* Introduced a new section explaining how user-scoped configuration
profiles are assigned, including behavior with multiple local users and
supported profile types.
* Improved formatting and clarified existing explanations for better
readability.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Adding additional information to the guide and
improving language to match what we're using in the product (instead of
"installed configuration profiles" -> "applied OS settings").
Document interim best practice for modifying OS settings. Later Fleet
might add an "Edit" button in the UI so the IT admin doesn't have to add
a new profile and then remove the old.
Rachael Shaw