session: Cascades phone verification & closeout — Entra Connect staging exited, CA policies re-pointed to AD-synced SG-Caregivers

- Full tenant verification sweep: all Intune/Entra objects match session logs
- Entra Connect staging mode exited; 17 AD groups synced to cloud
- CA policies (Block-off-network, Sign-in-frequency-8h, Block-non-compliant) patched from SG-Caregivers-Pilot to AD-synced SG-Caregivers
- Registration Campaign exclusion updated to SG-Caregivers
- Deleted test accounts: howard.enos (AD) and pilot.test (M365)
- Documented Christine Nyanzunda collision risk, Ederick Yuzon open item, standing security-group rule
- Session log written

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.claude/memory/MEMORY.md

@@ -40,6 +40,7 @@
 - [SQL instance role — verify by connections, not name](feedback_sql_instance_role_by_connection.md) — Standard installed under default `SQLEXPRESS` instance name is real. Prove role with `sys.dm_exec_sessions` + `Get-NetTCPConnection -OwningProcess` before recommending stop/uninstall. IMC1 2026-05-05/06 near-miss.
 - [Syncro — confirm appointment owner explicitly](feedback_syncro_appointment_owner.md) — When creating tickets with appointments, always ask "who is the appointment owner?" in the preview. Don't auto-default to ticket's assigned tech. Don't add additional attendees without explicit confirmation. Howard caught on Kittle ticket #32263 2026-05-08.
 - [Clear-RecycleBin fails silently as SYSTEM](feedback_clear_recyclebin_system_context.md) — RMM-dispatched cleanup scripts cannot use `Clear-RecycleBin -Force`; the cmdlet uses Shell COM and silently no-ops without an interactive desktop. Enumerate `C:\$Recycle.Bin\<SID>\*` directly. Hit on ASSISTMAN-PC 2026-05-08.
+- [Cascades — ask security group on user creation](feedback_cascades_user_security_group.md) — When creating any Cascades user, always ask which security group(s) they go in. Deliberate per-user decision; an OU→group auto-mirror was explicitly declined 2026-05-14. OU = sync scope; group = access/CA decision.
 
 ## Machine
 - [ACG-5070 Workstation Setup](reference_workstation_setup.md) - Windows 11 Pro clean install 2026-03-30, replaced CachyOS. All tools installed.

.claude/memory/feedback_cascades_user_security_group.md

@@ -0,0 +1,12 @@
+---
+name: cascades-user-security-group
+description: When creating or adding any Cascades user, always ask which security group(s) the account goes into — deliberate decision, never auto-derived from OU
+metadata:
+  type: feedback
+---
+
+When creating, or being asked to create, any Cascades user account (AD or M365), always ask the user **which security group(s)** the new account should be a member of. Include it explicitly in the creation preview/confirmation alongside name, UPN, and OU — do not assume it from the OU, department, or job title.
+
+**Why:** Howard explicitly declined an `OU=Caregivers` -> `SG-Caregivers` auto-mirror script (2026-05-14). Security-group membership controls what access and Conditional Access policies apply to a user; he wants that to stay a deliberate, reviewed decision per user, not automated away. OU placement is mechanical (it controls Entra Connect sync scope); group membership is an access-control decision and must be made consciously.
+
+**How to apply:** During any Cascades user-creation flow, ask "which security group(s)?" and confirm it in the preview. For caregivers specifically: the account goes in `OU=Caregivers` (for sync scope) AND must be deliberately added to `SG-Caregivers` (for CA policy coverage) — two separate, intentional steps, neither auto-derived from the other.

clients/cascades-tucson/CONTEXT.md

@@ -43,6 +43,15 @@ CA targeting consequences:
 - `SG-Break-Glass`: excluded from all CA (must add exclusion to every new policy)
 - ACG GDAP foreign principals: excluded from blocking policies via the "Service provider users" condition (Microsoft's CA UI), NOT via group membership
 
+## User onboarding — security group is a deliberate decision
+
+**Rule (2026-05-14):** When any Cascades user is created (AD or M365), the security group(s) they belong to must be **asked and decided explicitly** at creation time — never auto-derived from the OU, department, or title.
+
+- **OU placement** is mechanical — it controls whether the account syncs (Entra Connect scope). Caregivers go in `OU=Caregivers`.
+- **Security group membership** is an access-control decision — it controls what permissions and Conditional Access policies apply, and is reviewed/chosen per user.
+
+An `OU=Caregivers` -> `SG-Caregivers` auto-mirror script was considered and explicitly declined — the deliberate per-user review is the point. For caregivers: create in `OU=Caregivers` (sync) AND deliberately add to `SG-Caregivers` (CA coverage). Two separate, intentional steps.
+
 ## GuruRMM
 
 - Client: **Cascades of Tucson** (code `CASC`, id `42e1b0e3-f8b7-4fc5-86bd-06bdbb073b7f`)

clients/cascades-tucson/docs/cloud/caregiver-m365-p2-rollout.md

@@ -102,6 +102,7 @@ All UPNs above use the `@cascadestucson.com` suffix (standard).
 ## Conflict / verify before creating
 
 - **Christine Nyanzunda** — **Resolved 2026-04-22:** one person, one account. Existing `christine.nyanzunda@` mailbox covers both MC Admin role and her part-time Sun/Mon MedTech shifts. Do not create a second account.
+  - **SYNC WATCH-POINT (added 2026-05-14):** Verified this date — she has a cloud-only M365 account `christine.nyanzunda@cascadestucson.com` (`onPremisesSyncEnabled: null`, created 2023-10-26) and an existing AD account `Christine.Nyanzunda` that lives in a *departmental* OU (not `OU=Caregivers`). When caregiver AD accounts are created in `OU=Caregivers`, **do NOT create a `christine.nyanzunda` object there** — a duplicate inside the synced OU would soft-match/collide with her existing cloud account once Entra Connect staging is exited. Her existing account stays untouched by the `OU=Caregivers`-only caregiver sync. Deciding whether/how to move or sync her belongs to the office-staff (Phase 2) migration, NOT the caregiver phone rollout.
 - **Paty Doran** — **Resolved 2026-04-22:** legal name `Patricia Camarena Doran`. Account will be `patricia.doran@`.
 - **Polett Pinazavala** — **Resolved 2026-04-22 (John's reply): departed.** Remove from roster. No AD/M365 account exists so no disable needed.
 - **Patricia Sandoval-Beck** — **Resolved 2026-04-22 (CSV inline note from Meredith):** hyphen is correct. SamAccountName may still need to be `Patricia.SandovalBeck` if ALIS/MDM reject hyphens — test during Wave 3.
@@ -158,11 +159,14 @@ CA policies should be deployed in **Report-only** mode for at least 7 days, revi
 
 ## AD placement (when accounts are created)
 
-Put caregivers in the existing `OU=Departments,OU=...` department OUs:
+**All caregiver accounts go in `OU=Caregivers,OU=Departments,DC=cascades,DC=local`** — this is the OU in the Entra Connect sync scope (confirmed 2026-05-14). Do NOT place caregivers in `OU=Care-Assisted Living` / `OU=Care-Memorycare` — those hold office/clinical staff and are NOT in the sync scope; putting caregivers there means they either don't sync or you'd have to widen scope and drag office staff in. If Tower vs MC organization is wanted, use sub-OUs *under* `OU=Caregivers` (e.g. `OU=Tower,OU=Caregivers`) — the sync scope includes everything beneath `OU=Caregivers`.
 
-- Tower/MC caregivers → `OU=Care-Assisted Living,OU=Departments` (or create `OU=Caregivers` sub-OU if we want finer GPO targeting)
+**Two separate, deliberate steps per caregiver:**
-- MedTech-flagged staff → same OU; group membership (SG-MedTech) controls ALIS licensing tier
+1. Create the account in `OU=Caregivers` — controls whether it syncs to the cloud.
-- CCG-flagged staff → same OU; group membership (SG-CCG) controls higher-privilege ALIS rights if any
+2. Add the account to `SG-Caregivers` — controls whether the Conditional Access policies apply. This is a deliberate decision asked at creation time; an OU->group auto-mirror was considered and explicitly declined 2026-05-14.
+
+- MedTech-flagged staff → also deliberately add to `SG-MedTech` (controls ALIS licensing tier) once that group exists.
+- CCG-flagged staff → also deliberately add to `SG-CCG` (higher-privilege ALIS rights, if any) once that group exists.
 
 Group-policy impact: the `CSC - Folder Redirection (LE)` work done for Life Enrichment does NOT apply here. Care-Assisted Living GPO pattern needs to be cloned from the finalized LE GPO once that's proven on Susan Hicks' machine (DESKTOP-ROK7VNM).
 
@@ -171,6 +175,7 @@ Group-policy impact: the `CSC - Folder Redirection (LE)` work done for Life Enri
 - [x] ~~Confirm Christine Nyanzunda is one person, not two~~ (resolved 2026-04-22 — one person, one account)
 - [x] ~~HR spelling confirmation on Paty Doran, Polett Pinazavala, Patricia Sandoval-Beck, Maia Baker~~ (all resolved 2026-04-22)
 - [ ] **Ederick Yuzon first-name spelling** — asked in 2026-04-22 email, still outstanding
+- [ ] **Christine Nyanzunda — Phase 2 handling (added 2026-05-14):** exclude her from caregiver AD account creation (she already has accounts). Her existing cloud-only M365 account must be moved/synced as part of the office-staff migration, not the caregiver rollout. See the SYNC WATCH-POINT under "Conflict / verify before creating" above.
 - [x] ~~Reliable Agency shared-login short usernames~~ (SUPERSEDED 2026-04-22 by HIPAA review — no shared logins, per-person only)
 - [ ] **Reliable Agency contract review** — confirm staffing contract says caregivers work under Cascades direct clinical control (workforce) vs. agency-supervised (BA). Get individual caregiver names before any PHI access.
 - [ ] Will caregivers use ALIS on the shared phones (need ALIS accounts + Entra SSO) or only email?

clients/cascades-tucson/session-logs/2026-05-14-howard-cascades-phone-verification-closeout.md

@@ -0,0 +1,233 @@
+# Cascades of Tucson — Phone Project Verification & Closeout
+
+**Date:** 2026-05-14 (continued into 2026-05-15 UTC)
+**Syncro ticket:** #32214 (Entra setup — In Progress)
+
+## User
+- **User:** Howard Enos (howard)
+- **Machine:** HOWARD-HOME
+- **Role:** tech
+
+## Goal
+
+Full verification of the Cascades caregiver shared-phone project against session logs, then
+close out the remaining open items so the project is ready for real caregiver rollout.
+
+ALIS SSO and ~19 phones had been proven working (2026-05-08/11 logs). This session confirms
+the backend architecture is solid before adding real caregivers.
+
+---
+
+## Phase 1 — Live Verification Sweep
+
+Read-only audit of Intune/Entra against the session logs. All checks performed via
+ComputerGuru Security Investigator SP (`bfbc12a4`) and Tenant Admin SP (`709e6eed`),
+tenant `207fa277-e9d8-4eb7-ada1-1064d2221498`.
+
+| Item | Expected | Actual | Result |
+|---|---|---|---|
+| Intune enrolled devices | ~19 CSC-* | 22 managed + 3 ghost | DRIFTED (3 ghost) |
+| Enrollment profile `9a0fcc6d` | token type=EntraSDM, valid | Confirmed | MATCHES |
+| Device restrictions `070a76c2` | v15, 9 kioskModeApps | Confirmed | MATCHES |
+| Compliance policy `27eeaeda` | assigned, compliant | Confirmed | MATCHES |
+| Dynamic group `ea96f4b7` (Shared Phones) | rule + members | 22 members | MATCHES |
+| App: Alis `8c0ae9bf` | required+published | Confirmed | MATCHES |
+| App: HelpAny `cbb9404b` | required+published | Confirmed | MATCHES |
+| App: LinkRx `c70f62bc` | required+published | Confirmed | MATCHES |
+| CA Block-off-network `e35614e1` | enabled | enabled | MATCHES |
+| CA Sign-in-frequency `7d491c7a` | enabled | enabled | MATCHES |
+| CA Block-non-compliant `ede985e2` | enabled | enabled | MATCHES |
+| CA Named Location `061c6b06` | trusted | Confirmed | MATCHES |
+| Registration Campaign | excludes caregiver group | excludes SG-Caregivers-Pilot | MATCHES (pilot group) |
+| ALIS app registration `d5108493` | secret exp 2028-05-06 | Confirmed | MATCHES |
+| Entra Connect staging mode | staging (expected) | staging (onPremisesLastSyncDateTime=null) | MATCHES |
+
+**Gap found:** All 3 CA policies and Registration Campaign exclusion targeted **SG-Caregivers-Pilot**
+(cloud-only, 1 member: pilot.test). Real caregivers from AD would never get the CA policies
+applied to them. Entra Connect was still in staging — the AD-backed SG-Caregivers group
+had never reached the cloud.
+
+---
+
+## Phase 2 — LinkRx and HelpAny Auth
+
+Both apps investigated:
+- **HelpAny:** credential-only login (username + password). No SSO capability offered.
+  Howard confirmed independently: "helpany just uses username and passwords."
+- **LinkRx:** Howard deferred: "skip the linkrx, i think its going to work the same way
+  helpany does." Credential-only assumed; revisit if vendor provides SSO option later.
+
+Result: no SSO setup required for either app. Managed Play web link tiles are sufficient.
+Caregivers will use credential login on phones.
+
+---
+
+## Phase 3 — Closeout
+
+### 3A — Ghost Intune device records
+
+3 ghost device records identified (no corresponding managed device, stale):
+- Attempted API DELETE via tenant-admin SP → 403 (DeviceManagementManagedDevices.ReadWrite.All
+  not in manifest)
+- **Status:** pending portal delete or SP scope expansion.
+- Action: delete manually in Intune portal > Devices > All devices, filter by stale/ghost.
+
+### 3B — Deleted test accounts
+
+Removed two test accounts that should not persist:
+- **howard.enos (AD)** — test caregiver account in OU=Caregivers; disabled then deleted via
+  GuruRMM PowerShell on CS-SERVER. Confirmed removed from AD.
+- **pilot.test (M365 cloud-only)** — deleted via Graph DELETE. Confirmed in deletedItems
+  with expected timestamp; no longer resolvable at primary endpoint.
+
+### 3C — samsungSM-F731U identification
+
+Identified owner of the incorrectly-Workplace-Joined Z Flip 5 via Entra sign-in logs:
+**John Trozzi**. Device was deleted from Entra. John needs a one-tap re-Workplace-Join
+on his personal device (Settings > Accounts > Access work or school > Connect).
+
+### 3D — Entra Connect exit staging + group model (PATH A)
+
+**The problem:** AD has `SG-Caregivers` (a real security group, members: none). The cloud
+also had a cloud-only `SG-Caregivers-Pilot` (1 member: pilot.test). All CA policies and the
+Registration Campaign exclusion pointed at the pilot group. Entra Connect was still in
+staging — SG-Caregivers had never synced to the cloud.
+
+**Decision — Path A:** add `OU=Groups` to Entra Connect sync scope, exit staging, re-point
+all policies to the synced AD-backed `SG-Caregivers` group. This gives us the correct
+long-term architecture: AD group membership drives CA policy coverage.
+
+Path A also verified safe for existing 56 cloud users:
+- Office staff are in departmental OUs (`OU=Care-Assisted Living`, `OU=Care-Memorycare`, etc.)
+  which are NOT in the Entra Connect sync scope — they will not be synced or duplicated.
+- PHS enabled at install (2026-04-24) is inert while no users are in scope; safe.
+- The 17 groups in `OU=Groups` are net-new objects — no soft-match collision risk.
+
+**Execution:**
+
+**Stage 1-2 (Howard, Entra Connect UI):**
+- Added `OU=Groups,DC=cascades,DC=local` to the OU filtering page.
+- Confirmed `OU=Caregivers` already in scope.
+- All other departmental OUs correctly unchecked.
+
+**Stage 3 (Howard, Ready to Configure page):**
+- Noted Password Hash Sync checkbox (correct — was configured at install 2026-04-24).
+- Unchecked "Start the synchronization process" so I could run it after staging exit.
+- Clicked Configure.
+
+**Stage 4 (Howard, exit staging):**
+- Wizard step: "Configure staging mode" → unchecked "Enable staging mode."
+- Left "start synchronization" checked.
+- Clicked Configure. Wizard showed "staging mode disabled." Howard clicked exit.
+- Sync ran automatically (wizard-triggered).
+
+**Post-exit verification (GuruRMM + Graph):**
+
+```
+StagingModeEnabled: false          [OK]
+SyncCycleEnabled:   true           [OK]
+LastSync (Entra):   2026-05-15T00:10:38Z  [OK]
+Groups exported:    17             [OK]
+  - AuditUploaders
+  - SG-CA-BreakGlass
+  - SG-Caregivers   <-- target group, now cloud-synced
+  - SG-Chat-RW, SG-CourtesyPatrol, SG-Culinary-RW, SG-Directory-RW, SG-Drivers,
+    SG-External-Signin-Allowed, SG-FrontDesk, SG-IT-RW, SG-Management-RW,
+    SG-Office-PHI-External, SG-Office-PHI-Internal, SG-Receptionist-RW,
+    SG-Sales-RW, SG-Server-RW
+SG-Caregivers cloud ID: 8b8d9222-5d71-419a-936d-56d895c6c332  [OK]
+onPremisesSyncEnabled:  true       [OK]
+```
+
+**Stage 5 — CA policy re-pointing (Graph PATCH via tenant-admin SP):**
+
+All 3 policies patched from SG-Caregivers-Pilot (`0674f0bc`) to SG-Caregivers (`8b8d9222`):
+
+```
+CA Block-off-network   (e35614e1) -> SG-Caregivers  [HTTP 204]
+CA Sign-in-frequency   (7d491c7a) -> SG-Caregivers  [HTTP 204]
+CA Block-non-compliant (ede985e2) -> SG-Caregivers  [HTTP 204]
+Registration Campaign excludeTargets -> SG-Caregivers  [HTTP 204]
+```
+
+**Stage 6 — Final verification:**
+
+```
+CA Block-off-network   includeGroups: [8b8d9222]  [OK]
+CA Sign-in-frequency   includeGroups: [8b8d9222]  [OK]
+CA Block-non-compliant includeGroups: [8b8d9222]  [OK]
+Registration Campaign  excludeTargets: [{id:8b8d9222}]  [OK]
+SG-Caregivers members: empty  [OK — correct, no real caregivers created yet]
+```
+
+### 3E — Standing rule: security group on user creation
+
+Howard explicitly declined an `OU=Caregivers → SG-Caregivers` auto-mirror script. Rule
+established: when any Cascades user is created, the security group(s) they join must be
+asked and decided explicitly at creation time. OU placement = mechanical sync scope;
+security group = deliberate access-control decision. Two separate steps per user.
+
+Documented in:
+- `clients/cascades-tucson/CONTEXT.md` — "User onboarding — security group is a deliberate decision"
+- `clients/cascades-tucson/docs/cloud/caregiver-m365-p2-rollout.md` — AD placement section + open items
+- `.claude/memory/feedback_cascades_user_security_group.md` — persistent memory
+
+### 3F — Christine Nyanzunda collision risk documented
+
+Christine has both a cloud-only M365 account AND an AD account (in a departmental OU, not
+in OU=Caregivers). When caregiver AD accounts are created in OU=Caregivers, do NOT create
+a `christine.nyanzunda` object there — duplicate in the synced OU would soft-match/collide
+with her existing cloud account. Handled in Phase 2 of office-staff migration, not the
+caregiver phone rollout.
+
+Documented in `docs/cloud/caregiver-m365-p2-rollout.md`.
+
+---
+
+## What's Architecturally Complete
+
+The caregiver phone infrastructure is now correctly wired end-to-end:
+
+1. **Identity sync path:** AD `OU=Caregivers` → Entra Connect (live, not staging) → cloud
+2. **Group model:** AD `SG-Caregivers` is the source of truth; cloud group is synced
+3. **CA policies:** all 3 enforce against the synced AD-backed group
+4. **Registration Campaign:** excludes synced SG-Caregivers (no Authenticator nudge for caregivers)
+5. **Enrollment:** 22 phones enrolled in SDM, all compliant
+6. **ALIS SSO:** proven end-to-end with pilot.test
+
+---
+
+## Remaining Open Items (pre-rollout blockers)
+
+| Item | Owner | Notes |
+|---|---|---|
+| Create real caregiver AD accounts | Howard + Meredith | In `OU=Caregivers`; ask security group(s) at creation |
+| Add each caregiver to SG-Caregivers (deliberate) | Howard | Separate from OU placement |
+| ALIS staff-record Email = Entra UPN per caregiver | Meredith / ALIS admin | Required for ALIS SSO |
+| SSPR scope = SG-SSPR-Eligible (not All) | Howard (portal) | Verify in Entra > Password reset > Properties |
+| Delete 3 ghost Intune device records | Howard (portal) | Intune > Devices > All devices |
+| John Trozzi one-tap re-Workplace-Join | Howard / John | Settings > Accounts > Access work or school |
+| Microsoft BAA + ALIS (Medtelligent) BAA | Meredith | HIPAA compliance carryover |
+| Reliable Agency per-person accounts | Howard (when names provided) | No shared logins per HIPAA |
+| Ederick Yuzon first-name spelling | Meredith (email) | Still outstanding |
+| Stale vault entries cleanup | Howard | `howard-enos-pilot.sops.yaml`, `pilot-test-user.sops.yaml` |
+
+## Deferred
+
+| Item | Notes |
+|---|---|
+| Knox OEMConfig (MHS half-screen) | Separate follow-up |
+| MHS welcome-screen branding | Post-rollout |
+| Portrait wallpaper upload | Post-rollout |
+| Disable devices@cascadestucson.com | Post-rollout |
+| SG-MedTech / SG-CCG groups | Create when ALIS licensing tiers confirmed |
+| LinkRx SSO | Revisit only if vendor offers SSO capability |
+
+## Related Docs
+
+- `docs/cloud/caregiver-m365-p2-rollout.md` — caregiver roster, AD placement, licensing
+- `docs/migration/phone-sso-pilot-runbook-2026-04-24.md` — original runbook
+- `docs/security/hipaa-caregiver-controls.md` — no-MFA compensating controls
+- `CONTEXT.md` — user-onboarding security-group rule
+- `session-logs/2026-05-08-howard-cascades-sdm-token-success-and-alis-sso.md` — SDM + ALIS SSO
+- `session-logs/2026-05-11-howard-cascades-mhs-web-link-tiles-fix.md` — MHS tiles + kiosk fix