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.
|
||||
Reference in New Issue
Block a user