Logs showed the failure was a transient 403 on the tenant admin endpoint
(loading CurrentUser on -admin.sharepoint.com returned E_ACCESSDENIED on a
cold token), and that re-running the operation a few seconds later succeeded.
The site-collection admin grant is also eventually consistent on Group/Teams
sites, taking a few seconds to reach the content endpoint.
Retry both stages with backoff (3s, 6s, 9s; 4 attempts) instead of failing
on the first denial:
- ElevateAsync retries the admin-endpoint grant on transient access-denied; a
genuine lack of tenant-admin rights still surfaces after retries exhaust.
- After a successful grant, the post-elevation operation retries on continued
access-denied to absorb grant-propagation lag.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
A SharePoint admin reported the grant runs without a logged error yet the
account never appears as site-collection admin on Group/Teams sites. The
failure was invisible: ElevateAsync called ExecuteQueryAsync directly (no
enrichment/logging) and the coordinator only surfaced elevate failures on the
page, not to Serilog.
- Route the admin-endpoint ExecuteQuery through ExecuteQueryRetryHelper so a
denial there is enriched (serverErrorType/httpStatus) and logged.
- Log the resolved login and SetSiteAdmin acceptance in OwnershipElevationService.
- Log elevate failures to Serilog in the coordinator.
- Add a post-elevation verify that reads CurrentUser.IsSiteAdmin on the target
site so logs distinguish a failed/no-op grant from a scan failing for another
reason. Diagnostic only; never throws into the operation flow.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Microsoft 365 Group / Teams-connected sites surface access-denied on some
CSOM calls as a raw "(403) FORBIDDEN" WebException carrying
0x80070005 (E_ACCESSDENIED), not as a typed ServerException with
ServerErrorTypeName = System.UnauthorizedAccessException. IsAccessDenied
only matched the typed shape, so those denials became generic
InvalidOperationExceptions the elevation coordinator never caught — no
auto-elevation ran and the operation failed even for a SharePoint admin.
Walk the inner-exception chain and treat any of these as access-denied:
the typed ServerException, a WebException with HTTP 403, or a message
containing the E_ACCESSDENIED HRESULT. Per-site dedupe still caps elevation
to one retry, so a 403 elevation cannot fix (policy/endpoint block) won't loop.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The "Auto-elevate ownership when permission scan is denied" setting was
dead code: the toggle was persisted but never read, the audit flow never
passed its onAccessDenied callback, and EnrichException wrapped every CSOM
error (including ServerUnauthorizedAccessException) into a generic
InvalidOperationException so the access-denied catch could never match.
Centralize elevation instead of per-call-site callbacks:
- Throw typed SharePointAccessDeniedException from EnrichException on
access-denied, preserving the failing site URL and enriched diagnostic.
- Add scoped IElevationCoordinator that catches it, and when AutoTakeOwnership
is enabled takes site-collection admin via the tenant admin endpoint and
retries the operation once. Per-site dedupe prevents loops; admin-host
denials are not treated as ownership issues. Retry is safe because each
wrapped operation closure re-issues its own CSOM loads.
- Wrap all site-scoped operations (Storage, Permissions, Duplicates, Search,
VersionCleanup, FolderStructure, BulkMembers, FileTransfer, Templates) and
the UserAccessAudit per-site scan in the coordinator.
- Drop the unused onAccessDenied parameter from IUserAccessAuditService.
Elevation still requires SharePoint tenant admin rights on the signed-in
account; the coordinator surfaces a clear message when that is missing.
Also keeps the prior StorageService change that avoids admin-gated
folder.StorageMetrics (403 for delegated non-admin tokens).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The per-client app registered its redirect URI under the `web` platform,
so Entra treated it as a confidential client and the connect token
exchange (PKCE, no secret) failed with AADSTS7000218 (client_secret
required). Register the redirect under `publicClient` instead — matching
the desktop reference (PublicClient.RedirectUris) — so the secretless
PKCE code redemption is accepted.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
kawa