Files
claudetools/clients/cascades-tucson/session-logs/2026-05-14-howard-cascades-phone-verification-closeout.md
Howard Enos ce6a733496 sync: auto-sync from HOWARD-HOME at 2026-05-14 18:54:09
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-05-14 18:54:09
2026-05-14 18:54:10 -07:00

13 KiB

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
  • 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

Addendum — Post-session verifications (2026-05-14 continued)

SSPR portal confirmed by Howard: Password reset > Properties shows "Selected" with SG-SSPR-Eligible as the target group. Correct.

John Trozzi Z Flip 5: Howard confirmed John has already re-logged in on his personal phone. Resolved — no action needed.

Ghost Intune device records: Howard elected not to pursue cleanup. Not a rollout blocker.

BAA status: Docs show both BAAs still open (Microsoft BAA "Not signed", ALIS BAA "Not verified"). Howard believed these may have been done previously — no session log or doc confirms completion. Keeping as open items until verified with Meredith.

Syncro ticket #32214 updated: Comment posted (ID 411033290) with full session summary and remaining open items.


Update: ~18:00 PT — BAA verification and doc cleanup

Microsoft BAA resolved: Howard opened M365 Admin Center > Settings > Org Settings > Security & privacy — no HIPAA BAA option present. Investigated: the explicit BAA acceptance page only exists for Enterprise Agreement / volume licensing tenants. Cascades is on a Business plan under the Microsoft Customer Agreement (MCA), which automatically includes the HIPAA BAA as part of the Online Service Terms. No separate acceptance is required or available. Gap #13 closed.

Updated in:

  • docs/security/hipaa.md — gap #13 marked resolved, quick-wins item struck through
  • docs/security/hipaa-caregiver-controls.md — Microsoft BAA line updated
  • docs/cloud/m365.md — BAA status and gap #12 updated

ALIS BAA: Still open. No session log or document confirms a signed BAA with Medtelligent. Meredith to check if Medtelligent provided a signed copy at contract time; if not, request one from Medtelligent support.

Final open items before real caregiver rollout:

Item Owner
ALIS BAA — check with Meredith / Medtelligent Meredith
Create caregiver AD accounts in OU=Caregivers; add each to SG-Caregivers Howard
Update ALIS staff-record Email = Entra UPN per caregiver Meredith / ALIS admin
Reliable Agency per-person accounts (need individual names) Hold
Ederick Yuzon first-name spelling confirmation Meredith (email)
Stale vault entries: howard-enos-pilot.sops.yaml, pilot-test-user.sops.yaml Howard