How to Find Orphaned SharePoint Permissions Before Copilot Rollout
🔍 WiseChecker

How to Find Orphaned SharePoint Permissions Before Copilot Rollout

When you prepare for a Copilot rollout in Microsoft 365, orphaned SharePoint permissions can cause unexpected data exposure. Orphaned permissions occur when user or group accounts are removed from Azure Active Directory but their access rights remain in SharePoint sites. Copilot indexes content from SharePoint and can surface information to users who should not see it. This article shows you how to find and remove orphaned permissions before enabling Copilot for your organization.

Key Takeaways: Finding Orphaned SharePoint Permissions

  • SharePoint Online Management Shell (Get-SPOSiteUser): Lists all users with permissions on a site collection, including orphaned accounts.
  • Microsoft Graph PowerShell (Get-MgUser): Checks if a user still exists in Azure AD; cross-reference with SharePoint user list to find orphans.
  • SharePoint admin center > Site permissions > Check permissions: Manual method to verify a specific user’s access before deprovisioning.

ADVERTISEMENT

Why Orphaned Permissions Matter for Copilot

Copilot accesses Microsoft Graph data, including SharePoint site content, to generate responses. When a user asks Copilot a question, the system retrieves documents that the user has permission to view. Orphaned permissions create a security gap: a former employee’s account is disabled in Azure AD, but the SharePoint site still grants read or edit rights to that account. If the account is later reactivated maliciously, Copilot could expose sensitive content. Microsoft recommends auditing all SharePoint permissions before enabling Copilot for Microsoft 365. The process involves exporting current permissions, comparing them against active Azure AD accounts, and removing any access that no longer has a valid user or group.

How Orphaned Permissions Occur

Orphaned permissions typically result from three scenarios. First, a user is deleted from Azure AD without first removing their SharePoint access. Second, a security group is removed from Azure AD but the group membership remains in SharePoint. Third, a site collection is migrated or restored from backup, and the permission entries reference accounts that no longer exist in the directory. In all cases, the SharePoint site still shows a user or group in its permission list, but the identity cannot be resolved to a current Azure AD object. Copilot cannot distinguish between a valid user and an orphaned entry because it relies on the SharePoint permission model, which still grants access to the unresolved identity.

Steps to Identify Orphaned SharePoint Permissions

Use the following method to export all site users and cross-reference with Azure AD. This approach works for SharePoint Online in Microsoft 365.

  1. Connect to SharePoint Online Management Shell
    Open Windows PowerShell as an administrator. Run the command Connect-SPOService -Url https://yourtenant-admin.sharepoint.com. Replace yourtenant with your tenant name. When prompted, sign in with a SharePoint admin account.
  2. Export all site users for a site collection
    Run Get-SPOSiteUser -Site https://yourtenant.sharepoint.com/sites/yoursite. This command returns every user and group that has permissions on the specified site. Record the LoginName and Email properties for each entry.
  3. Repeat for all site collections
    Run Get-SPOSite -Limit All | ForEach-Object { Get-SPOSiteUser -Site $_.Url } to export users across every site collection. Pipe the output to a CSV file for analysis: Get-SPOSite -Limit All | ForEach-Object { Get-SPOSiteUser -Site $_.Url } | Export-Csv -Path C:\temp\AllSiteUsers.csv -NoTypeInformation.
  4. Connect to Microsoft Graph PowerShell
    Run Connect-MgGraph -Scopes User.Read.All, Directory.Read.All and sign in with a Global Admin or User Administrator account.
  5. Check each user against Azure AD
    For each LoginName in the CSV, run Get-MgUser -Filter "userPrincipalName eq 'user@domain.com'". If the command returns no output, the user does not exist in Azure AD and is orphaned. For groups, run Get-MgGroup -Filter "mail eq 'group@domain.com'".
  6. Document orphaned entries
    Create a new CSV listing the site URL, the orphaned LoginName, and the permission level (Read, Contribute, Full Control). This list will be used for removal.

ADVERTISEMENT

Remove Orphaned Permissions from SharePoint Sites

After you identify orphaned permissions, remove them using the SharePoint Online Management Shell. Do not remove permissions for groups that still exist in Azure AD even if no members are assigned.

  1. Remove a single orphaned user from a site
    Run Remove-SPOUser -Site https://yourtenant.sharepoint.com/sites/yoursite -LoginName user@domain.com. Confirm the prompt to remove the user.
  2. Remove orphaned users in bulk
    Import your CSV of orphaned entries. Use a loop: Import-Csv -Path C:\temp\OrphanedUsers.csv | ForEach-Object { Remove-SPOUser -Site $_.SiteUrl -LoginName $_.LoginName -Confirm:$false }. The -Confirm:$false parameter suppresses confirmation prompts for each removal.
  3. Verify removal
    Run Get-SPOSiteUser -Site https://yourtenant.sharepoint.com/sites/yoursite again to confirm the orphaned user no longer appears in the list.

If Orphaned Permissions Persist After Removal

Orphaned users reappear after running Remove-SPOUser

This can happen if the user is a member of a security group that still has permissions. Remove the group from the site instead. Run Remove-SPOUser -Site https://yourtenant.sharepoint.com/sites/yoursite -LoginName group@domain.com. If the group is also orphaned, this removes the group permission entirely.

Permissions inherited from a parent site cannot be removed at the child site

Break inheritance on the child site first. Run Set-SPOSite -Identity https://yourtenant.sharepoint.com/sites/childsite -DenyAddAndCustomizePages $false to ensure you can manage permissions. Then use the SharePoint admin center to stop inheriting permissions and remove the orphaned entry.

Orphaned permissions in OneDrive sites

OneDrive sites are personal and do not usually have orphaned permissions from deleted users. However, if a user is deleted and their OneDrive is still shared with others, the shared links remain active. Use the SharePoint Online Management Shell with Get-SPOSite -IncludePersonalSite $true to list OneDrive sites, then check permissions as described above.

SharePoint Permission Audit Methods: PowerShell vs Admin Center

Item PowerShell (SPO Management Shell) SharePoint admin center
Scope All site collections in one command One site at a time
Speed Fast for bulk operations Slower for large tenants
Orphan detection Requires cross-reference with Azure AD Manual check of each user
Removal Bulk removal via script Manual removal per user
Skill level Requires PowerShell knowledge No scripting required

After you complete the audit and remove all orphaned permissions, you can enable Copilot for Microsoft 365 with confidence. Run the same audit quarterly to maintain security. Use Microsoft Purview Data Lifecycle Management to automatically remove permissions when a user is deleted from Azure AD. This prevents orphaned permissions from accumulating between audits.

ADVERTISEMENT