azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

cascades: SDM activation root-caused, devices@ provisioning account created

Browse Source 
9-hour day on Cascades caregiver phone Shared Device Mode activation.
Root cause of repeated AADSTS50097 was missing Cloud Device Administrator
role -- pilot.test cannot self-register devices for shared mode. Created
dedicated devices@cascadestucson.com (CDA role, MFA on Howard's phone).
Final attempt on Phone A produced an Entra device record with shared-mode
markers (registeredOwners=0, registeredUsers=0). Resume tomorrow by
signing pilot.test in to verify SDM is actually active.

Side wins: ALIS SSO Entra App Registration created (vault commit 90ada33,
blocked on Medtelligent enabling App Store side); 2 of 3 caregiver CA
policies flipped from Report-only to Enforced; kiosk profile bumped to
v13 with full Android nav bar, 12hr inactivity signout, 6-app allowlist
including Company Portal.

Microsoft ticket #2605070040009774 still open.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Howard Enos
2026-05-07 18:38:37 -07:00
parent 6b3ae407bd
commit 9aab0dc35a
1 changed files with 261 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

261
clients/cascades-tucson/session-logs/2026-05-07-howard-cascades-phone-sdm-provisioning.md Normal file
View File

@@ -0,0 +1,261 @@
# Cascades — Caregiver phone provisioning + Microsoft Authenticator Shared Device Mode (SDM) activation
**Date:** 2026-05-07
**Client:** Cascades of Tucson (Syncro 20149445, Tenant `207fa277-e9d8-4eb7-ada1-1064d2221498`)
## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech
- **Session span:** ~9 hours, full day. Cascades follow-up review through phone provisioning attempts.
## Session Summary
Started with a Cascades-only follow-up audit to identify pending items, then spent the bulk of the day attempting Microsoft Authenticator Shared Device Mode (SDM) activation on Cascades caregiver phones. Multiple factory-reset cycles on two test phones (Samsung A14 5G — serials R9TW207FSXA and R92W310H31N), each time hitting `AADSTS50097 DeviceAuthenticationRequired` when pilot.test attempted to register the device for shared-device mode.
Through a comprehensive Entra/Intune configuration audit, identified the root cause: the **Cloud Device Administrator** role had ZERO members in the tenant. Microsoft's documented SDM activation flow requires a user with that role (or Global Admin, which is a superset) to perform the initial Workplace Join on each shared device. `pilot.test@cascadestucson.com` is a regular user with no directory roles, so its registration calls were correctly being rejected with 50097.
Created a dedicated provisioning account `devices@cascadestucson.com` with the Cloud Device Administrator role assigned, vaulted credentials, and registered Microsoft Authenticator MFA on Howard's own phone (Samsung F731). On the final phone-provisioning attempt of the day, signed in as `devices@` on phone R9TW207FSXA. The on-device "Register your device for passwordless sign-in" prompt completed without error — and the resulting Entra device record looks like a shared-device registration: `samsungSM-A146U`, `trustType=Workplace`, `registeredOwners=0`, `registeredUsers=0`. Devices@ does NOT appear in the device's owner/user arrays — that pattern is consistent with shared device mode, where no specific user "owns" the device.
Bug remaining: after Howard signed `devices@` out of Authenticator on Phone A, the account entry persists in Authenticator's account list and the remove option is now gone. We did not get to verify SDM by signing pilot.test in on the now-registered device. Resume there tomorrow.
In parallel: created the Entra App Registration for ALIS SSO (vaulted at `clients/cascades-tucson/alis-sso-app-registration.sops.yaml`), but ALIS App Store side is blocked — Medtelligent support contacted to enable the Entra SSO app on the Cascades ALIS tenant. Microsoft support ticket `#2605070040009774` is in flight after pushing back on the initial bot auto-response.
## Key Decisions
- **Cloud Device Administrator role is required for SDM activation** — confirmed via Microsoft's own SDM tutorial and reproduced by the audit finding. Going forward, any account performing first-sign-in on a fresh shared phone needs this role (or Global Admin).
- **Dedicated provisioning account, not Howard's `sysadmin@` or Mike's `admin@`.** Reason: scoped role (CDA, not GA — least privilege), distinct audit trail for "who provisioned which phones when", easy to disable after rollout completes, MFA target is Howard's own phone (not Mike's S25 Ultra) so Howard can do provisioning solo.
- **Disable account, don't delete, after rollout.** Preserves audit trail; devices stay in shared mode independent of activator account state.
- **Decline passkey + decline phone-as-passwordless prompts.** Per Microsoft SDM docs (https://learn.microsoft.com/entra/msal/android/shared-devices, last updated 2026-01-28), neither is part of the SDM flow. Accepting them on a shared device would create one orphan passkey per provisioned phone and tie the device to a specific user — the opposite of what shared mode needs.
- **Accept the "Register your device" prompt** even when worded "for passwordless sign-in" — the underlying mechanism is Workplace Join. With CDA role on the signing-in account, the call completes as shared-device registration (because the MSDM app config is in place). The "passwordless" wording is a UI artifact Microsoft hasn't updated.
- **Two of three caregiver CA policies flipped to Enforced.** `CSC - Block caregivers off Cascades network` and `CSC - Caregiver sign-in frequency 8h` are now `state=enabled`. The third (`CSC - Block caregivers on non-compliant device`) stays in Report-only because pilot.test's sign-ins still register `reportOnlyFailure` due to devices not being Workplace-Joined yet — flipping it now would lock pilot.test out entirely. Flip after SDM is verified working.
- **`devices@cascadestucson.com` will be disabled (not deleted) after all 32 phones are provisioned.**
- **Wallpaper deferred** until we have a public HTTPS URL for the provided Cascades-of-Tucson logo image. WordPress media library upload is the easiest path. Welcome screen logo (MHS app config) is deferred entirely — those keys (`welcome_screen_logo`, etc.) are speculative and were the source of an install/uninstall app loop earlier in the day.
## Problems Encountered
- **AADSTS50097 on pilot.test SDM activation attempts** — root cause: regular user accounts can't register devices for shared mode. Fixed by introducing devices@ with CDA role.
- **MHS app config with speculative keys (`welcome_screen_logo`, `show_sign_in_button`, `set_screen_orientation`) caused an install/uninstall loop on every required app** — the MHS app rejected the whole managed-config payload because of one or more invalid key types, which triggered Intune to retry deployment by uninstall+reinstall, repeatedly. Loop affected Edge, Outlook, Teams, MHS — all the apps. Deleted the bad app config; loop stopped within 1-2 sync cycles. Lesson: when pushing MHS app config in the future, ONLY use `web_apps` (the well-documented key) until we have a successful baseline; layer other keys on one at a time.
- **Sent the wrong enum value `enabled` for `kioskCustomizationSystemNavigation`** — correct value is `navigationEnabled`. Should have looked up the schema first. Fixed in v12 of the device-restrictions profile.
- **Authenticator account-removal UI is locked on Android Enterprise dedicated devices** — kiosk hides the path. Workaround was full factory reset multiple times. Phone now has devices@ stuck in the account list with no removal option after sign-out — pending tomorrow's session to determine if this is OK (account list shows the SDM-registered admin even when not signed in) or whether it needs another wipe.
- **Duplicate Intune device records** appeared after manual factory reset (without admin-issued wipe), causing app install/uninstall fights between two records claiming the same physical phone. Cleaned up by deleting the older record (the one with earlier `lastSyncDateTime`). Going forward, always use admin-issued wipe (`POST /managedDevices/{id}/wipe`) rather than asking the user to factory-reset manually so old records get torn down properly.
- **Microsoft sent a bot auto-response** to ticket #2605070040009774 with unrelated documentation links (AD sync guides, Android enrollment troubleshooting). Pushed back with explicit correlation IDs and the specific 50097 / Workplace Join failure scenario. The follow-up response was substantive (confirmed CDA role requirement, asked about joinType state) — that's what put us on the right track.
- **Phone B (R92W310H31N) had Wi-Fi/setup issues** during one of the enrollment cycles — required a manual factory reset by Howard. Resolved.
## Configuration Changes
### New Entra account
- **`devices@cascadestucson.com`** (id `aaca80c6-861b-4294-8068-1033c68d7667`) — cloud-only, US, no license, password `Gptf*77ttb!`, **Cloud Device Administrator** role assigned. MFA: Microsoft Authenticator on Howard's Samsung F731. Vaulted at `clients/cascades-tucson/devices-account.sops.yaml` (vault commit `1663a5d`).
### New Entra App Registration
- **Cascades of Tucson - ALIS SSO** (App ID `d5108493-cba8-4f08-90b6-1bb0bc09eb2a`, Object ID `0d5ba4e5-79d6-49ee-a04c-decd2d27644d`) — single-tenant OIDC App Registration per Medtelligent's setup doc. Redirect URI `https://cascadestucson.alisonline.com/ExternalLoginCallback`, ID tokens implicit/hybrid enabled, client secret expires 2028-05-06. Vaulted at `clients/cascades-tucson/alis-sso-app-registration.sops.yaml` (vault commit `90ada33`). **Pending Medtelligent enabling the Entra SSO app on the Cascades tenant of their App Store** before we can paste in the three values (Directory ID, App ID, secret).
### Cascades device-restrictions profile (`CSC - Android Shared Phones Restrictions`, id `070a76c2-a8c3-4f7f-9ba7-1f4ac5084184`)
Bumped from version 8 to version 13 across multiple PATCHes today.
- **kioskModeApps** restored from 3 entries (Authenticator, Outlook, Teams) to **6** (added Edge `com.microsoft.emmx`, Managed Home Screen `com.microsoft.launcher.enterprise`, Intune Company Portal `com.microsoft.windowsintune.companyportal`)
- **kioskModeManagedHomeScreenInactiveSignOutDelayInSeconds**: 600 -> **43200** (12 hr — full caregiver shift)
- **kioskModeManagedHomeScreenInactiveSignOutNoticeInSeconds**: 60 -> **300** (5 min warning)
- **kioskCustomizationSystemNavigation**: null -> **`navigationEnabled`** (full Android nav bar — back/home/recents)
- **kioskCustomizationStatusBar**: null -> **`notificationsAndSystemInfoEnabled`** (notifications + status visible)
- **kioskCustomizationDeviceSettingsBlocked**: null -> **`false`** (Settings access permitted — note: still kiosk-restricted via other settings)
- **kioskCustomizationPowerButtonActionsBlocked**: null -> **`false`**
- **kioskCustomizationSystemErrorWarnings**: null -> **`true`**
- **kioskModeVirtualHomeButtonEnabled**: false -> true -> **false** (added then removed; redundant with full nav bar)
### Conditional Access policy state changes (caregiver-scoped only)
- **`CSC - Block caregivers off Cascades network`** (`e35614e1-e896-4a13-9407-076963af488f`) — Report-only -> **enabled**
- **`CSC - Caregiver sign-in frequency 8h`** (`7d491c7a-ad90-4420-9990-40a1e676a76c`) — Report-only -> **enabled**
- **`CSC - Block caregivers on non-compliant device`** (`ede985e2-ee7e-4521-88b2-34c847c3db20`) — **kept Report-only** because Report-only logs showed `reportOnlyFailure` on every legitimate sign-in (devices aren't Workplace-Joined yet, so `device.isCompliant` doesn't evaluate true even for Intune-compliant devices). Flip after SDM is verified.
### Microsoft Shared Device Mode (MSDM) app configurations
- **No changes** to existing Authenticator MSDM config (`a1bfbda0-a36c-45e5-8844-8470f80ecc8d`) or Teams MSDM config (`3c6a354c-1616-434b-ac81-4dad7795e67b`) — both correct, both reporting compliant on test phones.
- **Created and then DELETED** `CSC - MHS Web Shortcuts and Branding` (was `af55951a-fba9-4f56-b34d-80de5e367ebc`) due to install/uninstall app loop caused by speculative MHS keys. Will recreate carefully tomorrow with **only the documented `web_apps` key**.
- **Created and then DELETED** `CSC - Microsoft Shared Device Mode (Outlook)` (was `d0acc9ae-ee74-4aa5-90ac-7928100572cb`) — collateral cleanup during the install-loop debugging. Schema was actually correct; can recreate later if we want Outlook to participate in shared sign-out.
### Pilot.test session revocation
- Issued `POST /users/43919c7b-638c-4d38-9f94-89c1d07ce724/revokeSignInSessions` early in the day to clear stale tokens after diagnostic work. (HTTP 200, returned `{"value":true}`.)
### Test phones state at end of session
| Serial | Intune ID | Status | Notes |
|---|---|---|---|
| R9TW207FSXA | new id (post-final-enrollment) | Compliant, Auth+Teams MSDM compliant | devices@ signed in to Authenticator, then signed out, account stuck in account list |
| R92W310H31N | new id (post-final-enrollment) | Compliant, MSDMs intermittent | Not progressed beyond MHS — pending tomorrow |
Both phones are physically with Howard.
### Cleanup actions taken
- Multiple wipes (4-5 cycles) of the test phones throughout the day.
- Final cleanup at end of day: wiped both test phones AND deleted their Intune records (POST wipe + DELETE on each).
- Identified one Entra device record left over from the day's failed SDM attempts: `31fb90e5bbc239ba_AndroidEnterprise_5/8/2026_12:12 AM` — needs manual portal deletion (Tenant Admin SP returns 403 on Entra device DELETE, lacks Device.ReadWrite.All scope). **Howard's personal phone `samsungSM-F731U` (Workplace registered 2026-02-12) is NOT to be touched.**
## Commands & Outputs
### Cloud Device Administrator role members (the smoking gun)
```bash
TOK=$(bash .claude/skills/remediation-tool/scripts/get-token.sh 207fa277-e9d8-4eb7-ada1-1064d2221498 tenant-admin | tail -1)
# Find Cloud Device Administrator role
curl -sk -H "Authorization: Bearer $TOK" "https://graph.microsoft.com/v1.0/directoryRoles" | \
jq -r '.value[] | select(.displayName == "Cloud Device Administrator") | .id'
# Returned: bf3e8fe6-b146-45b2-949c-b72dbf1a1cfa
# Members?
curl -sk -H "Authorization: Bearer $TOK" "https://graph.microsoft.com/v1.0/directoryRoles/bf3e8fe6-.../members" | \
jq '.value[] | .userPrincipalName'
# Returned: empty array
```
### Create devices@ + assign CDA role
```bash
# Create user
curl -sk -X POST -H "Authorization: Bearer $TOK_UM" -H "Content-Type: application/json" \
--data '{"accountEnabled":true,"displayName":"Devices Provisioning Account","mailNickname":"devices","userPrincipalName":"devices@cascadestucson.com","usageLocation":"US","passwordProfile":{"password":"Gptf*77ttb!","forceChangePasswordNextSignIn":false}}' \
"https://graph.microsoft.com/v1.0/users"
# Returned: id aaca80c6-861b-4294-8068-1033c68d7667
# Assign Cloud Device Administrator role
curl -sk -X POST -H "Authorization: Bearer $TOK_TA" -H "Content-Type: application/json" \
--data '{"@odata.id":"https://graph.microsoft.com/v1.0/directoryObjects/aaca80c6-861b-4294-8068-1033c68d7667"}' \
"https://graph.microsoft.com/v1.0/directoryRoles/bf3e8fe6-b146-45b2-949c-b72dbf1a1cfa/members/\$ref"
# HTTP 204
```
### CA policy state flip (2 of 3 caregiver policies)
```bash
for ID in e35614e1-e896-4a13-9407-076963af488f 7d491c7a-ad90-4420-9990-40a1e676a76c; do
curl -X PATCH -H "Authorization: Bearer $TOK_TA" -H "Content-Type: application/json" \
--data '{"state":"enabled"}' \
"https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies/$ID"
# HTTP 204 each
done
# Then re-read after 6+ second sleep (eventual consistency window).
```
### SDM activation result on Phone A (R9TW207FSXA)
After `devices@` signed in to Authenticator and tapped Register on the "register your device for passwordless sign-in" prompt:
```bash
# Entra device record check
curl -sk -H "Authorization: Bearer $TOK_TA" "https://graph.microsoft.com/v1.0/users/aaca80c6-861b-4294-8068-1033c68d7667/registeredDevices"
# Returned:
{
"displayName": "samsungSM-A146U",
"operatingSystem": "Android",
"registrationDateTime": "2026-05-08T01:26:51Z",
"trustType": "Workplace",
"deviceId": "b040511b-1d5a-493d-9997-a8070a79a3cf"
}
# Full device detail
curl -sk -H "Authorization: Bearer $TOK_TA" "https://graph.microsoft.com/beta/devices?\$filter=deviceId eq 'b040511b-...'"
# Key fields:
# profileType: "RegisteredDevice"
# trustType: "Workplace"
# registeredOwners: 0 <- SDM marker (no specific owner)
# registeredUsers: 0 <- SDM marker (no specific user)
```
### MSDM compliance polling script (`Monitor` task pattern)
```bash
# Polls every 5 min, exits when both Auth + Teams MSDM are compliant on both phones.
# Saved as a recipe for future use.
TENANT="207fa277-e9d8-4eb7-ada1-1064d2221498"
AUTH_CFG="a1bfbda0-a36c-45e5-8844-8470f80ecc8d"
TEAMS_CFG="3c6a354c-1616-434b-ac81-4dad7795e67b"
# (Full script in monitor task bzwzt1wpw — referenced in resume notes below.)
```
## Pending / Incomplete Tasks
### Resume tomorrow (high priority)
- [ ] **Verify SDM is actually active on Phone A** by attempting to sign in pilot.test on it.
- Phone A: serial R9TW207FSXA, samsungSM-A146U, Android 15, Entra device id `b040511b-1d5a-493d-9997-a8070a79a3cf`, registered 2026-05-08T01:26:51Z
- Open Authenticator on Phone A. Even if devices@ is "stuck" in the account list with no remove option, that may be the SDM admin marker — try signing in pilot.test as a SECOND account (if Authenticator allows) or via the MHS welcome-screen sign-in path.
- Success criteria: pilot.test signs in WITHOUT 50097, no "register device" prompt (because device is already SDM-registered), Teams + Outlook silent-sign-in via broker.
- [ ] **If pilot.test sign-in on Phone A succeeds → SDM is confirmed working.** Document the per-phone provisioning playbook and start Phone B + remaining 30 phones.
- [ ] **If pilot.test sign-in still fails 50097 on Phone A → SDM didn't actually activate.** Escalate Microsoft support ticket with the new diagnostic data (devices@ has CDA role and STILL didn't activate SDM; means the issue is deeper).
### Production phone rollout (after SDM is confirmed)
- [ ] Per-phone provisioning playbook: factory reset -> scan QR -> wait 15-20 min for apps + configs -> open Authenticator -> sign in as devices@ -> approve MFA push on Howard's phone -> tap Register on the "passwordless" prompt -> sign devices@ out -> phone ready for caregivers.
- [ ] Roll the playbook through the remaining 30 phones (32 total minus the 2 test phones already in hand).
- [ ] Decide if devices@ stays as a permanent provisioning account (re-enabled when adding/replacing phones) or is disabled after rollout. Default plan: disable, re-enable as needed.
### Cascades infrastructure follow-ups
- [ ] **Flip `CSC - Block caregivers on non-compliant device` from Report-only to enabled** once SDM is confirmed working (and Workplace Join has happened on enough phones that `device.isCompliant` evaluates true on legitimate sign-ins). Currently locks pilot.test out if flipped.
- [ ] **Wallpaper for phones** — upload the Cascades-of-Tucson portrait logo image (provided by Howard 2026-05-07, file `ChatGPT Image May 7, 2026, 02_33_33 PM.png`) to https://cascadestucson.com WordPress media library, capture the public HTTPS URL, then PATCH `kioskModeWallpaperUrl` on the device-restrictions profile.
- [ ] **MHS welcome-screen logo + web_apps tiles** — recreate the MHS app config with ONLY the documented `web_apps` key first (no speculative keys). Test on one phone before pushing tenant-wide. Revisit logo placement once stable.
- [ ] **Outlook MSDM app config** — recreate (was deleted as collateral during install-loop cleanup, but the schema was actually fine — `shared_device_mode_enabled=true` matching the Teams config).
- [ ] **Manually delete the orphan Entra device record** `31fb90e5bbc239ba_AndroidEnterprise_5/8/2026_12:12 AM` via portal (Entra → Devices → All devices → Delete). Do NOT touch Howard's `samsungSM-F731U`.
### ALIS SSO activation (blocked on vendor)
- [ ] **Medtelligent support callback** — they need to enable the Entra SSO app on Cascades' tenant of the ALIS App Store. Once enabled, paste the three values from the vault (Directory ID, App ID, Client Secret) into ALIS → App Store → Entra SSO app → Configure → Outbound Connections.
- [ ] After ALIS App Store install: set pilot.test's ALIS staff record Email to `pilot.test@cascadestucson.com` (must match Entra UPN exactly for SSO linking).
- [ ] Test ALIS SSO from a caregiver's signed-in session on a Cascades phone.
### Microsoft support ticket #2605070040009774
- [ ] **Update the ticket** with today's findings (CDA role identified as missing, devices@ created with CDA role, registration succeeds for devices@, joinType still showing unknown in Intune view but Entra has the registered device record).
- [ ] If pilot.test sign-in tomorrow confirms SDM works, **close the ticket** with a "this was the resolution" summary so it's documented for future reference.
## Reference Information
### Cascades tenant
- Tenant ID: `207fa277-e9d8-4eb7-ada1-1064d2221498`
- Default domain: `cascadestucson.com`
- Cascades named location: `061c6b06-b980-40de-bff9-6a50a4071f6f` (IPs: `72.211.21.217/32` + `184.191.143.62/32`, both trusted)
- Tenant Admin SP: `709e6eed-0711-4875-9c44-2d3518c47063`
- Intune Manager SP: `46986910-aa47-4e5e-b596-f65c6b485abb`
### Provisioning identity
- **`devices@cascadestucson.com`** (`aaca80c6-861b-4294-8068-1033c68d7667`)
- Role: Cloud Device Administrator (`bf3e8fe6-b146-45b2-949c-b72dbf1a1cfa`)
- Vault: `clients/cascades-tucson/devices-account.sops.yaml`
- MFA: Microsoft Authenticator on Howard's Samsung F731 (Entra device `2dfb6dbe-a552-4822-b19b-399bdb676cd6`)
### Pilot identity (caregiver test)
- **`pilot.test@cascadestucson.com`** (`43919c7b-638c-4d38-9f94-89c1d07ce724`)
- Group: SG-Caregivers-Pilot (`0674f0bc-6ff4-49c7-802d-2abf591ba371`) — 1 member (pilot.test)
- Vault: `clients/cascades-tucson/pilot-test-user.sops.yaml`
- License: Microsoft 365 Business Premium (SPB)
### Phone identifiers
- **Enrollment profile:** `CSC - Android Shared Phones`, id `3345721a-d9c3-4c79-9b3a-5c5e68849a9f`, token expires 2026-06-23
- **Dynamic group:** `Cascades - Shared Phones` (`ea96f4b7-3000-45da-ab1f-ddb28f509526`), rule `(device.enrollmentProfileName -eq "CSC - Android Shared Phones")`
- **Models:** Samsung Galaxy A14 5G / A15, model SM-A146U, Android 15
### Microsoft documentation referenced
- Android SDM: https://learn.microsoft.com/en-us/entra/msal/android/shared-devices (last updated 2026-01-28)
- Combined registration / authentication methods: tenant policy at `https://graph.microsoft.com/beta/policies/authenticationMethodsPolicy`
- ALIS Entra SSO setup: https://support.alisonline.com/hc/en-us/articles/34831696021901
### Vault paths (this session)
- `clients/cascades-tucson/devices-account.sops.yaml` — provisioning account (NEW today)
- `clients/cascades-tucson/alis-sso-app-registration.sops.yaml` — ALIS Entra app reg (NEW today)
- `clients/cascades-tucson/pilot-test-user.sops.yaml` — pilot test user
- `clients/cascades-tucson/cs-server.sops.yaml` — domain controller
- `clients/cascades-tucson/wifi-cscnet.sops.yaml` — Wi-Fi PSK
### Microsoft support ticket
- **Ticket #2605070040009774** — "Microsoft Authenticator Shared Device Mode failing to activate on Android Enterprise Dedicated devices — AADSTS50097 on Workplace Join"
- Initial response was the bot auto-response (unrelated AD sync articles). Pushed back with correlation IDs.
- Substantive response on second exchange — Microsoft engineer asked about joinType state and confirmed CDA role requirement. That answer led to today's fix.
## Note for Mike
**Today was a hard day on the phone rollout but ended on the strongest signal we've had that SDM activation works.** The reason every prior attempt failed (including the two production rollout attempts on 4/29-4/30) was that we were having `pilot.test` (a regular caregiver-tier user) try to perform a function that requires Cloud Device Administrator role. Microsoft's documentation says this requirement explicitly — neither of us had caught it.
The new `devices@cascadestucson.com` account is built specifically for this — Cloud Device Administrator role only (NOT Global Admin, by design — least privilege), MFA on Howard's phone, vaulted credentials. After we verify it works tomorrow on a clean attempt, the per-phone provisioning takes about 5 minutes. Howard can roll the playbook through the remaining 30 phones across a few sessions over the next week without you needing to be involved.
Two things that might be relevant to your next strategy call:
1. **The Microsoft-support journey was educational.** The auto-response was generic, but their second exchange asked the right diagnostic question (joinType + "intentionally configured for shared mode") and that's what led to identifying the CDA role gap. Worth knowing as a baseline for how their support handles SDM cases.
2. **The CA policy enforcement is now real for caregivers.** `Block off-Cascades network` and `8h sign-in frequency` are both Enforced (not Report-only). Pilot.test cannot sign in from anywhere except the Cascades public IP. Once SDM is verified working tomorrow, we'll flip the third (`Block on non-compliant device`) and the security perimeter is fully operational.
ALIS SSO is still blocked on Medtelligent enabling the Entra SSO app on the Cascades tenant of their App Store. The Entra side (App Registration, secret, vault) is fully done — three values just need to be pasted in once Medtelligent acts.
---
**Session duration:** ~9 hours (2026-05-07 ~10:00 PT through 18:35 PT)
**End-of-day phone state:** Both test phones (R9TW207FSXA, R92W310H31N) physically with Howard, both wiped + deleted from Intune at end of session for clean tomorrow start. Phone A reached the most-likely-SDM-active state (samsungSM-A146U Entra device record with `registeredOwners=0` `registeredUsers=0` — shared-device markers).
**Resume:** Sign in pilot.test on a freshly-provisioned phone tomorrow to verify the SDM activation path actually works end-to-end.