SharePoint / OneDrive request access dialog

In this post, we walk through why users who look ‘healthy’ on the surface can still experience issues, and we cover practical ways to prevent and fix them across identity lifecycle management, rehire scenarios, tenant changes, and operational hygiene.

Who this is for

• Microsoft 365 / SharePoint admins troubleshooting unexpected Access denied issues in SharePoint or OneDrive.
• Identity admins managing offboarding, rehiring, account restores, or account recreation in Microsoft Entra ID.
• Migration teams performing tenant-to-tenant migrations, domain changes, or identity consolidation.

Background Design Explained

When a user is created in Microsoft Entra ID, there is no guarantee that the User Principal Name (UPN) is unique so there is a unique id (historically known as PUID) that is created and passed to SharePoint. When a user is granted permission to a SharePoint or OneDrive Site or file explicitly the user information is added to a hidden list User Information List (UIL) that stores basic details about the users.

Note: For users that are given permission via Office 365 Group, Security group, sharing link, the user profile information is not added until the first time the user interacts with the site or file.

The users unique id, UPN, and other user information will be added to the UIL.

Note: The User Information List (UIL) is maintained per site collection and is separate from Microsoft Entra ID and SharePoint User Profile Service.

As part of authorization, the unique id that is found in the UIL is evaluated to the unique id that is passed via the authentication token and if they do not match then the authorization fails and the user receives “Access Denied”.

Scenario: Taylor Smith (UPN taylor.smith@contoso.com)  has confidential SharePoint/OneDrive access. Sometime after Taylor leaves the company, a new user joins the company with the same name and is assigned the same UPN.  The new Taylor should not inherit the former Taylor’s access or content. SharePoint prevents this by checking a unique identifier via the User Information List (UIL), ensuring only matching IDs can access content.

Considerations for users removed from Entra ID

It’s common to notice users removed from Entra ID still showing up in SharePoint or OneDrive. SharePoint intentionally retains these accounts in the site’s User Information List to preserve:

• Document meta data such as “Created By” or “Modified By” information
• Audit and compliance records
• Legacy permission references
• Sharing and version history integrity

As a result, terminated or mail-disabled users may still appear in:

• Site People lists (e.g., _layouts/15/people.aspx)
• Group‑connected site membership views
• SharePoint user pickers

This visibility is expected and not a security risk because:

• A disabled or deleted Entra ID account cannot authenticate
• SharePoint permissions are not re‑granted
• The presence of the user record does not re‑enable access

Preventive Measures to Avoid Site User ID Mismatches

Preventing Site ID mismatches is largely about identity management. The goal is to avoid situations where a SharePoint site has one ID for a user and Entra ID has another. Here are strategies to minimize the chances of a mismatch occurring:

Identity lifecycle best practices

• Avoid reusing a former employee’s UPN: If possible, do not create a new account with the same username. If you must reuse, ensure you’ve cleaned up the old account’s SharePoint presence (see next points) before the new user starts using SharePoint.

Rehire scenarios

• Leverage account restores when rehiring: If an employee returns within Entra ID’s 30-day soft-delete window, restore the original account in Entra ID instead of creating a new one. This way, the user’s PUID is the same, and no mismatch will occur because as far as SharePoint is concerned it’s the same account. If outside the 30 days, restoration isn’t possible then extra cleanup will be needed.
• Educate and coordinate with HR/IT for re-hires: Often, IT might not realize that creating a returning employee’s account from scratch can cause access issues. Train staff on Site ID mismatches so they know to restore the old account when possible or run diagnostics/cleanup quickly after creating a new account. A standard operating procedure for rehired employee account setup that includes checking for SharePoint conflicts is valuable.
• Change UPNs by renaming, not recreating: If you need to change a user’s UPN (for example, after a name change or domain change), rename the existing account (Plan and troubleshoot User Principal Name changes in Microsoft Entra ID) rather than delete and create new. Entra ID allows updating the UPN of a user. SharePoint will typically update the user info entry’s UPN on next sync. This way, the user’s PUID stays consistent. Documentation:
  • How UPN changes affect OneDrive - SharePoint in Microsoft 365 | Microsoft Learn
  • Change your SharePoint domain name - SharePoint in Microsoft 365 | Microsoft Learn 

Tenant/domain changes

• Gracefully handle corporate domain transitions: In tenant-to-tenant migrations or domain swaps (such as consolidating two Entra ID tenants), be aware of PUIDs. Use migration tools that map old IDs to new ones or plan to run the fixes post-migration if users receive new IDs. If user/profile mapping isn’t available, treat it like bulk rehiring.

Operational hygiene

• Implement a UPN reuse delay or alteration: Some organizations choose to alter the UPN of departing users for a period to prevent accidental reuse (for example, rename jdoe@company.com to jdoe_deactivated@company.com) before deletion. If your policies allow, avoiding UPN reuse entirely is the simplest way to prevent identity confusion.
• Maintain documentation of user’s site access: Knowing which sites a user previously accessed makes it easier to clean up conflicts and restore access for legitimate rehires. Centralized, group-based permission management can also simplify re-permissioning once the mismatch is fixed. We have seen this accomplished in the following ways:
  • Microsoft Graph Data Connect for SharePoint
  • Custom scripts and Tools
  • Third Party Tools
• Clear SharePoint user info on departure (if feasible): For users who are permanently gone, you can remove them from SharePoint site collections, so old UIL entries don’t linger and later conflict with a reused UPN. This cleanup can be part of an offboarding checklist when appropriate. The cleanup will be 2 steps: 
  1. Locate which sites a user previously had access to:
     • If the user has been deleted from Entra then the use of custom scripts will be needed to identify sites that the user previously had access to.  Example Script SPO-Sharing-Scripts/Readme-FindAccess-SPO.md at main · mikelee1313/SPO-Sharing-Scripts · GitHub
     • If the user still exists in Entra, use the SharePoint Data Access Governance reports to locate sites accessible for a given user. Data access governance reports - get site permission report for given users
  2. Once you have a list of sites that the user has accessed, you will need to remove them from that site.
     • Create a script utilizing remove-spouser (Remove users from SharePoint) for all sites that the user had access to previously.
• Process for guest users: If you remove guest users, consider also cleaning them from site permissions if they might be re-invited later.

Cleanup Site User ID Mismatches

Once there is a user encountering a Site User ID Mismatch then you will have to do a cleanup reactively.  Review the article and use the tools outlined to address the OneDrive site as well as critical sites.

If you do not need an inventory of sites, the user had access to previously to facilitate restoring access to those files/sites then you could do a cleanup of the user through script. The following is an example of such a script:  

If a user encounters a Site User ID Mismatch, follow these steps to resolve the issue:

1. Review the article "Fix site user ID mismatch in SharePoint or OneDrive" for guidance on addressing mismatches. Use the tools outlined in the article to fix issues with the OneDrive site and any other critical sites.
2. If you do not need an inventory of sites the user previously accessed, proceed with cleaning up the user using a script. Refer to SPO-Sharing-Scripts/Readme-SPOUserRemover.md at main · mikelee1313/SPO-Sharing-Scripts · GitHub for details that could be used. Use this option if restoring access to those files or sites is not required.
3. If you need an inventory of sites that the user previously had access to provide access later, then you will need a script or report of the permission inventory for the site prior to removing the user from the site.

Users can then move forward with sharing or resharing content/sites to the new user instance, which will write a new entry to the user information list, with the correct unique ID, allowing access.

Summary

• User Site ID mismatches occur when a user is recreated with the same UPN but a different underlying identity, leading to SharePoint or OneDrive access issues. 
• SharePoint authorizes access using a unique ID (PUID) stored per site in the User Information List (UIL), not just the users' UPN.
• Disabled or deleted users may still appear in SharePoint by design to preserve audit history and document ownership—this is not a security issue.
• Prevention focuses on avoiding UPN reuse through process changes.
• Resolution options depend on the scenario: admins can either remove the old user entry directly if access history is not needed, or inventory and clean up affected sites before resharing content to the new account, so the correct ID is written.

Further Reading

Fix site user ID mismatch in SharePoint or OneDrive - SharePoint

Remove users from SharePoint

This script will create a report containing OD4B sites and the value of the AadObjectId stored in SharePoint and Azure Active Directory. This data can be used to help detect Site ID mismatches of OD4B site owners. · GitHub

SPO-Sharing-Scripts/Readme-SPOUserRemover.md at main · mikelee1313/SPO-Sharing-Scripts · GitHub