claudetools/clients/cascades-tucson/session-logs/2026-06-03-session.md

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

# 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.