Files
claudetools/session-logs/2026-04-21-howard-remediation-vault-gap.md
Howard Enos 924f326e7f sync: auto-sync from ACG-TECH03L at 2026-04-21 08:09:28
Author: Howard Enos
Machine: ACG-TECH03L
Timestamp: 2026-04-21 08:09:28
2026-04-21 08:09:38 -07:00

3.5 KiB

2026-04-21 — Howard: remediation-tool blocked on Cascades (vault gap)

User

  • User: Howard Enos (howard)
  • Machine: ACG-Tech03L
  • Role: tech

TL;DR for Mike

I tried to run the remediation-tool against Cascades (cascadestucson.com) to hunt for spoofed emails. It's blocked on my box — not going to poke at it further, leaving it for you.

Two compounding issues:

  1. Cascades is not consented to the new tiered app suite. Per references/tenants.md, row cascadestucson.com: "Old app only; IdentityRiskyUser not consented". Outstanding since 2026-04-16.

  2. Your new-suite SOPS files are not in the shared vault. get-token.sh expects D:/vault/msp-tools/computerguru-security-investigator.sops.yaml (and peers). On ACG-Tech03L, D:/vault/msp-tools/ only has:

    • acg-msp-access-google-workspace.sops.yaml
    • autotask.sops.yaml
    • cipp.sops.yaml
    • claude-msp-access-graph-api.sops.yaml (the old deprecated app fabb3421)
    • screenconnect.sops.yaml
    • syncro.sops.yaml

    The five new-tier files (computerguru-security-investigator|exchange-operator|user-manager|tenant-admin|defender-addon.sops.yaml) are missing.

What the token script actually returned

$ bash C:/claudetools/.claude/skills/remediation-tool/scripts/get-token.sh cascadestucson.com investigator
ERROR: vault file not found: D:/vault/msp-tools/computerguru-security-investigator.sops.yaml

$ bash C:/claudetools/.claude/skills/remediation-tool/scripts/get-token.sh cascadestucson.com investigator-exo
ERROR: vault file not found: D:/vault/msp-tools/computerguru-security-investigator.sops.yaml

(Same error for all tiers since the whole new-suite directory is absent.)

What I did manage to check (public DNS only)

Full report at clients/cascades-tucson/reports/2026-04-21-spoofing-hunt.md. One real finding worth flagging even without Graph/EXO access:

DMARC reporting is a blind spot. _dmarc.cascadestucson.com has:

rua=mailto:info@cascadestucson.com
ruf=mailto:info@cascadestucson.com

Aggregate + forensic DMARC reports flow into an internal mailbox nobody is parsing. If someone is actively spoofing their domain, we have zero visibility. Fix is one DNS change pointing rua at a DMARC aggregator (dmarcian / EasyDMARC / Valimair — free tiers cover their volume).

Other public posture is fine: SPF strict -all with only spf.protection.outlook.com + our ix.azcomputerguru.com authorized, both M365 DKIM selectors published, no obvious lookalike domains registered (checked 6 common variants).

What I need from you

Pick your preferred unblock:

  • Option A (preferred — unblocks every tenant on my box): Commit the five new-tier SOPS files from your vault to the shared vault repo and push. Then I pull and any future remediation-tool work from my machine just works.
  • Option B: Consent Security Investigator in Cascades (URL in the report), but Option A is still needed for me to actually acquire a token.

What I did not touch (on purpose)

  • Did NOT modify get-token.sh to handle the old app — would've been a workaround that pushes against the stated migration direction.
  • Did NOT attempt to use claude-msp-access-graph-api.sops.yaml (the old app) even though its secret is in my vault.
  • Did NOT send any consent URL to Cascades.
  • Did NOT change DNS for DMARC reporting — flagged as a separate action item in the report.

Artifacts

  • Report: clients/cascades-tucson/reports/2026-04-21-spoofing-hunt.md
  • This log: session-logs/2026-04-21-howard-remediation-vault-gap.md