Interactive Troubleshooter

Published: Sep 27, 2026

SharePoint Online Access Denied Even as Owner

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Systematically diagnose and resolve SharePoint Online Access Denied errors that occur even when an account is assigned Site Owner or Site Collection Administrator permissions. This decision tree guides administrators through fixing User Information List mismatches, DenyAddAndCustomizePages restrictions, Conditional Access session blocks, and broken permission inheritance.

Full Diagnostic Tree & Step-by-Step Overview

In what context or specific area of the SharePoint Online site is the Access Denied error encountered?

Access Denied occurs across the entire site collection, including the root homepage.
Access Denied occurs only when accessing specific system pages (Site Settings, Storage Metrics, App Catalog, or Web Parts).
Access Denied occurs only on specific document libraries, sub-sites, or individual files.
Access Denied occurs when performing administrative actions via PowerShell, PnP, or REST API calls.

What identity or tenant-level restriction is present for the affected Site Owner account?

The user's User Principal Name (UPN) or email address was recently renamed or re-synced from Active Directory.
The site was created via Microsoft Teams / M365 Group, and the user is a Group Owner but missing from Site Collection Admins.
Access is blocked specifically when connecting from an unmanaged, personal, or non-compliant device.
The site collection is in a Read-Only state, locked, or undergoing storage quota enforcement.

User Information List Mismatch (Orphaned Account Claims / UPN Change)

Solution:

Root Cause: Mismatched Identity Claim in Hidden User Information List

When a user's User Principal Name (UPN), primary SMTP address, or immutable ID is altered in Microsoft Entra ID (Azure AD) or On-Premises Active Directory, SharePoint Online continues to reference the historical security identifier (SID) claim stored in the site collection's hidden User Information List (_catalogs/users). When the owner accesses the site, the browser sends a fresh Entra ID token containing the updated UPN claim. SharePoint attempts to map this token to the legacy profile in the site collection, fails the identity claim evaluation, and throws an Access Denied error.

# Diagnostic Verification:

1. Connect to the site using PnP PowerShell as a SharePoint Administrator:

powershell
   Connect-PnPOnline -Url "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -Interactive

2. Inspect the user entry in the site's User Information List:

powershell
   Get-PnPUser | Where-Object {$_.Email -eq "user@domain.com" -or $_.LoginName -like "*user@domain.com*"}

3. Note whether the LoginName claim format matches i:0#.f|membership|newuser@domain.com or retains the legacy olduser@domain.com string.

# Step-by-Step Fix:

1. Remove the Stale Profile from the Site Collection:

Open a web browser and navigate directly to the hidden User Information List URL:

https://yourtenant.sharepoint.com/sites/targetsite/_layouts/15/people.aspx?MembershipGroupId=0

Select the affected user profile and click Delete Users from Site Collection.

2. Force User Profile Sync Repair via PowerShell:

Open SharePoint Online Management Shell as Administrator.

Execute the user repair cmdlet to force Entra ID profile re-sync:

powershell
     Connect-SPOService -Url "[https://yourtenant-admin.sharepoint.com](https://yourtenant-admin.sharepoint.com)"
     Repair-SPOUserAndGroupSync -User "newuser@domain.com" -Site "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)"

3. Re-add User as Site Collection Administrator:

Run the following command to re-assign clean explicit administrator privileges:

powershell
     Set-SPOUser -Site "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -LoginName "newuser@domain.com" -IsSiteCollectionAdmin $true

# Prevention & Long-Term Monitoring:

Allow up to 24 hours after UPN modifications for background M365 User Profile Sync (UPS) timer jobs to update claims naturally across all site collections.

Microsoft 365 Group Owner Missing Explicit Site Collection Admin Status

Solution:

Root Cause: Disconnect Between M365 Group Owners and Primary Site Collection Administrators

Group-connected SharePoint sites (created via Teams, Outlook, or M365 Groups) manage permissions through Microsoft Entra ID Security Groups. A user can be designated as an Owner of the Microsoft 365 Group without being populated into the site's explicit Site Collection Administrators list. Certain advanced SharePoint features, administrative pages, and API calls require explicit Site Collection Admin rights rather than standard group owner permissions (Site Owners SharePoint group).

# Diagnostic Verification:

1. Connect to the SharePoint Admin Center using PowerShell:

powershell
   Connect-SPOService -Url "[https://yourtenant-admin.sharepoint.com](https://yourtenant-admin.sharepoint.com)"

2. Query the site's site collection administrators:

powershell
   (Get-SITE -Identity "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -Detailed).DetailedAdministrators

3. Check if the user's individual UPN is missing from the returned list.

# Step-by-Step Fix:

1. Add User Directly to Site Collection Administrators via PowerShell:

powershell
   Set-SPOUser -Site "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -LoginName "user@domain.com" -IsSiteCollectionAdmin $true

2. Alternatively, Update via SharePoint Admin Center GUI:

Go to SharePoint Admin Center (https://yourtenant-admin.sharepoint.com).

Navigate to Sites > Active sites.

Click the affected site name > Go to Membership tab.

Under Site admins, click Add site admins and add the owner's account directly.

3. Validate Access:

Have the user clear their browser cache or open a Private Browsing window to test access to administrative settings.

# Prevention & Long-Term Monitoring:

Ensure site provisioning templates automatically assign primary M365 Group Owners explicitly to the Site Collection Administrators group.

Entra ID Conditional Access Unmanaged Device / Network Session Restrictions

Solution:

Root Cause: Tenant Conditional Access Enforcement of Limited Web Access

Microsoft Entra ID Conditional Access policies paired with SharePoint Online session controls can restrict users on non-compliant or unmanaged devices. When the policy Use app enforced restrictions is enabled, SharePoint forces the session into a limited web access mode. Even if the user is a Site Owner or Global Admin, SharePoint blocks file downloads, script execution, and administrative UI configurations to prevent data exfiltration from non-corporate endpoints.

# Diagnostic Verification:

1. Check Entra ID Sign-in Logs in the Azure Portal (portal.azure.com).
2. Search for the user's recent sign-in events targeting Office 365 SharePoint Online.
3. Select the failed/restricted event and review the Conditional Access tab.
4. Look for policies where Session Control is set to Use app enforced restrictions or Block access.

# Step-by-Step Fix:

1. Inspect Tenant-Wide SharePoint Unmanaged Device Settings:

Open SharePoint Admin Center > Policies > Access control > Unmanaged devices.

If set to Block access or Allow limited, web-only access, unmanaged devices will trigger Access Denied on restricted site operations.

2. Grant Device Exemption via PowerShell:

To exempt a specific site collection from unmanaged device blocks, run:

powershell
     Set-SPOSite -Identity "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -AllowEditing $true -ConditionalAccessPolicy AllowFullAccess

3. Ensure Compliance on Endpoint:

Connect to the site from a Hybrid Entra ID Joined or Intune-compliant managed corporate device.

# Prevention & Long-Term Monitoring:

Configure conditional access policy exclusions for Break-Glass administrative accounts requiring emergency access from non-standard networks.

Site Collection Read-Only / Lock State Enforced

Solution:

Root Cause: Administrative Lock State or Read-Only Quotas Applied to Site Collection

SharePoint Online site collections can be placed into restricted access states (NoAccess or ReadOnly) by automated governance scripts, storage quota thresholds, or administrators. When a site is locked to ReadOnly, write operations (including updating site settings, saving lists, or managing permissions) throw Access Denied or permission errors regardless of the user's elevated Site Owner status.

# Diagnostic Verification:

1. Open SharePoint Online Management Shell as Administrator.
2. Query the exact Lock State of the site:

powershell
   Get-SPOSite -Identity "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" | Select-Object Url, LockState, StorageQuota, StorageQuotaWarningLevel

3. Verify if LockState displays ReadOnly, NoAccess, or Unlock.

# Step-by-Step Fix:

1. Unlock the Site Collection via PowerShell:

powershell
   Set-SPOSite -Identity "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -LockState "Unlock"

2. Increase Storage Quota if Caused by Exceeded Limits:

powershell
   Set-SPOSite -Identity "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -StorageMaximumLevel 1048576 -StorageWarningLevel 943718

3. Verify Access:

Refresh the site homepage and confirm full read/write administrative access is restored.

# Prevention & Long-Term Monitoring:

Set up automatic storage management in the SharePoint Admin Center so site quotas scale dynamically without locking sites.

Which specific system page or feature returns the Access Denied error for the Site Owner?

Accessing Site Settings options, Master Pages, Solution Gallery, or uploading web parts.
Accessing the Term Store, Managed Metadata properties, or Taxonomy settings.
Accessing the App Catalog, installing custom SharePoint Framework (SPFx) solutions, or approving API permissions.
Accessing Storage Metrics, Audit Log Search, or Site Usage reporting pages.

DenyAddAndCustomizePages Tenant / Site Feature Block (Custom Script Setting)

Solution:

Root Cause: Security Restrictions Enforcement via DenyAddAndCustomizePages Flag

In SharePoint Online, modern sites have the DenyAddAndCustomizePages (Custom Script) security feature enabled by default. This flag strips permission to execute script-based modifications, upload web parts, edit master pages, or access specific legacy system catalogs (_catalogs/wp or _catalogs/solutions). Even a Site Collection Administrator receives Access Denied when attempting these actions if Custom Scripting is blocked.

# Diagnostic Verification:

1. Connect via SharePoint Online Management Shell.
2. Query the custom script status on the site:

powershell
   Get-SPOSite -Identity "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" | Select-Object DenyAddAndCustomizePages

3. If DenyAddAndCustomizePages returns Enabled, custom scripting features are blocked.

# Step-by-Step Fix:

1. Temporarily Allow Custom Scripting on the Site Collection:

powershell
   Set-SPOSite -Identity "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -DenyAddAndCustomizePages $false

*(Note: Changes made via PowerShell take effect immediately, whereas GUI setting changes in M365 Admin Center can take up to 24 hours to propagate).*
2. Perform Required Administrative Task:

Complete uploading the web part, updating master pages, or configuring solution settings.

3. Re-enable Custom Scripting Security (Recommended Practice):

powershell
   Set-SPOSite -Identity "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -DenyAddAndCustomizePages $true

# Prevention & Long-Term Monitoring:

Utilize modern SharePoint Framework (SPFx) extensions instead of legacy custom script modifications to avoid requiring custom script permissions.

Term Store Admin Role Missing in Managed Metadata Service

Solution:

Root Cause: Term Store Permissions Isolation from Site Collection Permissions

The SharePoint Online Managed Metadata Service (Term Store) maintains a dedicated security model independent of site collection ownership. A Site Owner or Site Collection Administrator does not automatically inherit administrative rights to create term sets, modify term groups, or manage taxonomy tags in the global Term Store unless explicitly granted Term Store Administrator permissions.

# Diagnostic Verification:

1. Open the SharePoint Admin Center (https://yourtenant-admin.sharepoint.com).
2. Navigate to Content services > Term store.
3. Select a Term Group or Term Set and inspect the Term store administrators or Group managers fields.

# Step-by-Step Fix:

1. Assign User as Term Store Administrator:

In the Term store management page, click Edit next to Term store administrators.

Add the affected user's UPN/email address.

Click Save.

2. Grant Local Term Group Permissions (If Global Admin Rights are Not Desired):

Expand the specific Term Group in the left navigation pane.

Select the Group managers or Contributors tab.

Add the Site Owner to the local group level.

3. Validate Access:

Have the user navigate to Site Settings > Term store management on their site collection and test creating new term sets.

# Prevention & Long-Term Monitoring:

Assign site owners as local Group Managers within the Term Store for taxonomy groups dedicated to their business units.

App Catalog Administration / SPFx API Approval Permission Failure

Solution:

Root Cause: Site App Catalog vs. Tenant App Catalog Security Isolation

Deploying or approving SharePoint Framework (SPFx) solutions and web apps across a tenant requires SharePoint Administrator or Global Administrator roles in Microsoft 365, alongside admin rights to the dedicated Tenant App Catalog site collection (/sites/apps). A local Site Owner or Site Collection Admin cannot approve tenant-wide API web requests or upload apps to the central Tenant App Catalog.

# Diagnostic Verification:

1. Review the URL where Access Denied occurs:

If the URL is https://yourtenant.sharepoint.com/sites/apps, access is governed by the Tenant App Catalog permissions.

2. Check if the app deployment requires web API permissions in the API access page (https://yourtenant-admin.sharepoint.com/#/webApiPermissionManagement).

# Step-by-Step Fix:

1. Option A: Create a Site-Collection-App-Catalog (For Local Site Deployments):

If the app only needs to run on the local site, create a dedicated local app catalog using SharePoint Online Management Shell:

powershell
     Add-SPOSiteCollectionAppCatalog -Site "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)"

The Site Collection Administrator can now deploy apps locally to https://yourtenant.sharepoint.com/sites/targetsite/AppCatalog without tenant admin rights.

2. Option B: Grant Site Admin Permissions to Tenant App Catalog:

If managing central apps, add the user to the Tenant App Catalog site collection admins:

powershell
     Set-SPOUser -Site "[https://yourtenant.sharepoint.com/sites/apps](https://yourtenant.sharepoint.com/sites/apps)" -LoginName "user@domain.com" -IsSiteCollectionAdmin $true

# Prevention & Long-Term Monitoring:

Restrict Tenant App Catalog management to central IT teams while deploying Site Collection App Catalogs for decentralized site owners.

Usage Reporting / Storage Metrics Feature Disablement

Solution:

Root Cause: Disabled Site Collection Features or Information Barrier Policies

Accessing specialized analytics pages such as Storage Metrics (_layouts/15/storman.aspx) or Site Usage metrics can fail with Access Denied if the underlying site collection infrastructure features (such as Reporting or Cross-Site Collection Features) are corrupt, or if Microsoft Purview Information Barriers/Sensitivity Labels block administrative logging.

# Diagnostic Verification:

1. Connect via PnP PowerShell.
2. Verify site feature activation status:

powershell
   Get-PnPFeature -Scope Site | Where-Object {$_.DefinitionId -eq "4248e216-a620-4bc6-92d1-218a478144e0"}

# Step-by-Step Fix:

1. Re-activate Reporting Infrastructure Features:

powershell
   Enable-PnPFeature -Identity "4248e216-a620-4bc6-92d1-218a478144e0" -Scope Site -Force

2. Verify Sensitivity Label Access Policies:

Open Microsoft Purview Compliance Portal (compliance.microsoft.com).

Review Information Protection > Sensitivity Labels assigned to the site collection.

Ensure the label does not restrict administrative metadata access.

# Prevention & Long-Term Monitoring:

Avoid manually disabling core Site Collection scoped features in modern communication or team sites.

What specific permission structure is configured on the restricted document library, sub-site, or folder?

Permission inheritance is broken, and explicit unique permissions were configured on the object.
The document library is locked by an active Microsoft Purview Retention Label or Legal Hold.
Item-Level Security settings ('Read items that were created by the user') are enabled on the list.
A Microsoft Purview Information Rights Management (IRM) or Sensitivity Label encrypts the file.

Broken Permission Inheritance and Explicit Group Removal

Solution:

Root Cause: Unique Permission Assignment Removing Default Site Owners Group

When permission inheritance is broken on a sub-site, document library, or list, administrators can manually alter access lists. If an editor removes the default Site Owners or Site Collection Administrators group from the list's unique permissions table, Site Owners accessing the object via standard group membership encounter an Access Denied error.

# Diagnostic Verification:

1. Connect using PnP PowerShell:

powershell
   Connect-PnPOnline -Url "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -Interactive

2. Check if the target library has unique permissions:

powershell
   Get-PnPList -Identity "Documents" | Select-Object Title, HasUniqueRoleAssignments

3. If HasUniqueRoleAssignments is True, list the current role assignments:

powershell
   Get-PnPListItemPermission -List "Documents"

# Step-by-Step Fix:

1. Restore Permission Inheritance via PowerShell:

To restore inherited permissions from the parent site (re-adding Site Owners automatically):

powershell
     Reset-PnPListInheritance -Identity "Documents"

2. Alternatively, Add Explicit Permissions Without Restoring Inheritance:

If unique permissions must be maintained for other users, grant full control to the owner:

powershell
     Set-PnPListPermission -Identity "Documents" -User "user@domain.com" -AddRole "Full Control"

3. Verify Access:

Have the Site Owner refresh the list or document library in their web browser.

# Prevention & Long-Term Monitoring:

Audit list permission changes regularly using PnP PowerShell to ensure the Site Owners group is never stripped from unique permission lists.

Microsoft Purview Retention Policy / Legal Hold Lock

Solution:

Root Cause: Compliance Preservation Hold Library Locks Blocking File Operations

When a Microsoft Purview Retention Policy or eDiscovery Legal Hold is applied to a SharePoint site, files modified or deleted are preserved in the hidden Preservation Hold Library (PreservationHoldLibrary). If a Site Owner attempts to delete a folder, move a library, or perform site cleanup while items are locked by an immutable retention hold, SharePoint blocks the action with an Access Denied or file lock exception.

# Diagnostic Verification:

1. Navigate to Site Contents: https://yourtenant.sharepoint.com/sites/targetsite/_layouts/15/viewlsts.aspx.
2. Look for the presence of the Preservation Hold Library.
3. Verify active holds using Compliance PowerShell:

powershell
   Connect-IPPSSession
   Get-RetentionCompliancePolicy | Where-Object {$_.SharePointLocation -contains "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)"}

# Step-by-Step Fix:

1. Identify and Exclude Site from Retention Policy Temporarily (If authorized):

Open Microsoft Purview Compliance Portal (compliance.microsoft.com).

Navigate to Data lifecycle management > Microsoft 365 > Retention policies.

Edit the policy and exclude the target site URL under SharePoint classic and communication sites.

2. Complete Required Structural Modifications:

Wait 30–60 minutes for the policy exclusion to propagate to SharePoint Online.

Perform the required document library or folder management task.

3. Re-apply Retention Policy Location:

Remove the site exclusion in Purview to restore compliance protection.

# Prevention & Long-Term Monitoring:

Use eDiscovery cases to manage litigation holds rather than applying broad tenant-wide retention locks to active collaborative sites.

List Item-Level Access Settings Misconfiguration

Solution:

Root Cause: Item-Level Security Overrides Enforced on SharePoint Lists

SharePoint Lists contain advanced settings called Item-Level Permissions. If configured to Read items that were created by the user or Create items and edit items that were created by the user, standard list users cannot view or edit entries submitted by others. While Site Collection Administrators bypass this restriction, standard Site Owners (who are not explicit Site Collection Admins) are restricted by item-level rules.

# Diagnostic Verification:

1. Open the list in SharePoint Online.
2. Go to List Settings > Advanced settings.
3. Inspect Read access and Create and edit access options.

# Step-by-Step Fix:

1. Update Item-Level Permission Settings in GUI:

Navigate to List Settings > Advanced settings.

Under Read access, select Read all items.

Under Create and edit access, select Create and edit all items.

Scroll to the bottom and click OK.

2. Update via PnP PowerShell:

powershell
   Set-PnPList -Identity "TargetList" -ReadSecurity 1 -WriteSecurity 1

*(Where 1 corresponds to 'Read/Edit all items').*
3. Validate Access:

Refresh the list view as Site Owner and verify all user submissions are visible.

# Prevention & Long-Term Monitoring:

Reserve Item-Level Security settings for sensitive feedback or ticketing lists, ensuring site owners possess explicit Site Collection Admin status.

Microsoft Purview Sensitivity Label / IRM File Encryption

Solution:

Root Cause: File-Level Azure Information Protection (AIP) / Rights Management Encryption

When a document is protected by an Information Rights Management (IRM) policy or a Microsoft Purview Sensitivity Label with user-defined permissions, encryption rights are embedded directly into the file metadata. Even if a user is a SharePoint Site Owner or Site Collection Administrator, opening or downloading an encrypted file requires explicit usage rights (e.g., Owner, Co-Author) within the Sensitivity Label configuration.

# Diagnostic Verification:

1. Download the affected document (.docx, .xlsx, .pdf) locally.
2. Attempt to open the document in Microsoft 365 Apps.
3. Review the permission bar at the top of the app: Check if it states You do not have permission to access this content or lists restricted rights.

# Step-by-Step Fix:

1. Modify Sensitivity Label Permissions in Purview Portal:

Open Microsoft Purview Compliance Portal (compliance.microsoft.com).

Go to Information protection > Labels > Select the active label.

Edit label settings > Go to Configure protection settings > Encryption.

Ensure Assign permissions now includes the Site Owner group or Co-Author rights for all internal users.

2. Remove IRM Protection from Library Settings (If Library-Level IRM is Active):

Go to Library Settings > Information Rights Management (IRM).

Uncheck Restrict permission to documents in this library upon download and click Save.

# Prevention & Long-Term Monitoring:

Always include super-user groups or executive administrative accounts in Sensitivity Label encryption definitions.

What specific tool or protocol is failing when executing API/PowerShell commands?

SharePoint Online Management Shell cmdlets return '401 Unauthorized' or '403 Forbidden'.
PnP PowerShell / REST API queries fail with 'The remote server returned an error: (403) Forbidden'.
App-Only authentication (Azure AD App Registration) fails when connecting to SharePoint.
Power Automate flows or Logic Apps fail with 'Access Denied' when accessing SharePoint items.

SharePoint Admin Role Missing for Admin Shell Cmdlets

Solution:

Root Cause: Insufficient Tenant-Level Role Credentials for Administrative Management Shell

Executing cmdlets via the SharePoint Online Management Shell (connecting to https://yourtenant-admin.sharepoint.com) requires tenant-level administrative privileges. Being a Site Collection Administrator or Site Owner of an individual site is insufficient to execute SPO Management Shell commands, resulting in 401 Unauthorized or 403 Forbidden API exceptions.

# Diagnostic Verification:

1. Open PowerShell and attempt connection:

powershell
   Connect-SPOService -Url "[https://yourtenant-admin.sharepoint.com](https://yourtenant-admin.sharepoint.com)"

2. Run a basic tenant query cmdlet:

powershell
   Get-SPOSite -Limit 1

3. If PowerShell returns Current user is not a tenant administrator, the executing account lacks tenant admin roles.

# Step-by-Step Fix:

1. Assign SharePoint Administrator Role in Microsoft 365 Admin Center:

Open Microsoft 365 Admin Center (admin.microsoft.com).

Go to Users > Active users > Select the administrator account.

Under Roles, click Manage roles.

Select Admin center access > Check SharePoint Administrator.

Click Save changes.

2. Re-authenticate in PowerShell:

Close the PowerShell terminal, open a fresh window, and re-run Connect-SPOService.

# Prevention & Long-Term Monitoring:

Use Privileged Identity Management (PIM) to activate SharePoint Administrator roles dynamically when performing management tasks.

Legacy Authentication Blocked / PnP PowerShell Tenant Access Disabled

Solution:

Root Cause: Tenant Disable Custom App Authentication or Legacy Protocols

By default, Microsoft disables legacy authentication and legacy app-only tokens across SharePoint Online tenants (DisableCustomAppAuthentication = $true). If PnP PowerShell or custom REST scripts attempt to authenticate using ACS app-only tokens or non-interactive credentials without modern Azure AD App Registrations, SharePoint returns (403) Forbidden.

# Diagnostic Verification:

1. Connect to SPO Management Shell as SharePoint Admin.
2. Check tenant app authentication settings:

powershell
   Get-SPOTenant | Select-Object DisableCustomAppAuthentication, LegacyAuthProtocolsEnabled

# Step-by-Step Fix:

1. Enable PnP Management Shell Azure AD Application (For Interactive PnP Sessions):

powershell
     Register-PnPManagementShellAccess

2. Authenticate Using Interactive Web Login:

powershell
   Connect-PnPOnline -Url "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -Interactive

3. Allow Custom App Authentication (If Required for Legacy Scripts):

powershell
   Set-SPOTenant -DisableCustomAppAuthentication $false

# Prevention & Long-Term Monitoring:

Migrate all administrative scripts from legacy ACS app templates to Entra ID Registered Apps using certificate-based authentication.

Entra ID App Registration Missing SharePoint Graph / CSOM Permissions

Solution:

Root Cause: Insufficient API Permission Scope in Azure AD App Registration

When running automated scripts using Azure AD App Registrations (App-Only authentication via Certificates or Client Secrets), the application object acts as its own principal. If the application is granted Graph API permissions but lacks explicit SharePoint API permissions (Sites.FullControl.All or Sites.Selected), SharePoint API requests fail with Access Denied.

# Diagnostic Verification:

1. Open Entra Admin Center (entra.microsoft.com).
2. Navigate to Identity > Applications > App registrations > Select your application.
3. Click API permissions.
4. Check if SharePoint (Office 365 SharePoint) permissions are missing or if Admin consent required status shows ungranted warnings.

# Step-by-Step Fix:

1. Add SharePoint Application Permissions:

Click Add a permission > Select SharePoint.

Select Application permissions.

Check Sites.FullControl.All (or Sites.ReadWrite.All).

Click Add permissions.

2. Grant Admin Consent:

Click Grant admin consent for [Your Tenant Name] and confirm.

3. Test Connection in PnP PowerShell:

powershell
   Connect-PnPOnline -Url "[https://yourtenant.sharepoint.com/sites/targetsite](https://yourtenant.sharepoint.com/sites/targetsite)" -ClientId "<App-ID>" -Tenant "yourtenant.onmicrosoft.com" -Thumbprint "<Cert-Thumbprint>"

# Prevention & Long-Term Monitoring:

Utilize the Sites.Selected permission scope to grant app-only access strictly to designated site collections rather than tenant-wide.

Power Automate Connection Reference Account Permission Failure

Solution:

Root Cause: Connection Reference Service Account Lacking Site Permissions

Power Automate flows executing SharePoint actions (e.g., *Get items*, *Create file*) execute under the context of the user account defined in the flow's Connection Reference, not the user who triggers the flow. If the connection reference account loses Site Owner permissions or undergoes a password reset, the flow execution fails with HTTP 403 Forbidden or Access Denied.

# Diagnostic Verification:

1. Open the failed flow run in Power Automate (make.powerautomate.com).
2. Expand the failed SharePoint action step.
3. Inspect the error output: status: 403, message: Access denied. You do not have permission to perform this action.
4. Check the Connections panel to identify the account bound to the SharePoint connector.

# Step-by-Step Fix:

1. Verify Connection Account Permissions on Site:

Ensure the service account bound to the connection reference is assigned explicit Site Owner or Site Collection Administrator permissions on the target site.

2. Fix or Update Connection Reference in Power Automate:

In the flow designer, click the three dots (...) on the failed SharePoint action card.

Under Connection references, select Add new connection or switch to a valid Service Principal / Admin account.

3. Re-test Flow Execution:

Save the flow and click Test > With recently failed trigger to confirm successful execution.

# Prevention & Long-Term Monitoring:

Use dedicated non-interactive Service Principal connections (App Registrations) for production Power Automate enterprise flows targeting SharePoint.

Related Diagnostic Guides

Interactive: Game Crashes - Overheating, Driver, or Corrupted Files?

Intune Device Compliance Failed: Conditional Access Fix

Entra ID Sync Error: Duplicate Proxy Address

Power Automate Flow Failed: Connector Timeout Diagnostic

Interactive: Blue Screen - Which Driver Caused It? Use Driver Verifier

Subscribe to StepDiag

Embed Guide on Your Website