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:

1Connect 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

2Inspect 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*"}

3Note 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:

1Remove 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.

2Force 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)"

3Re-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:

1Connect to the SharePoint Admin Center using PowerShell:

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

2Query the site's site collection administrators:

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

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

Step-by-Step Fix:

1Add 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

2Alternatively, 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.

3Validate 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:

1Check Entra ID Sign-in Logs in the Azure Portal (portal.azure.com).

2Search for the user's recent sign-in events targeting Office 365 SharePoint Online.

3Select the failed/restricted event and review the Conditional Access tab.

4Look for policies where Session Control is set to Use app enforced restrictions or Block access.

Step-by-Step Fix:

1Inspect 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.

2Grant 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

3Ensure 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:

1Open SharePoint Online Management Shell as Administrator.

2Query 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

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

Step-by-Step Fix:

1Unlock the Site Collection via PowerShell:

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

2Increase 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

3Verify 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:

1Connect via SharePoint Online Management Shell.

2Query 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

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

Step-by-Step Fix:

1Temporarily 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).*

2Perform Required Administrative Task:

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

3Re-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:

1Open the SharePoint Admin Center (https://yourtenant-admin.sharepoint.com).

2Navigate to Content services > Term store.

3Select a Term Group or Term Set and inspect the Term store administrators or Group managers fields.

Step-by-Step Fix:

1Assign 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.

2Grant 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.

3Validate 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:

1Review 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.

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

Step-by-Step Fix:

1Option 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.

2Option 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:

1Connect via PnP PowerShell.

2Verify site feature activation status:

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

Step-by-Step Fix:

1Re-activate Reporting Infrastructure Features:

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

2Verify 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:

1Connect using PnP PowerShell:

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

2Check if the target library has unique permissions:

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

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

powershell
   Get-PnPListItemPermission -List "Documents"

Step-by-Step Fix:

1Restore Permission Inheritance via PowerShell:

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

powershell
     Reset-PnPListInheritance -Identity "Documents"

2Alternatively, 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"

3Verify 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:

1Navigate to Site Contents: https://yourtenant.sharepoint.com/sites/targetsite/_layouts/15/viewlsts.aspx.

2Look for the presence of the Preservation Hold Library.

3Verify 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:

1Identify 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.

2Complete 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.

3Re-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:

1Open the list in SharePoint Online.

2Go to List Settings > Advanced settings.

3Inspect Read access and Create and edit access options.

Step-by-Step Fix:

1Update 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.

2Update via PnP PowerShell:

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

*(Where 1 corresponds to 'Read/Edit all items').*

3Validate 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:

1Download the affected document (.docx, .xlsx, .pdf) locally.

2Attempt to open the document in Microsoft 365 Apps.

3Review 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:

1Modify 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.

2Remove 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:

1Open PowerShell and attempt connection:

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

2Run a basic tenant query cmdlet:

powershell
   Get-SPOSite -Limit 1

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

Step-by-Step Fix:

1Assign 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.

2Re-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:

1Connect to SPO Management Shell as SharePoint Admin.

2Check tenant app authentication settings:

powershell
   Get-SPOTenant | Select-Object DisableCustomAppAuthentication, LegacyAuthProtocolsEnabled

Step-by-Step Fix:

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

powershell
     Register-PnPManagementShellAccess

2Authenticate Using Interactive Web Login:

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

3Allow 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:

1Open Entra Admin Center (entra.microsoft.com).

2Navigate to Identity > Applications > App registrations > Select your application.

3Click API permissions.

4Check if SharePoint (Office 365 SharePoint) permissions are missing or if Admin consent required status shows ungranted warnings.

Step-by-Step Fix:

1Add SharePoint Application Permissions:

Click Add a permission > Select SharePoint.

Select Application permissions.

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

Click Add permissions.

2Grant Admin Consent:

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

3Test 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:

1Open the failed flow run in Power Automate (make.powerautomate.com).

2Expand the failed SharePoint action step.

3Inspect the error output: status: 403, message: Access denied. You do not have permission to perform this action.

4Check the Connections panel to identify the account bound to the SharePoint connector.

Step-by-Step Fix:

1Verify 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.

2Fix 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.

3Re-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

System Interrupts High CPU Usage 100% Fix Tree

NVMe SSD Not Showing Full Speed In CrystalDiskMark: PCIe Lane Diagnostic

Windows 11 File Explorer Slow To Load Green Bar Fix

Mechanical Keyboard Some Keys Double Typing: Debounce Diagnostic

AirPods Connected to Windows But Sound Is Low Quality: Hands-Free Profile Fix

Subscribe to StepDiag

Embed Guide on Your Website