Howard Enos
d6fc1cf5be
- 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>
1.3 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| cascades-user-security-group | When creating or adding any Cascades user, always ask which security group(s) the account goes into — deliberate decision, never auto-derived from OU |
|
When creating, or being asked to create, any Cascades user account (AD or M365), always ask the user which security group(s) the new account should be a member of. Include it explicitly in the creation preview/confirmation alongside name, UPN, and OU — do not assume it from the OU, department, or job title.
Why: Howard explicitly declined an OU=Caregivers -> SG-Caregivers auto-mirror script (2026-05-14). Security-group membership controls what access and Conditional Access policies apply to a user; he wants that to stay a deliberate, reviewed decision per user, not automated away. OU placement is mechanical (it controls Entra Connect sync scope); group membership is an access-control decision and must be made consciously.
How to apply: During any Cascades user-creation flow, ask "which security group(s)?" and confirm it in the preview. For caregivers specifically: the account goes in OU=Caregivers (for sync scope) AND must be deliberately added to SG-Caregivers (for CA policy coverage) — two separate, intentional steps, neither auto-derived from the other.