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

# 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