# Cascades — ALIS SSO failure diagnosis, admin consent granted, caregiver device allow-list staged

**Date:** 2026-06-03
**Client:** Cascades of Tucson (Syncro 20149445, Tenant `207fa277-e9d8-4eb7-ada1-1064d2221498`)

## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech

## Session Summary

Investigated reports that some staff could not sign in to ALIS on non-phone devices. Pulled live Entra data via the remediation-tool Security Investigator app and found the failures were `AADSTS65001` (application not consented), not Conditional Access or network. All failing sign-ins (megan.hiatt, karen.rossini, memcarereceptionist) came from the two trusted Cascades WAN IPs with `conditionalAccessStatus: success` — CA was never the gate. The ALIS service principal (`e1cae4ad-5beb-44ca-82d4-434c9bd835ad`) had only two per-user (`Principal`) consent grants for `User.Read` and no tenant-wide admin consent, so every user except the two who had self-consented hit a hard 65001.

Established that the "two-factor" toggle that fixed login for caregivers/medtechs was ALIS's own native 2FA, not Entra MFA: the `Require multifactor authentication for all users` policy excludes `AllTrusted` locations, so Entra never prompts on the Cascades network. Walked the security model — ALIS-native 2FA and Entra are two independent doors; a non-SSO ALIS user can reach ALIS from anywhere with just ALIS credentials because Entra never sees that login. The correct control is forcing all ALIS logins through Entra SSO (SSO-only, credential fallback disabled), not relying on ALIS-native 2FA.

Reconstructed the full project design from Syncro tickets #109412123 ("Entra setup" / Syncro #32214) and #110680053 ("Domain setup-entra sync" / Syncro #32303), the migration master plan, wiki, memory, and last month's session logs (two subagents + live Entra pulls). Confirmed the caregiver side is fully built and enforced (SG-Caregivers 38 members synced; three CSC CA policies enabled; phones in SDM), while the office/privileged ALIS path is in a mixed/broken state (some SSO, some direct login + native 2FA) and the office department OUs are not yet expanded into Entra Connect sync scope.

Per Howard's direction, changed the caregiver device restriction model from compliance-based to an explicit device allow-list (phones + 5 named machines), to be easier and lower-risk while machine compliance is verified later. Allowed devices: NURSESTATION-PC plus laptops Laptop2, LAPTOP-8P7HDSEI, LAPTOP-DRQ5L558, LAPTOP-E0STJJE8 (confirmed 5 total, no 6th). Verified the Android enrollment token (`CSC - Android Shared Phones (Entra SDM)`, 25 devices enrolled, token expires 2027-05-08) is a join key only — its expiry does not unenroll existing devices.

Executed two authorized production changes via the Tenant Admin app: granted tenant-wide admin consent (`AllPrincipals` `User.Read`) for the ALIS app, resolving 65001 for everyone; and created a new caregiver device allow-list CA policy in report-only (`CSC - Caregivers: allow-listed devices only (REPORT-ONLY)`). The three existing enforced caregiver policies were left untouched, so nothing was weakened during the transition.

## Key Decisions

- Diagnosed root cause as missing admin consent (65001), not CA/network/password. Evidence: all failures from trusted IPs, `conditionalAccessStatus: success`, only two `Principal` consent grants on the ALIS SP.
- Chose an explicit device allow-list (CA device filter on `displayName -startsWith "CSC-"` OR `extensionAttribute1 -eq "CSCCaregiverDevice"`) over compliance-based gating, because the tenant has no Windows compliance policy and `secureByDefault=false` (no-policy devices read as compliant) — compliance-only would let any future-enrolled PC in. Allow-list prevents scope creep.
- Created a NEW report-only allow-list policy rather than editing the existing enforced `CSC - Block caregivers on non-compliant device`, so the live phone lockdown is not weakened during validation. Cutover later = enable allow-list + disable the compliance policy.
- Granted admin consent programmatically as `AllPrincipals` `User.Read` (mirrors the two per-user grants that were already working) rather than the interactive admin-consent URL.
- Mirrored break-glass exclusions from the existing CSC policies (`admin@`, `sysadmin@`) and added the `SG-CA-BreakGlass` group to the new policy.
- ALIS-native 2FA is the wrong perimeter control; the permanent model is all users on ALIS SSO + ALIS set to SSO-only + native 2FA off, with Entra doing onsite-seamless / offsite-MFA. Deferred the office/privileged standardization as a separate workstream.

## Problems Encountered

- Sign-in log query returned HTTP 504 (gateway timeout) on an appId-only `$filter`. Resolved by adding a `createdDateTime ge` date bound and URL-encoding the filter (spaces in the raw URL broke curl).
- Investigator (Security Investigator) token lacked Intune DeviceManagement scope (403). Resolved by falling back to the intune-manager tier for `androidDeviceOwnerEnrollmentProfiles`, `deviceCompliancePolicies`, and `deviceManagement/settings`.
- `policies/mobileDeviceManagementPolicies` returned BadRequest; could not read the Windows MDM auto-enroll scope via API. Noted to confirm in the Entra portal instead.
- Memory files referenced by the wiki (`project_cascades_ca_phased_rollout.md`, etc.) did not exist at the expected paths; glob `.claude/memory/*cascade*` returned none. Subagent read the actual sources directly.

## Configuration Changes

### Entra / Conditional Access (tenant `207fa277-e9d8-4eb7-ada1-1064d2221498`)

- **Admin consent granted** for ALIS app. New delegated grant created:
  - `oauth2PermissionGrant` id `reTK4etbykSC1ENMm9g1rTplOyzgVClCofKDVRrn-ds`
  - clientId `e1cae4ad-5beb-44ca-82d4-434c9bd835ad` (ALIS SP), resourceId `2c3b653a-54e0-4229-a1f2-83551ae7f9db` (Microsoft Graph SP)
  - consentType `AllPrincipals`, scope `User.Read`
- **New CA policy created (report-only):**
  - `CSC - Caregivers: allow-listed devices only (REPORT-ONLY)` — id `1b7fd025-1aad-47c8-9274-c32c3e0b163c`
  - state `enabledForReportingButNotEnforced`
  - include group `SG-Caregivers` (`8b8d9222-5d71-419a-936d-56d895c6c332`)
  - exclude users `sysadmin@` (`471b13dc-3cf8-416b-a132-f5f3bc8d1cc8`, "Computer Guru Support") and `admin@` (`e20f7f21-757a-48cd-bb24-7bdeeb1497d0`, "Cascades Tenant Admin"); exclude group `SG-CA-BreakGlass` (`131e51ac-d69b-44b8-9c81-56890537a796`)
  - applications: All; grant: block
  - device filter: mode `exclude`, rule `(device.displayName -startsWith "CSC-") -or (device.extensionAttribute1 -eq "CSCCaregiverDevice")`

No files in the repo were modified this session (investigation + live Entra changes only). Session log + wiki recompile are the repo changes.

## Credentials & Secrets

No new credentials created or discovered. Relevant existing references (unchanged):
- ALIS Entra app registration + ALIS install key + Inbound Basic Auth: vault `clients/cascades-tucson/alis-sso-app-registration.sops.yaml`
- ALIS app: Application ID `d5108493-cba8-4f08-90b6-1bb0bc09eb2a`, client secret expires 2028-05-06 (rotation reminder — expiry breaks ALIS SSO tenant-wide)
- Remediation-tool app tokens sourced from `msp-tools/computerguru-*.sops.yaml` (Security Investigator, Tenant Admin, Intune Manager tiers)

Note: there are NO per-caregiver password vault entries; SSO-linked ALIS users have no usable ALIS password (auth delegated to Entra/PHS).

## Infrastructure & Servers

- Tenant ID `207fa277-e9d8-4eb7-ada1-1064d2221498` (`cascadestucson.com`)
- ALIS SP objectId `e1cae4ad-5beb-44ca-82d4-434c9bd835ad`; Microsoft Graph SP objectId `2c3b653a-54e0-4229-a1f2-83551ae7f9db`
- Named Location `Cascades` (`061c6b06-b980-40de-bff9-6a50a4071f6f`, isTrusted): `184.191.143.62/32` (primary WAN), `72.211.21.217/32` (secondary WAN, DHCP — stale risk)
- Existing enforced caregiver CA policies (unchanged this session):
  - `CSC - Block caregivers off Cascades network` `e35614e1-e896-4a13-9407-076963af488f`
  - `CSC - Block caregivers on non-compliant device` `ede985e2-ee7e-4521-88b2-34c847c3db20` (to be DISABLED at allow-list cutover)
  - `CSC - Caregiver sign-in frequency 8h` `7d491c7a-ad90-4420-9990-40a1e676a76c`
- `Require multifactor authentication for all users` (`7e87a1c7…`): enabled, grant=mfa, excludeLocations=AllTrusted, excludeGroups=`SG-Caregivers-Pilot` (`0674f0bc…`) — STALE; should reference live `SG-Caregivers` (`8b8d9222…`). Functionally harmless today but a known bug.
- Android enrollment profile `CSC - Android Shared Phones (Entra SDM)` `9a0fcc6d-0a88-466e-aa53-44401bb74fca`: 25 devices enrolled, token expires 2027-05-08. Token = join key only; expiry does NOT unenroll devices.
- Only compliance policy in tenant: `CSC - Android Compliance` (no Windows compliance policy). `deviceManagement/settings.secureByDefault = false`.

### Caregiver-allowed device list (target — 5 devices)
| Device | OS | GuruRMM agent | Enroll path |
|---|---|---|---|
| NURSESTATION-PC | Win 11 | `8164c6fa-62e7-4aa5-88e4-624f2f656932` | Hybrid Entra Join (domain-joined) |
| Laptop2 | Win 11 | `dc8daf71-a2e6-4181-8cf2-c463c95dcd7d` | Entra join (RMM pending install) |
| LAPTOP-8P7HDSEI | Win 10 (EOL — upgrade) | `9b74852c-623a-4d4a-bdda-1709ee75ae44` | Entra join |
| LAPTOP-DRQ5L558 | Win 11 | `f9e25b3b-da63-40ff-94a6-8cec3b9a19ce` | Entra join |
| LAPTOP-E0STJJE8 | Win 11 | `4ac00700-9a9b-4e7f-a7aa-c51857b77661` | Entra join |

## Commands & Outputs

```bash
# Token (read-only investigator) then ALIS sign-in failures (note date bound + URL-encode to avoid 504)
TOK=$(bash scripts/get-token.sh $TEN investigator)
curl -s -G -H "Authorization: Bearer $TOK" \
  --data-urlencode "\$filter=appId eq 'd5108493-...' and createdDateTime ge 2026-05-27T..Z" \
  --data-urlencode "\$top=100" "https://graph.microsoft.com/v1.0/auditLogs/signIns"
# -> errorCode 65001 (AADSTS65001 not consented); conditionalAccessStatus success; IPs all trusted

# Grant admin consent (tenant-admin tier)
curl -s -X POST -H "Authorization: Bearer $TOK_TA" -H "Content-Type: application/json" \
  -d '{"clientId":"e1cae4ad-...","consentType":"AllPrincipals","resourceId":"2c3b653a-...","scope":"User.Read"}' \
  https://graph.microsoft.com/v1.0/oauth2PermissionGrants    # -> HTTP 201

# Create report-only allow-list CA policy -> HTTP 201, id 1b7fd025-1aad-47c8-9274-c32c3e0b163c
```

- Intune scope requires `intune-manager` tier (investigator 403s on `deviceManagement`).
- Device filter operators used: `-startsWith`, `-eq`, `-or` (mode `exclude`).

## Pending / Incomplete Tasks

### Caregiver device allow-list rollout
- [ ] Confirm Windows MDM auto-enroll scope in portal: Entra → Devices → Mobility (MDM and MAM) → Microsoft Intune → MDM user scope = All.
- [ ] Entra-join + Intune-enroll the 4 laptops (Howard). Verify each appears in Intune.
- [ ] NURSESTATION-PC: needs Hybrid Entra Join (Entra Connect device-sync/SCP config) — confirm whether already enabled; separate task.
- [ ] After enrollment, tag each device `extensionAttribute1 = CSCCaregiverDevice` (Claude, via Graph).
- [ ] Review report-only results in sign-in logs (phones + tagged = allowed; else = would-block).
- [ ] CUTOVER (needs Howard OK): set `CSC - Caregivers: allow-listed devices only` to `enabled` AND disable `CSC - Block caregivers on non-compliant device`.
- [ ] LAPTOP-8P7HDSEI: upgrade Win 10 → Win 11 before PHI use.
- [ ] Optional: create `CSC - Windows Compliance` policy for the PHI laptops once allow-list is stable.

### ALIS / office-privileged standardization (separate workstream)
- [ ] Verify ALIS is set to SSO-only (credential fallback disabled) for linked users — closes the "ALIS from home with just ALIS creds" hole.
- [ ] Move office/managers/directors/nurses onto ALIS SSO; set each ALIS staff Email = Entra UPN; turn off ALIS-native 2FA per user.
- [ ] Once all on SSO, disable ALIS-native 2FA globally.

### Known fixes / hygiene
- [ ] Fix stale exclude-group on `Require multifactor authentication for all users` (`SG-Caregivers-Pilot` → `SG-Caregivers`).
- [ ] Expand Entra Connect sync to office department OUs + add `cascadestucson.com` UPN suffix (from #32303).
- [ ] Per-caregiver ALIS Email=UPN for several (Esperance; add Kasey Flores, Jahmeka Clarke, Gloria Williford).
- [ ] 38 Business Premium licenses; ALIS (Medtelligent) BAA; break-glass FIDO2 accounts.

## Reference Information

- Syncro tickets: #109412123 = Syncro #32214 "Entra setup"; #110680053 = Syncro #32303 "Domain setup-entra sync"
- ALIS tenant: https://cascadestucson.alisonline.com ; ALIS support 888-404-ALIS / support@go-alis.com
- Entra: https://entra.microsoft.com ; Intune: https://intune.microsoft.com
- Admin consent URL (fallback, not used — granted via API): `https://login.microsoftonline.com/207fa277-e9d8-4eb7-ada1-1064d2221498/adminconsent?client_id=d5108493-cba8-4f08-90b6-1bb0bc09eb2a`
- 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.

## Update: 11:50 MST — Caregiver device allow-list rollout: enrollment approach + join-model decisions

Resumed the caregiver device allow-list workstream. Live check confirmed none of the 5 target devices are usable yet: the 4 laptops (Laptop2, LAPTOP-8P7HDSEI, LAPTOP-DRQ5L558, LAPTOP-E0STJJE8) are not in Entra; NURSESTATION-PC has only a stale 2021 Workplace-registered record (OS build 18363, last seen 2021-07-03, unmanaged) to be ignored/cleaned. Tenant holds 91 Windows device objects, mostly previous-MSP cruft.

Decided the join model per device. Laptops will be **Entra-joined (cloud join)**, not domain-joined: the allow-list is a CA device filter that can only match a device with an Entra device object, and a domain-join-only PC has no Entra object — so domain-only cannot be allow-listed and is ruled out. The laptops are shared ALIS/Teams/Outlook access points and do not need the on-prem GPO stack (folder redirection, mapped drives). NURSESTATION-PC stays domain-joined and gets **Hybrid Entra Join** (it needs on-prem printers/ALDocs share) — requires a one-time device-options config in Entra Connect on CS-SERVER. Mixed model (Entra-joined laptops + hybrid NURSESTATION) is supported.

Printing does not require domain join. Entra-joined laptops print via direct IP network printers or an Intune-pushed printer config (Add-Printer against the printer IP). Printing alone is not a reason to domain-join; only the full domain experience (GPO printers + folder redirect + seamless shares) would justify hybrid, which these laptops do not need.

License/account analysis: Business Premium (SPB) = 34 seats, 4 consumed, 30 free. `sysadmin@` carries only Power Automate Free (FLOW_FREE); `admin@` and `devices@` are unlicensed. Device-join policy allows all users to join (quota 50). Recommended join account is the dedicated `devices@cascadestucson.com` (Cloud Device Administrator), which needs a Business Premium license assigned at enrollment time so auto-MDM-enroll fires.

Clarified Intune licensing lifecycle: the enrolling account's license is needed only at the moment of join. After enrollment the device stays Entra-joined and Intune-managed, and the CA allow-list (which keys on the device object) is unaffected by the enroller's later license state. One license covers sequential enrollments of all devices; the Business Premium seat can be reclaimed from `devices@` after the batch. Per-user Intune licensing for ongoing use is satisfied by the caregivers (Business Premium) and/or by marking each laptop a shared device (remove primary user in Intune).

### Key Decisions (this update)
- Laptops = Entra join, not domain join: domain-only produces no Entra device object, breaking the CA allow-list. The laptops do not need the on-prem GPO stack.
- NURSESTATION-PC = domain-joined + Hybrid Entra Join (needs on-prem resources); ignore/clean its stale 2021 Entra record.
- Printing handled via direct IP / Intune push — not a justification to domain-join.
- Use `devices@` (Cloud Device Administrator) as the join account, licensed with Business Premium only transiently for enrollment, then reclaim the seat.

### Configuration Changes (this update)
- None applied. Planning + live read-only checks only. Business Premium license assignment to `devices@` offered but NOT yet executed (awaiting go-ahead).

### Credentials (this update)
- `devices@cascadestucson.com` / `Gptf*77ttb!` — Cloud Device Administrator, user ID `aaca80c6-861b-4294-8068-1033c68d7667`. Vault: `clients/cascades-tucson/devices-account.sops.yaml`. Currently UNLICENSED — needs Business Premium at enrollment.

### Reference (this update)
- SPB (Business Premium) skuId `cbdc14ab-d96c-4c30-b9f4-6ada7cdc1d46` (34 seats, 30 free). O365_BUSINESS_PREMIUM (Business Standard, suspended) skuId `f245ecc8-75af-4f8e-b61f-27d8114de5f3` (0 enabled, 31 consumed).
- Printers (CS-SERVER print server): FrontDesk = Epson ET-5800 `192.168.2.147`; CopyRoom = Canon imageRunner C478iF `192.168.2.230`; MCReception = Epson ET-5800 (Memory Care reception). 13 total.
- Device join policy: `allDeviceRegistrationMembership` (all users may join), userDeviceQuota 50.
- MDM auto-enroll scope (Entra -> Devices -> Mobility (MDM and MAM) -> Microsoft Intune -> MDM user scope) NOT verifiable via API (BadRequest) — confirm = All in portal before joining.

### Pending (this update)
- [ ] Assign Business Premium to `devices@` (offered; awaiting go-ahead).
- [ ] Confirm MDM user scope = All in portal.
- [ ] Confirm which printer(s) each laptop needs -> Intune printer push.
- [ ] Confirm whether any laptop needs on-prem file shares (would push that one to hybrid).
- [ ] Entra-join 4 laptops with `devices@`; reclaim license after batch.
- [ ] Hybrid Entra Join for NURSESTATION-PC (Entra Connect device options on CS-SERVER); clean stale 2021 record.
- [ ] After enrollment: tag devices `extensionAttribute1=CSCCaregiverDevice`, validate report-only, then cutover.