German post was automatically translated by DeepL and manually reviewed
It is not a new issue for SharePoint. If an Identity team uses a UserPrincipalName (for SharePoint Online) multiple times in Entra or a local AD organization can be affected. For SharePoint Server, it is the SAMAccountName in the AD account.
While an account exists, a UserPrincipalName / SAMAccountName cannot be used a second time. It is a different situation in the case of a re-entry or identical name and if the UserPrincipalName was used already in the past. In such situations, conflicts with permissions may occur in SharePoint Online in the foreseeable future.
Content
When can your organization be affected?
- A UserPrincipalName was used in the past, deleted (when leaving), and is used again later (for example re-entry).
- If different people are involved (for example person with an identical name), the multiple use of the UserPrincipalName can lead to incorrect metadata in SharePoint, see workaround at the end.
- In SharePoint, content is shared directly with the new account.
An account is not affected…
- if the content is shared to a Microsoft 365 group and the account is a member of the group.
- if the SharePoint site is shared with “Everyone except external users” and the permissions for the content have not been interrupted.
In the latter case, SharePoint recognizes that this is a new account and replaces the account in the User Information List. Permission to “All persons in the organization” does not solve the problem.
Impact for SharePoint?
If someone shares content (page, folder, file,…) to the new account in SharePoint, the permissions are granted without any problems. The account is informed by email but still has no access.
A check confirms the permission for my colleague.
She will not get permisisions for content in the Site Collection. Owners and members of the Site Collection cannot identify the cause. A support ticket will most likely be created via internal IT. The cause is that the UserPrincipalName has been used again for her account.
Cause
SharePoint has been using the user information list per site collection for ages. Via the URL <SiteUrl>/_catalogs/users/simple.aspx it shows the User Information List in the browser.
When an account opens a site collection for the first time, SharePoint creates an entry for the account in the User Information List. It can be checked with PnP PowerShell.
Import-Module PnP.PowerShell
Connect-PnPOnline -url <SiteUrl> -Interactive
$SPOSiteUser = Get-PnPUser | ?{$_.LoginName -like "*[email protected]" }
Via the User Information List it optionally shows when the account was created in the Site Collection.
$UserHiddenListItem = Get-PnPListItem -List "User Information List" -Id $SPOSiteUser.id
$UserHiddenListItem.FieldValues.GetEnumerator() | ?{ $_.Key -in "Title", "UserName", "Created" }
The User Information List updates itself and obtains the data from the SharePoint User Profile Service. If an account is deleted and the UserPrincipalName is used again later, it is not a new account for the User Information List. User Profile Service does not update the data in the list.
Linking User Information List to SharePoint User Profile Service
Whether the entry in the User Information List matches the account in the User Profile Service and Entra ID can be recognized by a property. NameId from the UserId of the entry.
NameId is part of the SID from the SharePoint User Profile Service.
To check this, I query the account in the User Profile Service.
$SPOUPSAccount = Get-PnPUserProfileProperty -Account "[email protected]"
$SPOUPSAccount.GetEnumerator() | ?{$_.Key -in "AccountName", "UserName", "SID", "msOnline-ObjectId" }
A comparison of the SID shows that these are different accounts.
- Due to the UserPrincipalName, it is not a new account for the User Information List.
- Due to the SID, the account does not match the User Profile Service and Entra ID.
- The result is that the SharePoint Site Collection denies access.
The msOnline-ObjectId property is the Object ID of the Entra ID account. A check confirms this.
Solution / Workaround
Workaround
In the best case, your organization does not use a UserPrincipalName / SAMAccountName multiple times in SharePoint. Then you don’t need a workaround and the issue is resolved.
Workaround
If your identity team unfortunately has no interest in making changes, you have four alternative options. It does not solve the root cause. Options 3 and 4 require the PnP.PowerShell or SharePoint Online module.
With the workarounds, metadata (such as created by, information about versions,…) is retained at the end.
- If SharePoint can later reassign the account via the UserPrincipalName, it matches the person’s new profile and links the metadata of the old profile to the new profile. In this case, a person with an identical name could mistakenly take over the metadata of the old profile.
- If the account does not exist in the User Information List, SharePoint will display an error for metadata. SharePoint wants to open the profile in the list and cannot find it.
Workaround 1
Temporarily add the permission for Everyone… to the permissions of the Site Collection. The first time the user accesses the site, SharePoint should recognize that this is a new account. SharePoint replaces the account in the User Information List. After the first access, you can remove the permission for everyone again and authorize the new account to individual content on the SharePoint site.
Workaround 2
For a group-connected team site, add the account as a member of the team/group. The first time the user accesses the site, SharePoint should recognize that this is a new account. SharePoint replaces the account in the User Information List. After the first access, you can remove the account from the team again and permit it for individual content on the SharePoint site.
Workaround 3
Manually update the user account via PowerShell. SharePoint will remove the old account and replace it with the new account. The new account receives a new ID and the SID is updated. The account must be re-authorized to the content.
In some cases, it does not work via PnP.PowerShell. In this case, use the SharePoint Online PowerShell module.
# With PnP.PowerShell
Connect-PnPOnline -Url <SiteUrl> -Interactive
New-PnPUser -LoginName <UserPrincipalName>
(Get-PnPUser | ?{$_.LoginName -like "*<UserPrincipalName>" }) | Select-Object id -ExpandProperty UserId
# OR with SharePoint Online PowerShell
Connect-SPOService -Url "https://<Tenant>-admin.sharepoint.com"
Set-SPOUser -Site <SiteUrl> -LoginName <UserPrincipalName>
The account has been successfully replaced if the ID and the NameId property have been changed.
In my example, ID 63 was the old account. With ID 64, SharePoint recreated it in the User Information List and updated the SID.
A new comparison in the User Profile Service confirms the SID from ID 64. The account can be re-authorized in the SharePoint Site Collection.
Workaround 4
Remove the user account from the User Information List. The account is removed from the list and recreated the next time it is accessed. The account must be re-authorized to the content.
# With PnP.PowerShell
Connect-PnPOnline -Url <SiteUrl> -Interactive
(Get-PnPUser | ?{$_.LoginName -like "*<UserPrincipalName>" }) | Remove-PnPUser
# OR with SharePoint Online PowerShell
Connect-SPOService -Url "https://<Tenant>-admin.sharepoint.com"
Remove-SPOUser -Site <SiteUrl> -LoginName <UserPrincipalName>