azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from GURU-5070 at 2026-06-25 21:13:47

Browse Source 
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-25 21:13:47
This commit is contained in:
Mike Swanson
2026-06-25 21:14:53 -07:00
parent cf960d1b2a
commit 730d26437b
7 changed files with 174 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
.claude/memory/MEMORY.md
View File

@@ -2,6 +2,9 @@
## Reference
- [ACG resource map](reference_resource_map.md) — **READ THIS FIRST** when a task references a server/service/tenant/API. What we have access to, how to connect from this machine, per-machine exceptions, gotchas. Points at the detail files below.
- [exchange-op = all-access Exchange tier](feedback_exchange_op_all_access.md) — STOP claiming "no tier can write mail." Exchange Operator app = Exchange Admin role + full_access_as_app + Exchange.ManageAsApp = full all-access (move mail, rules, config, EWS). Default to `exchange-op` for any Exchange write.
- [Tedards tenant facts](reference_tedards_tenant_facts.md) — Bill Tedards law office; tenant `4fcbb1f4…`; bt@/y226@ mailboxes; matter-number filing; UAL ingestion OFF; 9 synced devices; botched-import DUPLICATE folder.
- [Investigator EXO ManageAsApp gap](reference_investigator_exo_manageasapp_gap.md) — Security Investigator app lacks `Exchange.ManageAsApp` (only `full_access_as_app`) so `investigator-exo` 401s on EXO adminapi; use `exchange-op` tier for InvokeCommand.
- [Tailscale subnet-route key expiry](reference_tailscale_subnet_key_expiry.md) — "internet OK but all of 172.16.3.x (Gitea .20, RMM/coord .30) dead" = Tailscale infra-node KEY EXPIRY (pfSense subnet router advertises 172.16.0.0/22), NOT a LAN outage; expiry now disabled on infra nodes (2026-06-25). Fallback: gururmm-server direct at tailnet 100.86.12.15:3001.
- [GravityZone support center](reference_gravityzone_support.md) — Authoritative Bitdefender GravityZone product + Public API docs; use to confirm UNVERIFIED `bitdefender` skill methods/param shapes (push setPushEventSettings, assignPolicy, report/account writes, maintenancewindows/integrations names).
- [GURU-5070 Rust toolchain](reference_guru5070_rust_toolchain.md) — GURU-5070 now has cargo + MSVC + protoc; build/clippy/test guru-connect LOCALLY (set PROTOC to the winget path) instead of the build host. CI only clippy-checks the Linux server, not the Windows agent.

12
.claude/memory/feedback_exchange_op_all_access.md Normal file
View File

@@ -0,0 +1,12 @@
---
name: feedback_exchange_op_all_access
description: The exchange-op tier is the all-access Exchange tier — stop claiming "no tier can write mail"
metadata:
type: feedback
---
The **`exchange-op`** tier (ComputerGuru **Exchange Operator** app, `b43e7342-5b4b-492f-890f-bb5a4f7f40e9`) holds the **Exchange Administrator** directory role PLUS `full_access_as_app` and `Exchange.ManageAsApp`. That is **full all-access to every mailbox and every Exchange Online operation** — reading, writing, moving mail, inbox rules, message trace, TABL, audit config, EWS, the lot.
**Why:** Mike's recurring correction (2026-06-25) — I keep claiming "no app tier has Mail.ReadWrite, so I need a workaround" and reaching for convoluted paths (EWS gymnastics, etc.). That framing is wrong and wastes time EVERY time. Graph application Mail.ReadWrite is not the only write path; the Exchange Operator app already has full Exchange admin rights.
**How to apply:** For ANY mailbox/Exchange write or all-access need (move/copy/delete mail, modify rules, change mailbox config, EWS operations, audit settings), default to the **`exchange-op`** tier. Never declare a task blocked for lack of mail-write permission without first using exchange-op. The Graph `investigator` tier is read-only (`Mail.Read`); `investigator-exo` lacks `Exchange.ManageAsApp` (see [[reference_investigator_exo_manageasapp_gap]]) — neither limitation means "we can't write," it just means use exchange-op. See [[reference_tedards_tenant_facts]].

12
.claude/memory/reference_investigator_exo_manageasapp_gap.md Normal file
View File

@@ -0,0 +1,12 @@
---
name: reference_investigator_exo_manageasapp_gap
description: Why the remediation-tool investigator-exo tier 401s on EXO adminapi; use exchange-op instead
metadata:
type: reference
---
The **Security Investigator** app (`bfbc12a4-f0dd-4e12-b06d-997e7271e10c`) registration grants only the `full_access_as_app` (EWS) Office 365 Exchange Online app role — it is **missing `Exchange.ManageAsApp`**. The EXO REST admin API (`outlook.office365.com/adminapi/beta/{tid}/InvokeCommand` — Get-Mailbox, Get-InboxRule, Search-UnifiedAuditLog, etc.) requires `Exchange.ManageAsApp`, so the `investigator-exo` token returns **401** on every cmdlet.
The Exchange Administrator **directory role** is NOT the cause — it is already assigned to the Investigator SP. The gap is the **API permission** on the app registration, which is a manual Entra portal change (suite rule: app registrations stay manual) and arguably shouldn't be added to the read-only Investigator at all.
**How to apply:** for any EXO `InvokeCommand` work (mailbox reads, inbox rules, message trace, TABL, audit), use the **`exchange-op`** tier — the **Exchange Operator** app (`b43e7342-5b4b-492f-890f-bb5a4f7f40e9`) carries BOTH `full_access_as_app` and `Exchange.ManageAsApp`. Don't waste a round trip on `investigator-exo` for adminapi. See [[reference_tedards_tenant_facts]].

16
.claude/memory/reference_tedards_tenant_facts.md Normal file
View File

@@ -0,0 +1,16 @@
---
name: reference_tedards_tenant_facts
description: Tedards (Bill Tedards law office) M365 tenant facts for investigations
metadata:
type: reference
---
**Tedards** = Bill Tedards law office. M365 tenant `tedards.net`, tenant ID `4fcbb1f4-fbf9-4548-a93e-7d14a3c091e6`. Registry lists Onboarded=NO but the ComputerGuru apps ARE consented and working (Graph investigator + EXO exchange-op both verified live 2026-06-25).
Mailboxes: `bt@tedards.net` (Bill, owner), `y226@tedards.net` (Yvonne). Bill files mail by legal matter number into deep Inbox subfolders (e.g. "8445 BOLTON [Farmers TX]", "BOLTON, Lindsay"); a top-level "DUPLICATE need to check" folder (~11,864 items) is junk from a **botched mail import years ago** — ignore it.
Security gaps found 2026-06-25: tenant was **dehydrated** (never customized) — ran `Enable-OrganizationCustomization` (irreversible, one-time) then `Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true` (both HTTP 200). Read-back still showed `false` immediately after — propagation lag; verify later that it flipped to true and that Search-UnifiedAuditLog starts returning data (ingestion lag up to ~60min). Before this, UAL was OFF so there was no queryable audit trail for the bt@ deletions. bt@ mailbox syncs to **9 devices** (5 aging iOS Mail/EAS, a Mac Outlook, 2 Outlook-for-iOS added 2026-06-25). Per-mailbox AuditEnabled=true but not queryable since Search-MailboxAuditLog is deprecated + UAL ingestion off.
EXO access: use the `exchange-op` tier, not `investigator-exo` — see [[reference_investigator_exo_manageasapp_gap]]. Ongoing matter: Wirechunk/agencyzoomify.com DMARC + the bt@ "delete folder" deletions (ticket #5070, #32228).
**bt@ "delete folder" mystery — SOLVED 2026-06-26 (root cause = client-side device auto-delete).** Lindsay's (lindsay@agencyzoomify.com) Bolton-thread mail auto-moves to Deleted Items. Proven via bait test: restored the 3 msgs to Inbox via EWS, all 3 were re-deleted to Deleted Items at the identical instant (02:54:24Z) — automated, not human. Eliminated: inbox rules (incl. hidden), sweep rules, transport rules, forwarding, delegates, folder perms, and any OAuth app with Mail.ReadWrite (none exist; admin apps only have MailboxSettings.ReadWrite/Mail.Send/Exchange.Manage). Only mail-MOVE capability present = Apple native iOS Mail (appId 32f67a9b, EAS+EWS) + Outlook-for-iOS. 5 Apple/Outlook-iOS devices push-synced within 8s of the re-delete; all activity from Bill's single home IP 69.242.239.94 (NOT a compromise). Bisection test (2026-06-26 03:23): removed/disabled Outlook-for-iOS, re-moved msgs to Inbox — re-deleted again in 4s, AND the re-delete (03:23:31Z) fired BEFORE the Outlook-iOS clients re-synced (03:23:38/48) → **Outlook-iOS EXONERATED; culprit = a NATIVE iOS Mail (EAS) device** with on-device "Block Sender → Move to Trash" for lindsay@agencyzoomify.com. Narrowed to the two devices syncing at the delete instant: **iPhone16C2** and **iPad15C8** (Bill's current iPhone + iPad). On-device block list is NOT server-readable — Bill must remove Lindsay from Blocked on those devices (iOS Settings → Mail → Blocked). Note: Set-CASMailbox OutlookMobileEnabled has heavy propagation lag (didn't enforce during the test window); same lag seen on Set-AdminAuditLogConfig. To pin the exact one device, block one EAS DeviceId and re-bait. Removed 2 Outlook-iOS partnerships (they auto-re-add) + toggled OutlookMobileEnabled (reverted to true, queued).