Howard Enos
96ad4b7059
Intune Manager (46986910-...) registered as AzureADMyOrg instead of AzureADMultipleOrgs, blocking consent in any external tenant. Includes evidence, PATCH command, and portal steps. Blocks Cascades MDM Phase B. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
81 lines
4.8 KiB
Markdown
81 lines
4.8 KiB
Markdown
# Note for Mike
|
|
|
|
Check this file at sync. Delete items after you've addressed them.
|
|
|
|
---
|
|
|
|
## From Howard, 2026-04-22 — Per-user Syncro keys (attribution fix)
|
|
|
|
I hit the issue that my Syncro comments/line items on ticket #32179 were getting logged as you (user_id 1735) because we share your API key. Fixed it with per-user tokens:
|
|
|
|
- Generated my own Syncro API token (Custom, admin, indefinite) → `user_id 1750`
|
|
- Added vault entry: `msp-tools/syncro-howard.sops.yaml`
|
|
- Patched `.claude/commands/syncro.md` to pick the key from `identity.json`'s `user` field, falls back to the shared `msp-tools/syncro.sops.yaml` if no per-user file exists
|
|
- Verified `/me` now returns Howard Enos on my machine
|
|
|
|
**When you get a chance** (after Valleywide settles), do the same for yourself so the shared key can be retired:
|
|
|
|
1. Syncro → Admin → API Tokens → New (integration or custom, full scopes)
|
|
2. `cat > $VAULT_ROOT/msp-tools/syncro-mike.sops.yaml <<YAML ... YAML` (template in the patched syncro.md)
|
|
3. `cd $VAULT_ROOT && sops --encrypt --in-place msp-tools/syncro-mike.sops.yaml`
|
|
4. Commit + push vault. The skill will pick it up automatically on your next sync.
|
|
|
|
After your key is in place we can delete `msp-tools/syncro.sops.yaml` (shared). Until then the skill warns on stderr when it falls back to the shared key.
|
|
|
|
---
|
|
|
|
## From Howard, 2026-04-22 — Ack: intune-manager + rates
|
|
|
|
Pulled vault (got `ebdd711` + `1c837ba`). intune-manager vault file loads fine now. Tried a token against grabblaw.com — returns `AADSTS700016` (app not consented in that tenant). Same category as the `defender` case, tenant-onboarding work, not a code bug. No action needed from you.
|
|
|
|
Rates reply on Syncro — understood, will omit `price_retail` going forward. Saw the syncro.md update.
|
|
|
|
Good luck with Valleywide — saw the NVRAM corruption log. Holler if you need a hand with anything from here.
|
|
|
|
---
|
|
|
|
## From Howard, 2026-04-22 — Intune Manager app is single-tenant (correction to earlier ack)
|
|
|
|
**TL;DR:** `ComputerGuru - Intune Manager` (`46986910-aa47-4e5e-b596-f65c6b485abb`) was registered with `signInAudience: AzureADMyOrg`. No external tenant can consent it. Needs a one-field PATCH to `AzureADMultipleOrgs`. Every other MSP app is already multi-tenant.
|
|
|
|
**Evidence** (pulled today via Management app):
|
|
|
|
```
|
|
AzureADMultipleOrgs Security Investigator
|
|
AzureADMultipleOrgs Exchange Operator
|
|
AzureADMultipleOrgs User Manager
|
|
AzureADMultipleOrgs Tenant Admin
|
|
AzureADMultipleOrgs Defender Add-on
|
|
AzureADMyOrg Intune Manager <-- the odd one
|
|
```
|
|
|
|
**Correcting my earlier ack above:** I chalked the grabblaw `AADSTS700016` up to "app not consented in that tenant — same category as defender." That diagnosis was wrong. `700016` at the `/adminconsent` endpoint itself (not just at the token endpoint) means the app is invisible to the external tenant's directory — i.e., the audience blocks it before any consent UI even loads. Verified today against Cascades (207fa277-e9d8-4eb7-ada1-1064d2221498) with `admin@cascadestucson.com` — same 700016 straight from the sign-in screen.
|
|
|
|
**Current impact:** I'm blocked on Cascades MDM phone setup. Can't get a read on what Intune policies/configs/apps already exist on their tenant without this app working. Falling back to portal clicks with Howard, but that's slower and leaves us with no scripted state checks going forward.
|
|
|
|
**Fix** — one PATCH call against the app object in your home tenant:
|
|
|
|
```bash
|
|
# Via Management app token (you already have this pattern in patch-tenant-admin-manifest.sh)
|
|
curl -X PATCH -H "Authorization: Bearer $MGMT_TOKEN" \
|
|
-H "Content-Type: application/json" \
|
|
"https://graph.microsoft.com/v1.0/applications/31017446-c01a-4775-864f-aef96ce43797" \
|
|
-d '{"signInAudience": "AzureADMultipleOrgs"}'
|
|
```
|
|
|
|
Or in the portal: Entra → App registrations → ComputerGuru - Intune Manager → Authentication → **Supported account types** → pick "Accounts in any organizational directory (Any Microsoft Entra ID tenant - Multitenant)" → Save.
|
|
|
|
**Why I'm not doing it myself:** Howard said no changes to your apps without you in the loop ("it was working and now its not, i dont want to make a bunch of changes"). Ball's in your court — takes ~30 seconds.
|
|
|
|
**After you flip it, I'll:**
|
|
1. Re-click the consent URL with Cascades GA, create the SP + grant scopes
|
|
2. Run the Intune readout against Cascades
|
|
3. Continue Phase B MDM work with Howard
|
|
|
|
**Possibly related followups** while you're in there:
|
|
- `onboard-tenant.sh` still only auto-consents the original 5 apps. Needs `intune-manager` added so future tenants onboard cleanly.
|
|
- `references/tenants.md` consent URL section doesn't have an Intune Manager template yet.
|
|
- `SKILL.md` tier table lists 6 tiers, actual is 7.
|
|
|
|
All three are documentation/script updates, happy to do those myself once the audience is flipped. Let me know.
|