From c693dc1e24db652d2a5400f298c5c29dd11284d8 Mon Sep 17 00:00:00 2001 From: Howard Enos Date: Wed, 3 Jun 2026 09:56:31 -0700 Subject: [PATCH] sync: auto-sync from HOWARD-HOME at 2026-06-03 09:56:24 Author: Howard Enos Machine: HOWARD-HOME Timestamp: 2026-06-03 09:56:24 --- .../session-logs/2026-06-03-session.md | 19 +++++++++++++++++++ wiki/clients/cascades-tucson.md | 8 ++++++++ 2 files changed, 27 insertions(+) diff --git a/clients/cascades-tucson/session-logs/2026-06-03-session.md b/clients/cascades-tucson/session-logs/2026-06-03-session.md index 9c8f23f..601bdc6 100644 --- a/clients/cascades-tucson/session-logs/2026-06-03-session.md +++ b/clients/cascades-tucson/session-logs/2026-06-03-session.md @@ -138,3 +138,22 @@ curl -s -X POST -H "Authorization: Bearer $TOK_TA" -H "Content-Type: application - Migration master plan: `C:\Users\Howard\.claude\plans\wise-discovering-panda.md` - Remediation skill: `.claude/skills/remediation-tool/` (get-token.sh tiers: investigator, intune-manager, tenant-admin) - New CA policy id: `1b7fd025-1aad-47c8-9274-c32c3e0b163c` ; consent grant id: `reTK4etbykSC1ENMm9g1rTplOyzgVClCofKDVRrn-ds` + +## Update: 09:55 MST — Crystal Rodriguez SSO fixed (per-user ALIS Email = UPN confirmed) + +Diagnosed why Megan Hiatt could use the ALIS "Sign in with Microsoft" option but Crystal Rodriguez could not. Both are identical on every dimension that could matter: cloud-only Entra accounts (`onPremisesSyncEnabled = null`), enabled, neither in `SG-Caregivers`, and **both have their own per-user `Principal` consent grant** (Megan `b8de0859`, Crystal `ac1799f6`). So it was not the security group, not consent, not identity, not sync state. + +The real difference was the **login path**: Megan had 10 ALIS sign-in events through the Entra/Microsoft login (most recent `errorCode 0` = success), while Crystal had **zero** ALIS/Entra sign-in events in 14 days — she had never come through the Microsoft login at all. Her ALIS staff record was not SSO-linked because the **Email field on her ALIS record did not match her Entra UPN** (`crystal.rodriguez@cascadestucson.com`), so "Sign in with Microsoft" could not resolve her to a staff record, and she fell back to direct ALIS credential login. + +**Resolution (Howard):** added Crystal's email to her ALIS staff record → SSO worked immediately. + +### Confirmed procedure — enable ALIS SSO for one user +1. User must have a valid Entra identity (synced or cloud-only — both work). +2. Tenant-wide admin consent for the ALIS app must exist — **done globally 2026-06-03**, so this is a one-time prerequisite, not per-user. +3. In ALIS admin → Staff → user's record, set the **Email field = the user's exact Entra UPN** (e.g. `crystal.rodriguez@cascadestucson.com`). This is the per-user SSO join key. +4. User signs in via **"Sign in with Microsoft"** (not the ALIS username/password box). +5. Turn off **ALIS-native 2FA** on that user's account (Entra is the second factor; native 2FA conflicts and was what locked out Karen Rossini on 2026-05-29). + +Symptom signature: a user with zero ALIS app sign-in events in the Entra logs is on the old direct-login path (not SSO) — the fix is the ALIS Email match, not anything in Entra. + +Sweep target: apply this to all office/clinical users (Karen Rossini, MemCare reception, etc.) to standardize everyone onto SSO. diff --git a/wiki/clients/cascades-tucson.md b/wiki/clients/cascades-tucson.md index 57392f5..3f5f3ba 100644 --- a/wiki/clients/cascades-tucson.md +++ b/wiki/clients/cascades-tucson.md @@ -109,6 +109,14 @@ Senior living / assisted living facility in Tucson, AZ. Single 6-floor building - `sysadmin@cascadestucson.com` — Howard's working admin (cloud-only, Connect-excluded by design) - **ALIS (clinical SaaS):** https://cascadestucson.alisonline.com — Entra SSO live and working; proven end-to-end with pilot.test on Galaxy A15 caregiver phones. Install key: `d796539d-356b-4190-9c17-35f0f1129376`. Vault: `clients/cascades-tucson/alis-sso-app-registration.sops.yaml` (Entra app reg + ALIS Inbound Connections Basic Auth creds + install key). ALIS application ID `d5108493-cba8-4f08-90b6-1bb0bc09eb2a`, client secret expires 2028-05-06 (rotation reminder — expiry breaks ALIS SSO tenant-wide). Per-caregiver: ALIS staff-record Email must match Entra UPN exactly. BAA with Medtelligent not yet verified — confirm with Meredith. - **Admin consent (2026-06-03):** Tenant-wide admin consent (`AllPrincipals` `User.Read`) granted on ALIS Entra service principal (`e1cae4ad-5beb-44ca-82d4-434c9bd835ad`) via Graph API (`oauth2PermissionGrant` id `reTK4etbykSC1ENMm9g1rTplOyzgVClCofKDVRrn-ds`). This resolved `AADSTS65001` sign-in failures that office/clinical staff (megan.hiatt, karen.rossini, memcarereceptionist) were hitting on non-phone devices. Root cause was missing admin consent — NOT Conditional Access, network, or password. Prior state: only two per-user (`Principal`) consent grants existed, so all other users hit 65001. CA policies had `conditionalAccessStatus: success` on all failing sign-ins; both WAN IPs were trusted Named Locations. + - **How to enable ALIS SSO for one user (procedure — confirmed 2026-06-03):** + 1. User needs a valid Entra identity (synced or cloud-only both work). + 2. Tenant-wide admin consent for the ALIS app must exist — **done globally 2026-06-03**, so this is a one-time prerequisite, NOT per-user. + 3. In ALIS admin -> Staff -> the user's record, set the **Email field = the user's exact Entra UPN** (e.g. `crystal.rodriguez@cascadestucson.com`). This is the per-user SSO join key. + 4. User signs in via **"Sign in with Microsoft"** — not the ALIS username/password box. + 5. Turn off **ALIS-native 2FA** on that user's account (Entra is the second factor; native 2FA conflicts and locked out Karen Rossini on 2026-05-29). + - **Diagnostic signature:** a user with **zero ALIS-app sign-in events in the Entra sign-in logs** is still on the old direct-login path (never reached Entra) — the fix is the ALIS Email match, not anything in Entra. Confirmed with Crystal Rodriguez (2026-06-03): identical to Megan Hiatt on identity, sync state, security group, and even held her own per-user consent grant — the ONLY difference was the missing ALIS Email match. Adding her email fixed SSO immediately. Megan worked because her ALIS record was already Email-matched and she used the Microsoft login; Crystal was falling back to direct ALIS login. + - **Sweep target:** apply to all office/clinical users (Karen Rossini, MemCare reception, etc.) to standardize everyone onto SSO. - **Caregiver phones:** 22 Samsung Galaxy A15s enrolled in Intune Shared Device Mode (SDM). Enrollment profile: `CSC - Android Shared Phones (Entra SDM)` (`9a0fcc6d-0a88-466e-aa53-44401bb74fca`); 25 devices enrolled per 2026-06-03 Intune pull. Dynamic group: `Cascades - Shared Phones` (`ea96f4b7-3000-45da-ab1f-ddb28f509526`). Used by caregivers for Teams, Outlook, and ALIS. CA policies: block off-network, block non-compliant device (see below re: pending replacement with allow-list), 8h sign-in frequency. Android enrollment token expires 2027-05-08 — token is a join key only; expiry does NOT unenroll existing devices. - **Audit retention:** Approved 2026-04-29. Azure Log Analytics (90d) + Storage Account (6yr) in ACG subscription `e507e953-2ce9-4887-ba96-9b654f7d3267`, RG `rg-audit-cascadestucson`. **Not yet built.** Runbook: `.claude/skills/remediation-tool/references/audit-retention-runbook.md`.