diff --git a/clients/cascades-tucson/session-logs/2026-06-05-session.md b/clients/cascades-tucson/session-logs/2026-06-05-session.md index 35c6159..99e8507 100644 --- a/clients/cascades-tucson/session-logs/2026-06-05-session.md +++ b/clients/cascades-tucson/session-logs/2026-06-05-session.md @@ -128,3 +128,31 @@ Test attempts: pilot.test authenticated fine but ALIS was blocked by Conditional - Allow-list policy `1b7fd025-1aad-47c8-9274-c32c3e0b163c`; off-network block `e35614e1-...`; compliance-block `ede985e2-...`; sign-in-freq `7d491c7a-...`. - ALIS app `d5108493-cba8-4f08-90b6-1bb0bc09eb2a`; admin-consent grant `reTK4etbykSC1ENMm9g1rTplOyzgVClCofKDVRrn-ds`. - devices@ `aaca80c6-861b-4294-8068-1033c68d7667`. Threat model confirmed with Howard: remote credential abuse (hacker / bad employee from home) — fully blocked by the off-network + device allow-list CA (stolen caregiver creds unusable off-site/off-device). + +--- + +## Update: 12:17 MST — Core test PROVEN; enrollment blocked on Intune license provisioning + +### Result +**The caregiver restricted-access model is proven end-to-end on a desktop.** pilot.test signed into NURSESTATION-PC, and **ALIS opened via Microsoft SSO**, with the lockdown holding (off-network blocked, only allow-listed device passes). That was the goal. + +### How ALIS finally passed +First attempts threw CA **AADSTS53003** (allow-list block) even though NURSESTATION was tagged `CSCCaregiverDevice`, on a trusted IP (184.191.143.62), with the device claim flowing correctly (deviceId e16c4af5, Azure AD joined, valid PRT). Root cause: **device extensionAttribute changes take a long time (>70 min here) to propagate into CA's device-filter cache.** Fix: added NURSESTATION's **intrinsic deviceId directly to the allow-list rule** (policy changes propagate in minutes; deviceId isn't subject to the attribute cache) — ALIS then worked immediately. **Takeaway:** for the small caregiver device set, matching by **deviceId** in the allow-list is the reliable, lag-free lever; the `extensionAttribute1` tag is fine but slow to take effect. + +### Open blocker: Intune enrollment (license provisioning) +NURSESTATION is Entra-joined but won't Intune-enroll. Walked it down with `dsregcmd /status`: device healthy, AzureAdPrt YES, but **`MdmUrl` blank**. Confirmed MDM user scope = Some -> `SG-Intune-Enrollment` (correct) and devices@ is a member (correct). **Actual root cause:** the **Intune service plan on the enrolling account is not provisioned** — `INTUNE_A: PendingInput` on both newly-licensed accounts (devices@ AND pilot.test), while established users (Megan) are fine. A device cannot enroll through an account whose Intune plan isn't active. Re-kicked the Business Premium license on devices@ (remove + re-add; first re-add 409'd and was retried to 200 — confirmed SPB back on the account). `INTUNE_A` still `PendingInput` immediately after — provisioning takes time. Re-check in 20-30 min. + +### Windows Hello prompt (still showing) +The "set up Windows Hello" prompt persisted on pilot.test despite the local reg key (`PassportForWork\Enabled=0`) and reboots — I was wrong that a reboot would fix it. Fact: **tenant WHfB enrollment policy = `notConfigured`**, so Windows applies its default (WHfB ON) on Entra-joined devices, and the generic reg key doesn't reliably override it. The clean, scoped fix is the **Intune disable-Hello profile** (already built, assigned to Cascades - Caregiver Devices) — which applies once the device is Intune-enrolled. The prompt is dismissible, so it didn't block the test. Tenant WHfB left untouched so office users keep PIN + Authenticator (their offsite 2FA preserved). + +### Config changes (live) +- Allow-list policy `1b7fd025` rule now: `(device.displayName -startsWith "CSC-") -or (device.extensionAttribute1 -eq "CSCCaregiverDevice") -or (device.deviceId -eq "e16c4af5-cb0e-49e1-90be-674a216f5e9c")` (mode exclude). +- devices@ Business Premium license removed + re-added (kick Intune provisioning). SPB confirmed re-present. + +### Pending (updated) +- [ ] Re-check `devices@` `INTUNE_A` -> Success (re-check ~20-30 min after 12:17 MST). Once Success: reboot NURSESTATION -> auto-enrolls -> disable-Hello + idle-lock apply. +- [ ] If still `PendingInput` after a while: tenant new-license Intune activation issue (both new accounts affected) — may need more time / MS support; does NOT block the working caregiver access. +- [ ] After enrollment: drop the local WHfB reg hack; build Shared PC Mode in portal (assign to Cascades - Caregiver Devices). +- [ ] Howard: confirm pilot.test ALIS staff Email = `pilot.test@cascadestucson.com` (ALIS resolved it this session, so likely set). +- [ ] Promote rule set to `SG-Caregivers` (all 38 + Feller/Nyanzunda); for devices, prefer **deviceId matching** in the allow-list (reliable) — collect the 6 caregiver-device deviceIds. Then disable compliance-block + clean up test artifacts (pilot.test, test group). +- [ ] LESSON: check Intune license provisioning (`INTUNE_A = Success`) before troubleshooting enrollment; CA device-filter extensionAttribute changes lag (use deviceId for immediacy). diff --git a/wiki/clients/cascades-tucson.md b/wiki/clients/cascades-tucson.md index 3c697f9..75fe842 100644 --- a/wiki/clients/cascades-tucson.md +++ b/wiki/clients/cascades-tucson.md @@ -226,7 +226,7 @@ Senior living / assisted living facility in Tucson, AZ. Single 6-floor building - **User<->computer map source:** Syncro `kabuto_information.last_user` (GuruRMM does not expose logged-in user). DuPras=ALASSIST-PC, Lois Lane=DESKTOP-KQSL232, Karen Rossini=DESKTOP-LPOPV30, shared medtech=ASSISTNURSE-PC, shared MemCare reception=MEMRECEPT-PC (excluded from caregiver allow-list, receptionist-only). CONTEXT.md GuruRMM roster stale (27->32) — refresh pending. - **Caregiver desktop app shortcuts:** ALIS (`https://cascadestucson.alisonline.com`), LinkRx (`https://pharmcare.linkrxnow.com/`), HelpAny (`https://app.safe-living.com/login`) — deploy via a Public-Desktop PowerShell script launching Edge `--app` mode (preserves SSO device-claim), pushed via GuruRMM to the 6 caregiver machines. - **Login UX:** Entra/Microsoft sign-in (and ALIS SSO) requires the full UPN — no bare-username option for cloud accounts. Minimize typing via Windows Hello PIN on laptops + silent ALIS SSO once signed in; pursue ALIS Login PINs (Medtelligent limited-release). - - **Caregiver test rig (2026-06-05, in progress):** Phased-test infra before promoting to all caregivers. `SG-Caregivers-DeviceTest` (`db5849ec`, USERS) carries the full caregiver rule set (off-network block + sign-in-freq + allow-list, excluded from compliance-block); `Cascades - Caregiver Devices` (`02c6f698`, STATIC devices) targets Intune profiles (NURSESTATION only for now); `SG-Intune-Enrollment` (`13d94f6e`, holds devices@) scopes MDM auto-enroll. Test acct `pilot.test@cascadestucson.com` (`d26e0e5a`, Business Premium, ephemeral). Intune profiles on the device group: idle-lock 5min + disable-WHfB (OMA-URI); Shared PC Mode deferred to portal. NURSESTATION-PC un-joined domain + Entra-joined (Win11 25H2) + tagged, NOT yet Intune-enrolled (MDM scope is a portal toggle). **Open:** test ALIS sign-ins blocked CA 53003 = device-tag propagation lag (device claim flowed, trusted IP) — retry after propagation. Windows shared-device UX differs from phone SDM and is NOT yet proven. Promotion: point allow-list at SG-Caregivers + disable compliance-block once validated. + - **Caregiver test rig (2026-06-05, in progress):** Phased-test infra before promoting to all caregivers. `SG-Caregivers-DeviceTest` (`db5849ec`, USERS) carries the full caregiver rule set (off-network block + sign-in-freq + allow-list, excluded from compliance-block); `Cascades - Caregiver Devices` (`02c6f698`, STATIC devices) targets Intune profiles (NURSESTATION only for now); `SG-Intune-Enrollment` (`13d94f6e`, holds devices@) scopes MDM auto-enroll. Test acct `pilot.test@cascadestucson.com` (`d26e0e5a`, Business Premium, ephemeral). Intune profiles on the device group: idle-lock 5min + disable-WHfB (OMA-URI); Shared PC Mode deferred to portal. NURSESTATION-PC un-joined domain + Entra-joined (Win11 25H2) + tagged, NOT yet Intune-enrolled (MDM scope is a portal toggle). **PROVEN 2026-06-05:** pilot.test on NURSESTATION-PC -> ALIS opened via SSO with lockdown holding (off-network blocked, only allow-listed device passes). ALIS first threw CA 53003 because the `extensionAttribute1` tag takes >70 min to propagate into CA's device-filter cache; fixed by adding NURSESTATION's **deviceId** directly to the allow-list rule (immediate, lag-free) — for the small caregiver device set, **deviceId matching is the reliable lever**. **Open:** Intune enrollment blocked — `INTUNE_A` service plan is `PendingInput` (not provisioned) on the newly-licensed accounts (devices@, pilot.test); established users fine. A device can't enroll through an account whose Intune plan isn't active. Re-kicked devices@'s Business Premium license to force re-provisioning; re-check for `Success`. Until enrolled, the scoped disable-Hello/Shared-PC profiles can't apply (Hello prompt is dismissible meanwhile; tenant WHfB left `notConfigured` so office users keep PIN+Authenticator). Windows shared-device UX differs from phone SDM. Promotion: once enrolled+validated, point allow-list at SG-Caregivers (prefer deviceId list) + disable compliance-block. - **Threat model (confirmed 2026-06-05):** off-network + device allow-list specifically defeats remote credential abuse (hacker / bad employee from home) — stolen caregiver creds unusable off-site/off-device because CA blocks the cloud sign-in before ALIS/email. Risk-based MFA policies are inert (tenant has no Identity Protection P2 license). - **GDAP exclusion:** CA policy 3 must exclude "Service provider users" (GDAP foreign principals) + `SG-External-Signin-Allowed` + `SG-Break-Glass`, otherwise ACG partner admins lose access at CA cutover. - **Pilot cleanup required when done:** Delete `pilot.test@cascadestucson.com`, clean up `howard.enos@cascadestucson.com`, remove `SG-Caregivers-Pilot` from CA policy targets and delete the group. Source: `project_cascades_pilot_cleanup.md`.