Howard Enos
18e5a467d2
Cascades caregiver shared-phone bypass pilot — 2026-04-29 evening into 2026-04-30 early morning continuation. Major work: - Adopted phased per-group CA rollout (corrects original tenant-wide §5 design that would have blocked off-site office users) - Step A: backfilled admin@ into excludeUsers on all 8 existing Cascades CA policies (mirrors sysadmin@ exclusion posture; Option 1 break-glass) - Outlook + Helpany + LinkRx assigned to Cascades - Shared Phones group and added to MHS kiosk app list (final dashboard: 5 caregiver apps) - Created cloud-only pilot user pilot.test@cascadestucson.com, SG-Caregivers-Pilot group, Business Premium license, vault entry pushed to Gitea vault repo - Built 4 CA changes: PATCH legacy all-users-MFA to exclude pilot group, CREATE 3 new Report-only policies (block off-network, block non-compliant, 8h sign-in frequency) with both admins excluded - Pilot phone wipe + re-enroll after first attempt stuck; PIN set, awaiting MHS to take over launcher and SDM sign-in prompt 6 new project/feedback memories. Resume point at top of new session log. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
1.4 KiB
1.4 KiB
name, description, type
| name | description | type |
|---|---|---|
| Microsoft Graph CA policy reads are eventually consistent (~5s) | After PATCHing a CA policy (204 No Content), an immediate GET may return stale state. Wait ~5 seconds before verifying. | feedback |
When PATCHing /identity/conditionalAccess/policies/{id} and immediately re-reading via GET, the read may return pre-PATCH state for a few seconds even though the PATCH was accepted (204).
Observed 2026-04-29 during the Cascades admin@ exclusion backfill: 7 of 8 PATCHes returned 204, but immediate verify GETs showed the old excludeUsers list. Re-query after sleep 5 showed all 8 had landed correctly. No retries were needed — the PATCH had succeeded; only the read lagged.
Why: Microsoft Graph fronts CA policy reads through a regional cache that doesn't immediately reflect writes. Writes hit the authoritative store and return 204 right away. Reads converge after a short propagation window.
How to apply:
- After a CA policy PATCH that returns 204, do not treat an immediate "verify mismatch" as failure.
- Insert
sleep 3-5(or a poll loop with a few seconds of backoff) before the verify GET. - If verifying many policies in a batch, the simplest pattern is: do all PATCHes, sleep 5, then re-query everything once at the end.
- This applies to CA policies specifically. Other Graph endpoints (e.g., users, groups) have their own consistency characteristics — don't generalize.