diff --git a/.claude/memory/MEMORY.md b/.claude/memory/MEMORY.md index e5bb31e..25d8cd9 100644 --- a/.claude/memory/MEMORY.md +++ b/.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\\*` 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. diff --git a/.claude/memory/feedback_cascades_user_security_group.md b/.claude/memory/feedback_cascades_user_security_group.md new file mode 100644 index 0000000..510d69d --- /dev/null +++ b/.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. diff --git a/clients/cascades-tucson/CONTEXT.md b/clients/cascades-tucson/CONTEXT.md index 009ddc3..783866a 100644 --- a/clients/cascades-tucson/CONTEXT.md +++ b/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`) diff --git a/clients/cascades-tucson/docs/cloud/caregiver-m365-p2-rollout.md b/clients/cascades-tucson/docs/cloud/caregiver-m365-p2-rollout.md index 9c81860..83cd72b 100644 --- a/clients/cascades-tucson/docs/cloud/caregiver-m365-p2-rollout.md +++ b/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) -- MedTech-flagged staff → same OU; group membership (SG-MedTech) controls ALIS licensing tier -- CCG-flagged staff → same OU; group membership (SG-CCG) controls higher-privilege ALIS rights if any +**Two separate, deliberate steps per caregiver:** +1. Create the account in `OU=Caregivers` — controls whether it syncs to the cloud. +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? diff --git a/clients/cascades-tucson/session-logs/2026-05-14-howard-cascades-phone-verification-closeout.md b/clients/cascades-tucson/session-logs/2026-05-14-howard-cascades-phone-verification-closeout.md new file mode 100644 index 0000000..35ed1eb --- /dev/null +++ b/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