Session work 2026-05-04: Grabb Leap calendar fix, Dataforth lobby phone VLAN, IMC printer + VPN
- Grabb & Durando: investigated and resolved Svetlana Larionova's Leap-to-M365 calendar OAuth consent issue (Graph-side report + session log). Syncro #32245. - Dataforth: lobby phone (ext 201) was offline due to D1-Server-Room port 1 being on the wrong VLAN; reconfigured to VLAN 100, phone re-provisioned and registered. Session log + PROJECT_STATE update. Syncro #32246. - Instrumental Music Center: Station 2 receipt printer reconnect + VPN install on Manda's machine. Syncro #32247. - Memory: generalized the Syncro blank-contact rule (was Cascades-only) and added the labor-type rule (never use "Prepaid project labor") per Winter's 2026-05-04 corrections. - Gitignored `.claude/tmp/` so per-session helper scripts don't sneak in. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -0,0 +1,115 @@
|
||||
# LEAP Calendar Sync Permission Investigation — slarionova@grabblaw.com
|
||||
|
||||
**Date (UTC):** 2026-05-04
|
||||
**Tenant:** grabblaw.com (`032b383e-96e4-491b-880d-3fd3295672c3`) — Grabb & Durando, P.C.
|
||||
**User:** Svetlana Larionova (`slarionova@grabblaw.com`, `affab40c-5535-4c1a-9a78-a2eda1a4a3b7`)
|
||||
**Issue:** "Not able to add calendar event from Leap to M365 — no admin permissions"
|
||||
**Investigator:** Howard Enos (read-only Graph via Security Investigator app)
|
||||
|
||||
---
|
||||
|
||||
## TL;DR
|
||||
|
||||
**She does NOT need an M365 admin role.** The error is a misnamed OAuth consent block — Leap's sign-in app asks for scopes (Mail.ReadWrite, Mail.Send, Files.ReadWrite.All) that the tenant's user-consent policy classifies as "high-risk" and reserves for admin approval. Five of her co-workers (4 with no admin roles at all, 1 with User Administrator) already have these grants because an admin previously approved them per-user. She just needs the same per-user approval — not an elevated role.
|
||||
|
||||
**Recommended fix:** Have Svetlana run through Leap's M365 connect again and click "Request approval from your administrator." Then approve the request in Entra → Enterprise Applications → Admin consent requests, scoped to her user only.
|
||||
|
||||
---
|
||||
|
||||
## Findings
|
||||
|
||||
### 1. User account is healthy
|
||||
- Account enabled: `true`
|
||||
- License: `O365_BUSINESS_PREMIUM` (Exchange, SharePoint, Teams all enabled)
|
||||
- Mailbox settings reachable (English-US, MST timezone, autoreply off)
|
||||
- Group memberships: only `Grabb & Durando, P.C.` distribution group
|
||||
- **Directory roles: NONE** (correctly, no admin role)
|
||||
- Existing OAuth grants: **0**
|
||||
|
||||
### 2. Two LEAP service principals are registered in this tenant
|
||||
|
||||
| App ID | Display | Role | Consent state |
|
||||
|---|---|---|---|
|
||||
| `5602fc50-4c30-4faa-a595-e5a0f15d2cce` | LEAP (service) | App-only/daemon — runs as the app, not a user | Tenant-wide app-permission consent already granted (Calendars/Mail/Files via Application roles on Graph + EXO + SharePoint) |
|
||||
| `a7d19842-33e2-457b-a399-d4e6ec010f0a` | LEAP (delegated) | User sign-in — runs as the signed-in user | Per-user (`consentType=Principal`) grants for 5 users only |
|
||||
|
||||
### 3. The 5 users who already have working Leap calendar sync
|
||||
|
||||
| User | Admin role? |
|
||||
|---|---|
|
||||
| jsosa@grabblaw.com (Jeannette Sosa) | None |
|
||||
| rpesqueira@grabblaw.com (Reyna Pesqueira) | None |
|
||||
| avazquez@grabblaw.com (Ana Vazquez) | None |
|
||||
| yheredia@grabblaw.com (Yvette Heredia) | None |
|
||||
| jwilliams@grabblaw.com (Jeff Williams) | User Administrator (incidental) |
|
||||
|
||||
Each holds a `Principal`-type OAuth grant on the LEAP delegated app with the full scope set:
|
||||
|
||||
```
|
||||
Calendars.Read Calendars.ReadWrite Mail.Read Mail.ReadWrite Mail.Send
|
||||
Contacts.Read Tasks.Read Tasks.ReadWrite OnlineMeetings.ReadWrite
|
||||
ChannelMessage.Send ChannelMessage.Edit Chat.Create Chat.ReadWrite
|
||||
ChatMessage.Send Files.ReadWrite.All User.Read User.ReadBasic.All
|
||||
offline_access email profile openid
|
||||
```
|
||||
|
||||
The per-user grant is what makes Leap → calendar work. **No admin role is required to hold the grant.**
|
||||
|
||||
### 4. Tenant user-consent policy
|
||||
|
||||
`policies/authorizationPolicy` shows:
|
||||
- `permissionGrantPoliciesAssigned`:
|
||||
- `ManagePermissionGrantsForSelf.microsoft-user-default-recommended`
|
||||
- `ManagePermissionGrantsForSelf.microsoft-user-default-allow-consent-apps`
|
||||
|
||||
Under the **recommended** baseline, users may self-consent to apps from verified publishers, but only for "low-risk" delegated permissions. `Mail.ReadWrite`, `Mail.Send`, `Files.ReadWrite.All` are explicitly classified as **not** low-risk → admin approval required. This is what produces the "no admin permissions" message in Leap.
|
||||
|
||||
### 5. Why she's the only one stuck
|
||||
|
||||
She was hired/onboarded after the previous batch of 5 users was approved. The other consents were granted point-in-time (per-user), so a new user has to go through the same approval again. This is not a policy regression — it's the steady-state pattern in this tenant.
|
||||
|
||||
---
|
||||
|
||||
## Recommended Fix (least-privilege)
|
||||
|
||||
### Option A — Admin Consent Request (preferred, matches existing pattern)
|
||||
|
||||
1. Have Svetlana sign in to Leap, click **Connect to Microsoft 365 / Enable calendar sync**.
|
||||
2. When she hits the "approval required" page, she clicks **Request approval from your administrator** and submits a short justification.
|
||||
3. The admin (`sysadmin@grabblaw.com` or the `guru@grabblaw.com` Global Admin) approves at:
|
||||
`https://entra.microsoft.com → Identity → Applications → Enterprise applications → Admin consent requests`
|
||||
4. Choose **Approve for this user only** (this matches what the other 5 employees have).
|
||||
5. Leap calendar sync starts working immediately.
|
||||
|
||||
Net effect: a single new `oauth2PermissionGrant` row tied to her object ID with `consentType=Principal`. No role change. No tenant-wide impact.
|
||||
|
||||
### Option B — Switch to tenant-wide admin consent (broader, easier going forward)
|
||||
|
||||
If new hires keep tripping over this, an admin can grant the LEAP delegated app **tenant-wide** consent once:
|
||||
|
||||
`https://entra.microsoft.com → Enterprise applications → LEAP (appId a7d19842-33e2-457b-a399-d4e6ec010f0a) → Permissions → Grant admin consent for Grabb & Durando`
|
||||
|
||||
Trade-off: ALL users get those scopes automatically (including new hires). The existing pattern in this tenant is per-user, so this is a deliberate change in posture — not a fix. Worth considering if Leap is the firm's standard practice management tool and everyone needs it.
|
||||
|
||||
### What NOT to do
|
||||
|
||||
- Do **not** assign her any directory role (Global Admin, Exchange Admin, etc.). It would not fix this — the error is OAuth consent, not RBAC. A user with no admin role can hold the grant, as 4 of the 5 working users prove.
|
||||
|
||||
---
|
||||
|
||||
## Evidence Artifacts
|
||||
|
||||
Raw JSON in `/tmp/remediation-tool/032b383e-96e4-491b-880d-3fd3295672c3/sla-check/`:
|
||||
- `user.json` — slarionova profile + license
|
||||
- `memberOf.json`, `transitive.json` — group/role membership (no admin roles)
|
||||
- `grants.json` — her OAuth grants (empty)
|
||||
- `sp-leap.json` — both LEAP SPs found in tenant
|
||||
- `sp-{spid}-grants.json` (via direct query) — current consent state on each LEAP SP
|
||||
- `skus.json` — license definitions
|
||||
- `ga-role.json`, `exo-role.json` — directory role lookups
|
||||
|
||||
## Tools used
|
||||
|
||||
- App tier: `investigator` (Graph read-only) — `bfbc12a4-f0dd-4e12-b06d-997e7271e10c`
|
||||
- Auth: cert (client_assertion JWT) via `get-token.sh`
|
||||
- No write actions performed.
|
||||
@@ -0,0 +1,72 @@
|
||||
# Grabb & Durando — Leap M365 Calendar Sync + Teams + Monitor
|
||||
|
||||
**Date (UTC):** 2026-05-04
|
||||
**Tech:** Howard Enos
|
||||
**User helped:** Svetlana Larionova (`slarionova@grabblaw.com`)
|
||||
**Tenant:** grabblaw.com (`032b383e-96e4-491b-880d-3fd3295672c3`)
|
||||
|
||||
## User
|
||||
- **User:** Howard Enos (howard)
|
||||
- **Machine:** Howard-Home
|
||||
- **Role:** tech
|
||||
|
||||
## Summary
|
||||
|
||||
Multiple support items for Svetlana at Grabb & Durando in one session: got Leap's M365 calendar sync working for her account (admin-consent + token-rebind cleanup), added a second monitor to her workstation, and resolved a Teams file-send issue.
|
||||
|
||||
## 1. Leap M365 calendar sync — root cause and fix
|
||||
|
||||
### Problem
|
||||
Svetlana could not add calendar events from Leap to M365. Leap displayed "no admin permissions" during the connect-to-M365 flow.
|
||||
|
||||
### Root cause
|
||||
The error message is misleading — it's an OAuth consent block, not an RBAC issue. Leap's user-facing app (appId `a7d19842-33e2-457b-a399-d4e6ec010f0a`, registered in tenant as service principal `7dd62220-081d-4c6b-8184-dc3187e81578`) requests scopes including `Mail.ReadWrite`, `Mail.Send`, `Files.ReadWrite.All` along with `Calendars.ReadWrite`. The grabblaw.com tenant's user-consent policy (`microsoft-user-default-recommended` + `microsoft-user-default-allow-consent-apps`) classifies those as high-risk and blocks user-level self-consent. New users have to be admin-approved for Leap to connect — at the time of investigation, five other users (jsosa, rpesqueira, avazquez, jwilliams, yheredia) already had per-user `Principal` grants from a prior approval round; Svetlana didn't because she was onboarded later.
|
||||
|
||||
### Investigation
|
||||
Used the ComputerGuru Security Investigator (Graph read-only) app to:
|
||||
- Pull Svetlana's user record — confirmed `accountEnabled=true`, license `O365_BUSINESS_PREMIUM`, no admin roles, no group memberships beyond the company DL.
|
||||
- Enumerate the LEAP service principals — found two: a daemon/app-only app (5602fc50…, has `Calendars.ReadWrite` Application permission) and the user-facing delegated app (a7d19842…, requires per-user delegated consent).
|
||||
- Confirm the 5 working users had `Principal`-type OAuth grants on the delegated app and 4 of them had no admin roles. Conclusion: she did not need an admin role — just admin approval for the Leap app for her account.
|
||||
|
||||
Full investigation report: `clients/grabb-durando/reports/2026-05-04-leap-calendar-permission-investigation.md`.
|
||||
|
||||
### Fix
|
||||
Mike granted **tenant-wide** consent (`consentType=AllPrincipals`) on the LEAP delegated app at 16:26 UTC via sysadmin@grabblaw.com. Verified via `oauth2PermissionGrants` endpoint — grant count on LEAP2 went from 5 (per-user Principals) → 6 (5 Principals + 1 AllPrincipals).
|
||||
|
||||
This is broader than my original recommendation (per-user via Admin Consent Request), but it has a useful side-effect: any future new hire at Grabb & Durando won't hit the consent block — Leap will just work.
|
||||
|
||||
### Second issue — Leap bound to sysadmin's identity
|
||||
After consent, Leap stopped asking for admin permission but threw "unable to subscribe to notifications. leap cannot complete this action" instead. On further inspection, Leap was syncing **sysadmin's** mailbox/calendar instead of Svetlana's — because when Mike signed in to Leap on Svetlana's PC to grant consent, Leap stored sysadmin's user token as the calendar identity.
|
||||
|
||||
### Resolution steps Howard performed
|
||||
1. Ran Leap repair (leap.us) — did not fully fix.
|
||||
2. Revoked the M365 OAuth grant for Leap on sysadmin's account.
|
||||
3. Deleted the Leap Outlook integration cache from `%LOCALAPPDATA%\Microsoft Corporation\` on Svetlana's PC.
|
||||
4. Re-enabled the M365 connection in Leap, signing in as Svetlana.
|
||||
5. Calendar sync now works against Svetlana's mailbox.
|
||||
|
||||
### Going forward
|
||||
For future new hires at Grabb & Durando, do NOT have an admin sign in to Leap on the user's machine to grant consent — the admin's identity gets bound to that Leap install. Either:
|
||||
- Have the user run the connect flow themselves (tenant-wide consent now exists, so they should sail through), OR
|
||||
- If broader consent is ever needed, grant it via the Entra portal admin-consent flow, not by signing in to the third-party app.
|
||||
|
||||
## 2. Teams not sending files — "outside of their domain"
|
||||
|
||||
Svetlana was getting blocked sending files in Teams. Root cause: the recipient was outside the grabblaw.com domain. Teams correctly enforces the firm's external-collaboration policy; this isn't a bug. Walked through the limitation with her so she knows when to use email/secure-share for external recipients vs. Teams for internal.
|
||||
|
||||
(No tenant-side change needed — this is policy working as intended.)
|
||||
|
||||
## 3. Second monitor
|
||||
|
||||
Added a second monitor to her workstation. Plug-and-play; configured display arrangement.
|
||||
|
||||
## Tools / accounts touched
|
||||
|
||||
- ComputerGuru Security Investigator (Graph read-only) — investigation only
|
||||
- sysadmin@grabblaw.com — granted tenant-wide consent for LEAP delegated app
|
||||
- Svetlana's PC — Leap repair, deleted `%LOCALAPPDATA%\Microsoft Corporation\` Leap cache, re-signed in to Leap
|
||||
|
||||
## Follow-up
|
||||
|
||||
- Syncro ticket to create + bill (this session).
|
||||
- No further M365 / Leap work needed unless calendar sync regresses.
|
||||
Reference in New Issue
Block a user