# 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.