sync: auto-sync from ACG-TECH03L at 2026-04-19 12:50:13

Author: Howard Enos
Machine: ACG-TECH03L
Timestamp: 2026-04-19 12:50:13

.claude/messages/for-howard.md

@@ -4,50 +4,4 @@ Check this file at sync. Delete items after you've addressed them.
 
 ---
 
-## 2026-04-18 — GuruRMM is now a git submodule
-
-The `projects/msp-tools/guru-rmm/` folder is no longer tracked as regular
-files in claudetools. It is now a git submodule pointing to the live gururmm
-Gitea repo. You need to initialize it on ACG-TECH03L.
-
-**Run this once after pulling:**
-
-```bash
-cd D:/claudetools   # or wherever your claudetools checkout is
-git submodule update --init projects/msp-tools/guru-rmm
-```
-
-This clones the full gururmm repo into that folder. After that, pulling
-claudetools will NOT automatically update the submodule — you need to
-run this to get the latest gururmm code:
-
-```bash
-git submodule update --remote projects/msp-tools/guru-rmm
-```
-
-**Working on gururmm code going forward:**
-
-```bash
-cd projects/msp-tools/guru-rmm   # this is now its own repo
-git pull                          # get latest
-# make changes, commit, push as normal
-cd ../../../                      # back to claudetools root
-git add projects/msp-tools/guru-rmm
-git commit -m "chore: update gururmm submodule pointer"
-```
-
-**Why this changed:**
-
-The old copy in claudetools was drifting behind the live repo on the server.
-Features were being built in the gururmm repo that session logs in claudetools
-marked as "Done" — causing context loss between sessions. Submodule means
-one source of truth.
-
-**Gitea credentials** for the submodule are stored in your local git config,
-not in .gitmodules. If the submodule can't authenticate, run:
-
-```bash
-git config --local submodule."projects/msp-tools/guru-rmm".url \
-  "https://azcomputerguru:Gptf%2A77ttb123%21%40%23-git@git.azcomputerguru.com/azcomputerguru/gururmm.git"
-git submodule sync
-```
+*No pending messages.*

.claude/messages/for-mike.md

@@ -0,0 +1,42 @@
+# Note for Mike
+
+## From Howard, 2026-04-19
+
+### Cascades of Tucson - M365 Remediation App - Identity Protection scope
+
+During today's phishing investigation on Cascades of Tucson (crystal.rodriguez, et al.), the 10-point breach check returned `Forbidden` on `/identityProtection/riskyUsers` and `/identityProtection/riskDetections` because **Claude-MSP-Access (ComputerGuru - AI Remediation, App ID `fabb3421-8b34-484b-bc17-e46de9703418`) lacks admin consent for `IdentityRiskyUser.Read.All` on the Cascades tenant.**
+
+**Asking before I grant:** should I go ahead and give this consent, or do you want to hold off?
+
+#### What the scope does
+
+- **Read-only.** Reads Entra ID Identity Protection signals: risky-user state (low/medium/high), and the underlying risk detections (impossible travel, anonymous IP, leaked credentials, malware-linked IP, etc.).
+- **No write capability** - not `ReadWrite.All`, just `Read.All`. The app cannot reset risk state, dismiss detections, or modify anything in Identity Protection.
+- **Tenant-scoped.** Consent applies only to the Cascades tenant; doesn't affect other clients.
+
+#### Why I want it
+
+- Closes a visibility gap in our standard breach-check workflow. Today I had to tell the report "this check skipped" for risky-user signals.
+- Saves us from logging into the Defender / Entra portal manually during IR to cross-check.
+- Cascades has Defender P1+ (based on targeted-user protection already configured), so risk data exists to read.
+
+#### Why you might say no
+
+- Every additional scope on the app = larger blast radius if the app's client secret/cert leaks.
+- Scope is persistent until revoked via the portal.
+- Identity Protection data can include sensitive info (IPs, geo, device hints). If our audit logging is weak, reading it leaves tracks we should be aware of.
+
+#### My lean
+
+**Allow it.** The scope is read-only, the app is narrowly controlled (only us), and we already have Mail.Read, User.Read.All, Exchange Admin, etc. — which are materially more sensitive than this. The inconsistency of "we can read full mailbox contents but not risky-user flags" doesn't match a risk-based model.
+
+If you say yes, consent URL is:
+```
+https://login.microsoftonline.com/207fa277-e9d8-4eb7-ada1-1064d2221498/adminconsent?client_id=fabb3421-8b34-484b-bc17-e46de9703418
+```
+
+Takes ~30 seconds. Sign in as a GA on Cascades' tenant (sysadmin@ works), review the permission, click Accept.
+
+Full investigation report: `clients/cascades-tucson/reports/2026-04-19-crystal-rodriguez-phish-investigation.md`
+
+- Howard