sync: auto-sync from HOWARD-HOME at 2026-06-30 12:39:43

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-30 12:39:43
This commit is contained in:
2026-06-30 12:40:12 -07:00
parent bc6dde5b89
commit 5db3a27685
2 changed files with 150 additions and 13 deletions

View File

@@ -24,16 +24,19 @@
| 7 | Remove **O365 Business Standard** license (`f245ecc8…`) | confirmed 0 licenses — **frees 1 seat** |
| 8 | Remove from groups `Sales`, `All Cascades`, `SG-SSPR-Eligible` | HTTP 204 ×3 |
### AutoMapping caveat (delegate auto-attach)
- **Crystal Rodriguez + Ashley Jensen** — added with `AutoMapping:$true`; the shared mailbox
**auto-attaches** in their Outlook.
- **Megan Hiatt + Meredith Kuhn** — `AutoMapping:$true` would not persist via the ComputerGuru
Exchange Operator app: the cmdlet echoed success but the grant rolled back (a failed
`msExchDelegateListLink` write aborts the whole `Add-MailboxPermission` transaction). Re-added with
`AutoMapping:$false`, which **persisted**. They have full access but the box does **not**
auto-attach — one-time manual add in Outlook (File → Open & Export → Other User's Folder, or add
`tamra.matthews@cascadestucson.com` as an additional mailbox), **or** flip auto-mapping from an
interactive EXO PowerShell session later (`Add-MailboxPermission … -AutoMapping $true`).
### AutoMapping — all 4 auto-attach (resolved)
- **All four delegates** (Crystal Rodriguez, Ashley Jensen, Megan Hiatt, Meredith Kuhn) have
**FullAccess with AutoMapping** — the shared mailbox auto-attaches in their Outlook and stays
until they remove it.
- **Gotcha encountered + fix:** the first pass added all 4 in a rapid loop with `AutoMapping:$true`;
only Crystal + Ashley persisted — Megan + Meredith rolled back to NONE (cmdlet echoed success).
Cause: rapid sequential AutoMapping writes contend on the *same* `msExchDelegateListLink` attribute
on Tamra's mailbox; the middle writes lost the race and a failed link-write aborts the whole
`Add-MailboxPermission` transaction. **Fix:** re-grant the missing users **one at a time, spaced
(~6-8s), with verify-and-retry** — `Remove-MailboxPermission` → poll until NONE →
`Add-MailboxPermission -AutoMapping $true` → confirm it persists. Both took on the first spaced
attempt. (The literal `msExchDelegateListLink` list is not exposed in the Exchange Operator REST
schema; persistence of an `AutoMapping:$true` grant is the success signal.)
## Actions completed (on-prem AD, CS-SERVER)
- `Set-ADAccountPassword -Reset` (random, vaulted)
@@ -54,9 +57,8 @@
## Open follow-ups
- [ ] **ALIS staff profile** — confirm whether Tamra had ALIS access; if so, disable the staff record
(audit record stays). Her M365 SSO tie is already severed by the sign-in block.
- [ ] **AutoMapping for Megan Hiatt + Meredith Kuhn** — either they add the shared mailbox manually,
or flip `-AutoMapping $true` from an interactive EXO session (the app-based REST path won't
persist it for these two). Crystal + Ashley already auto-attach.
- [x] ~~AutoMapping for Megan Hiatt + Meredith Kuhn~~**RESOLVED 2026-06-30**: re-granted one at a
time (spaced) so AutoMapping persisted. All 4 now auto-attach.
- [ ] **Reconcile** Tamra out of forward-looking plans/rosters. Share roster
`docs/migration/share-group-roster-proposed-2026-06-25.md` already shows her struck-through
*(leaving)*; `docs/servers/active-directory.md` OU=Marketing row updated to disabled +

View File

@@ -0,0 +1,135 @@
## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech
## Session Summary
Offboarded **Tamra Matthews** (Move-In Coordinator, Marketing/Sales) from Cascades of Tucson
after she left the facility in June 2026. Followed the canonical termination runbook
(`docs/security/termination-procedures.md`) and the Alma Montt offboarding (2026-06-25) as the
proven pattern. Work spanned the M365 cloud tenant (via the `remediation-tool` skill) and the
on-prem AD domain controller CS-SERVER (via the `rmm` skill); both passwords were vaulted.
Established live pre-state first: Tamra's M365 object (`tamra.matthews@cascadestucson.com`,
id `2d9cf0d1-2b0b-424e-9cd1-91eaac408837`) is **cloud-only** (`onPremisesSyncEnabled=null`) with a
single O365 Business Standard license and membership in `Sales`, `All Cascades`, and
`SG-SSPR-Eligible`. The on-prem `Tamra.Matthews` is a **separate, non-synced** object in
`OU=Marketing,OU=Departments` with no explicit group memberships. All four mailbox-delegate
recipients (Crystal Rodriguez, Megan Hiatt, Meredith Kuhn, Ashley Jensen) resolved as
UserMailboxes; all three target groups were static (not dynamic), so removable.
Before mutating anything, surfaced one genuine compliance fork to Howard: unlike Alma (no PHI),
Move-In Coordinator is a resident-intake / PHI-adjacent role, so the runbook's 7-yr Litigation
Hold could apply. Howard authorized the **Alma-style posture** — shared-mailbox + zero-deletion,
free the seat, **no litigation hold** (revisit if the PHI determination changes; hold remains
available since the tenant has Business Premium/Exchange Plan 2).
Executed the M365 sequence (revoke sessions, block sign-in, vaulted password reset, convert to
SharedMailbox, grant the 4 delegates FullAccess+AutoMapping, hide from GAL, remove license, strip
3 groups), then the on-prem AD lockdown (reset password, Disable-ADAccount, move to
`OU=Excluded-From-Sync`). Verified every step against live state. Vaulted both passwords, wrote the
offboarding record, reconciled the AD current-state doc + share roster, and synced. Per Howard's
direction, AutoMapping was then fixed for all 4 delegates and a `/save` run before proceeding to a
breach check on Megan Hiatt.
## Key Decisions
- **No litigation hold despite PHI-adjacent role** — Howard explicitly authorized the same
preserve-but-no-hold posture as Alma. Documented the deviation in the offboarding record so the
PHI-role/no-hold decision is auditable.
- **Treated the M365 object as cloud-only and the AD object as separate** — `onPremisesSyncEnabled=null`
confirmed the M365 account is cloud-mastered; the domain lockdown was a distinct operation on
CS-SERVER (same split as Alma).
- **Removed license only AFTER shared-mailbox conversion** — per runbook, so the mailbox is never a
licensed-then-unlicensed user mailbox at risk of default-retention deletion.
- **Fixed AutoMapping by spaced, one-at-a-time re-grants** rather than leaving Megan/Meredith on
manual-add — Howard wanted the box to auto-attach and stay.
## Problems Encountered
- **AutoMapping silently rolled back for 2 of 4 delegates.** The first pass added all 4 in a rapid
loop with `AutoMapping:$true`; the cmdlet echoed `[FullAccess]` for all 4, but a readback showed
only Crystal + Ashley persisted — Megan + Meredith were NONE. Cause: rapid sequential AutoMapping
writes contend on the same `msExchDelegateListLink` multivalued attribute on Tamra's mailbox; a
failed link-write aborts the whole `Add-MailboxPermission` transaction, so the middle writes lost
the race and rolled back entirely. **Resolved** by re-granting one user at a time, spaced ~6-8s,
with `Remove-MailboxPermission` → poll-until-NONE → `Add-MailboxPermission -AutoMapping $true`
verify-persists. Both took on the first spaced attempt. Logged to `errorlog.md` (--friction).
- **Graph read-replica lag** — immediately after `PATCH accountEnabled=false` (HTTP 204), a verify
read still showed `accountEnabled=true`; a re-read seconds later showed false. Not a failure, just
eventual consistency. Same lag bit the Meredith remove (still showed FullAccess right after the
remove), handled with a poll-until-NONE loop.
- **msExchDelegateListLink not readable via REST** — the Exchange Operator REST `Get-Mailbox` schema
doesn't expose the attribute, so AutoMapping can't be directly read; persistence of an
`AutoMapping:$true` grant (no rollback) is the success signal used instead.
## Configuration Changes
- **Created:** `clients/cascades-tucson/docs/security/offboarding-2026-06-30-tamra-matthews.md`
(offboarding record).
- **Created:** `clients/cascades-tucson/session-logs/2026-06/2026-06-30-howard-tamra-matthews-offboarding.md`
(this log).
- **Created (vault):** `clients/cascades-tucson/tamra-matthews.sops.yaml` (encrypted; m365_password +
ad_password + metadata). Committed + pushed to the vault repo.
- **Edited:** `clients/cascades-tucson/docs/servers/active-directory.md` — OU=Marketing Tamra.Matthews
row struck + annotated OFFBOARDED/disabled/Excluded-From-Sync.
- **Edited:** `clients/cascades-tucson/docs/migration/share-group-roster-proposed-2026-06-25.md`
Tamra `(leaving)``(OFFBOARDED 2026-06-30)` (4 lines).
- **Appended:** `errorlog.md` — EXO AutoMapping rollback friction entry.
## Credentials & Secrets
- **Tamra Matthews offboarding passwords** (emergency/audit only; **DO NOT re-enable without
authorization**): vault `clients/cascades-tucson/tamra-matthews` — fields `m365_password`,
`ad_password`. Generated random, complexity-guaranteed; not pasted into chat/tickets. Scratchpad
plaintext was scrubbed after vaulting.
## Infrastructure & Servers
- **M365 tenant:** cascadestucson.com — Tenant ID `207fa277-e9d8-4eb7-ada1-1064d2221498`
- **Tamra M365 object id:** `2d9cf0d1-2b0b-424e-9cd1-91eaac408837` (cloud-only)
- **Removed license SKU:** `f245ecc8-75af-4f8e-b61f-27d8114de5f3` (O365 Business Standard) — seat freed
- **Delegate mailbox GUIDs:** megan.hiatt `448588b1-cb16-41e4-95b3-a496ebf0c7e8`; meredith.kuhn
`02ebe159-818e-4814-a72a-3620dea944a0`
- **Groups removed from:** `Sales` `757e7628-ff38-477c-a5a1-71b27e94d365` (Unified),
`All Cascades` `0344d8ae-bf3c-4b2f-b30b-c9fa93a20aa2` (Unified),
`SG-SSPR-Eligible` `d6044864-a0ef-4c30-ba37-cdba7074437e` (security)
- **On-prem DC:** CS-SERVER (192.168.2.254), `cascades.local`; GuruRMM agent id (live this session)
`c39f1de7-d5b6-45ae-b132-e06977ab1713`. Tamra final DN
`CN=Tamra Matthews,OU=Excluded-From-Sync,DC=cascades,DC=local`, Enabled=False.
- **Remediation apps used:** Security Investigator (`bfbc12a4`, Graph+EXO read), Exchange Operator
(`b43e7342`, EXO write), User Manager (`64fac46b`, Graph user/group/license write), Tenant Admin
(`709e6eed`, password reset — no PAA elevation needed for a non-admin target).
## Commands & Outputs
- Block sign-in: `PATCH /users/{id}` `{"accountEnabled":false}` → HTTP 204 (verify lagged true→false).
- Revoke sessions: `POST /users/{id}/revokeSignInSessions` → HTTP 200.
- Password reset: `reset-password.sh … tamra.matthews …``[OK] no elevation needed` (non-admin).
- Convert shared: EXO `Set-Mailbox -Type Shared``RecipientTypeDetails=SharedMailbox`.
- Grants (final): all 4 `Get-MailboxPermission -User <u>``["FullAccess"]`.
- License remove: `POST /users/{id}/assignLicense` removeLicenses=[f245ecc8…] → 0 licenses.
- Group removes: `DELETE /groups/{gid}/members/{id}/$ref` → 204 ×3.
- AD lockdown (RMM cmd `a788a445…`, exit 0): `Set-ADAccountPassword -Reset` + `Disable-ADAccount` +
`Move-ADObject``Enabled=False`, DN in `OU=Excluded-From-Sync`, Groups=0.
- AutoMapping fix: per-user `Remove-MailboxPermission` → poll NONE → `Add-MailboxPermission -AutoMapping $true`
→ persists (Megan + Meredith, first spaced attempt).
## Pending / Incomplete Tasks
- **ALIS** — Howard handling; unsure Tamra used ALIS. If she had a staff profile, disable it
(M365 SSO tie already severed by the sign-in block).
- **Breach check on Megan Hiatt** — NEXT step this session. Megan's account carried a
`CREDENTIAL_STUFFING_ACTIVE` marker in the April tenant inventory; Howard recalls an April
remediation that should have stopped it — verify it held (`/remediation-tool check megan.hiatt@…`).
- **Litigation hold** — not applied (Howard authorized); revisit only if Tamra's PHI-access
determination or a legal hold changes.
## Reference Information
- Offboarding record: `clients/cascades-tucson/docs/security/offboarding-2026-06-30-tamra-matthews.md`
- Termination runbook: `docs/security/termination-procedures.md`
- Prior offboarding (pattern): `docs/security/offboarding-2026-06-25-alma-montt.md`
- Vault: `clients/cascades-tucson/tamra-matthews`
- Cascades wiki: `wiki/clients/cascades-tucson.md`