claudetools/.claude/memory/reference_365_app_suite.md at c18e74ed1c4aa2afaa126b7d99e1e1c4fed46b68

Files

Mike Swanson 8152476ee4 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>

2026-07-02 15:15:08 -07:00

2.4 KiB

Raw Blame History

name, description, metadata

name

description

metadata

reference_365_app_suite

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.

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.

2.4 KiB Raw Blame History

2.4 KiB

Raw Blame History