remediation-tool: document the 365 app suite + build consent-audit

Root-caused the recurring '365 suite isn't documented' pain: the apps are fine (tiered by
privilege) but per-tenant consent is NOT uniform and there was no way to see a tenant's
actual grant state. VWP had the Tenant Admin app but no SharePoint app-only role -> silent
401s until this session.

- references/app-suite.md: authoritative, live-verified map of every app, App ID, and
  actually-granted permission per tier; the consent-drift problem + both fix methods
  (adminconsent URL, direct appRoleAssignment grant).
- scripts/consent-audit.sh: audits a tenant (or --all) vs the baseline, grades
  GREEN/AMBER/RED, prints the exact fix per gap. Extends the assign-exchange-role --verify
  pattern to Graph scopes + SharePoint role + EXO role. Verified: BirthBio GREEN, VWP/Cascades
  AMBER (caught real drift - both missing grants).
- SKILL.md: run consent-audit FIRST on any tenant task. Memory + errorlog correction.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
2026-07-02 15:13:21 -07:00
parent 42da3cfcca
commit 8152476ee4
6 changed files with 447 additions and 0 deletions

View File

@@ -204,4 +204,5 @@
- [GuruScan verification IN TEST / paused](project_guruscan_in_test_paused.md) — multi-engine scanner verify on DESKTOP-MS42HNC paused 2026-06-22 (VM rebooted mid-Emsisoft run); HitmanPro done (36 removed), Emsisoft full-scan unverified; resume `guruscan-agent-test.sh DESKTOP-MS42HNC scan-one Emsisoft`; Defender RTP/Tamper still off on VM
- [GuruRMM fleet dispatch-hang fix](project_gururmm_dispatch_hang_fix.md) — blocking send_to on a full bounded channel to one black-holed agent wedged ALL command dispatch; fixed with try_send (9dae20c, deployed); proper black-hole eviction still missing (was reverted in 80df458) — finish it if it recurs
- [Windows won't-boot / offline DISM repair playbook](windows-offline-dism-repair-gotchas.md) — Automatic Repair loop = boot-critical fault (disk/registry/wedged update), NOT shell/appx store corruption (that's a symptom); `FaultyPackageInProgress` + 100s of Install/Uninstall-Pending packages = wedged CU -> RevertPendingActions or clean install. Offline DISM rejects `wim:` source (0x800f082e) -> MOUNT the wim, source `\Windows`. Ventoy breaks WIM mount (0xc1420134) -> use Rufus. 25H2(26200)=24H2(26100)+enablement, so match 26100 media. First hit: Four Paws AvImark #32447.
- [365 app suite — authoritative map + consent-drift fix](reference_365_app_suite.md) — full map in `.claude/skills/remediation-tool/references/app-suite.md`; per-tenant consent is NOT uniform (VWP had the app but no SharePoint role). Run `consent-audit.sh <tenant|--all>` to detect gaps; fix via adminconsent URL or direct appRoleAssignment grant.
- [Remediation-tool has full M365 access (incl. SharePoint)](reference_remediation_tool_365_access.md) — the app suite covers Graph/EXO/Defender/SharePoint; don't declare "no access" on an accessDenied. SharePoint app-only needs a CERT (secret = "Unsupported app only token"); use get-token.sh `sharepoint`/`sharepoint-admin` tiers + CSOM admin API (Graph /admin/sharepoint/settings scope not held). Full map: skill references/app-permissions-and-sharepoint.md.

View File

@@ -0,0 +1,32 @@
---
name: reference_365_app_suite
description: Authoritative map of the ComputerGuru M365 app suite (apps, App IDs, live-verified permissions per tier) and — the recurring failure — per-tenant consent is NOT uniform; how to audit + fix partial consent.
metadata:
type: reference
---
The ComputerGuru M365 app suite is fully documented in the remediation-tool skill:
`.claude/skills/remediation-tool/references/app-suite.md` (authoritative; live-verified
2026-07-02). Read it before concluding "the tool can't do X on tenant Y".
**The recurring failure it fixes:** per-tenant consent is NOT uniform. A tenant can have an
app's service principal but only a PARTIAL/OLD permission grant. Example: VWP
(valleywideplastering.com, 5c53ae9f-…) had the Tenant Admin app but NO SharePoint
`Sites.FullControl.All` — SharePoint calls 401'd with a valid-looking token whose `roles`
claim was empty. The suite "having" a capability (baseline design) ≠ a given tenant having it
(actual consent).
**Always AUDIT before giving up:** decode each tier's token `roles` on the target tenant and
compare to the baseline in app-suite.md. Empty roles on a correct `aud` = present-but-not-granted.
**Fix partial consent — two methods:**
- A: re-consent the whole manifest — `https://login.microsoftonline.com/<tenant>/adminconsent?client_id=<app-id>` (reliably grants Graph; the SharePoint app-only role often does NOT attach from consent — verify + use B for the leftover).
- B: grant the specific missing app role directly via `POST /servicePrincipals/{recipientSP}/appRoleAssignments` using a `tenant-admin` token (holds AppRoleAssignment.ReadWrite.All). This is how VWP's SharePoint role was granted 2026-07-02; propagates to a fresh token in seconds. Only to complete an intent the customer already consented to.
- EXO role gap: `assign-exchange-role.sh <domain>` (audit fleet: `--all --verify`).
Apps: Security Investigator bfbc12a4 (Graph read + EXO read), Exchange Operator b43e7342
(EXO all-access + `exchange-op-graph` Graph Mail.ReadWrite), User Manager 64fac46b (Graph
user/group write), Tenant Admin 709e6eed (Graph high-priv + SharePoint Sites.FullControl.All
via CERT), Defender dbf8ad1a (MDE), Intune 46986910, Mailbox 1873b1b0 (ACG-internal only).
SharePoint app-only REQUIRES cert (not secret). See [[reference_remediation_tool_365_access]],
[[feedback_exchange_role_recurring_gap]], [[feedback_exchange_op_all_access]].