session: Cascades phone verification & closeout — Entra Connect staging exited, CA policies re-pointed to AD-synced SG-Caregivers

- Full tenant verification sweep: all Intune/Entra objects match session logs
- Entra Connect staging mode exited; 17 AD groups synced to cloud
- CA policies (Block-off-network, Sign-in-frequency-8h, Block-non-compliant) patched from SG-Caregivers-Pilot to AD-synced SG-Caregivers
- Registration Campaign exclusion updated to SG-Caregivers
- Deleted test accounts: howard.enos (AD) and pilot.test (M365)
- Documented Christine Nyanzunda collision risk, Ederick Yuzon open item, standing security-group rule
- Session log written

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

clients/cascades-tucson/CONTEXT.md

@@ -43,6 +43,15 @@ CA targeting consequences:
 - `SG-Break-Glass`: excluded from all CA (must add exclusion to every new policy)
 - ACG GDAP foreign principals: excluded from blocking policies via the "Service provider users" condition (Microsoft's CA UI), NOT via group membership
 
+## User onboarding — security group is a deliberate decision
+
+**Rule (2026-05-14):** When any Cascades user is created (AD or M365), the security group(s) they belong to must be **asked and decided explicitly** at creation time — never auto-derived from the OU, department, or title.
+
+- **OU placement** is mechanical — it controls whether the account syncs (Entra Connect scope). Caregivers go in `OU=Caregivers`.
+- **Security group membership** is an access-control decision — it controls what permissions and Conditional Access policies apply, and is reviewed/chosen per user.
+
+An `OU=Caregivers` -> `SG-Caregivers` auto-mirror script was considered and explicitly declined — the deliberate per-user review is the point. For caregivers: create in `OU=Caregivers` (sync) AND deliberately add to `SG-Caregivers` (CA coverage). Two separate, intentional steps.
+
 ## GuruRMM
 
 - Client: **Cascades of Tucson** (code `CASC`, id `42e1b0e3-f8b7-4fc5-86bd-06bdbb073b7f`)