链接中的文章标题是"SharePoint: Users randomly lose permission – are deleted from site"，这篇文章探讨了SharePoint中的一个问题，即用户随机失去权限或被从站点中删除的问题。作者解释了该问题的原因和解决方法。这篇文章提供了详细的信息，包括SQL查询和PowerShell脚本，以帮助管理员识别和解决此问题。文章还提到了如何避免出现这个问题。如果您想详细了解这个问题和解决方法，请点击链接查看完整的文章：SharePoint: Users randomly lose permission – are deleted from site。
章标题： SharePoint: Users randomly lose permission – are deleted from site
作者： Josh Roark
发布日期： 2018年12月30日
更新日期： 2022年11月16日
文章内容：
这是一个复杂的问题。它似乎是随机和不定期的（实际上都不是），并且非常难以跟踪。这被称为“SID不匹配”问题。
这个问题的一个场景如下：
Intermittently, when a user browses to a resource (site, list, etc) that they are supposed to have access to, they receive “Access Denied“, or our friendlier version: “Sorry, this site hasn’t been shared with you“.
When looking at permissions, you find that the user no longer has any explicitly-given permission within the site collection.
The permission to the resource has been removed and the user must be added back. In fact, the user has been deleted from the entire site collection. The only permissions they may have left are those they get via Active Directory (AD) group membership.
You may find entries like the following in your SharePoint ULS logs at the time the user lost permission:
Failed to add [Login=i:0#.w|contoso\user1] to the database. It may already exist at [SiteId=5F39AB50-AD42-4B35-85E3-3BDF60028A7B][UserId=0]. HR=0x80070050
Found a user with the same tp_Login but different tp_SystemId. Try to delete it. Site ID: 5F39AB50-AD42-4B35-85E3-3BDF60028A7B tp_Login: i:0#.w|contoso\user1
不定期地，当用户浏览到他们应该有访问权限的资源（站点、列表等）时，他们会收到“拒绝访问”或更友好的版本：“抱歉，此站点尚未与您共享”。
在查看权限时，您会发现用户不再在站点集合中具有任何明确授予的权限。
资源的访问权限已被删除，用户必须重新添加。实际上，用户已从整个站点集合中删除。他们可能仅通过Active Directory（AD）组成员身份获得的权限仍然存在。
在用户失去权限的时间，您的SharePoint ULS日志中可能会出现以下类似的条目：
Failed to add [Login=i:0#.w|contoso\user1] to the database. It may already exist at [SiteId=5F39AB50-AD42-4B35-85E3-3BDF60028A7B][UserId=0]. HR=0x80070050
Found a user with the same tp_Login but different tp_SystemId. Try to delete it. Site ID: 5F39AB50-AD42-4B35-85E3-3BDF60028A7B tp_Login: i:0#.w|contoso\user1
原因：
在某个时候，用户通过用户配置文件同步（Profile Sync）导入，然后从Active Directory（AD）中删除，再次在Active Directory中使用相同的帐户名重新创建，并随后重新通过Profile Sync导入。当以这种方式重新在AD中创建用户时，他们具有相同的帐户名，但具有新的安全标识符（SID）值。当用户被重新导入到SharePoint时，它们的SID未在Profile数据库中的UserProfile_Full表中更新。现在，用户配置文件服务应用程序（UPA）中的SID与站点集合使用的UserInfo表中的SID不匹配。
Verify you're hitting this issue:
您可以运行以下SQL查询来识别处于此状态的用户。以下是根据不同版本的SharePoint运行的查询示例。
sql-- 识别在UserProfile_Full和UserProfileValue之间SID不匹配的配置文件：
-- SharePoint 2016及更高版本
select upf.RecordId, upf.NTName, upf.PreferredName, upv.PropertyVal as [SIDfromUserProfileValue], pl.PropertyName, upv.PropertyID
into #temp
from upa.UserProfile_Full upf (nolock)
join upa.UserProfileValue upv (nolock)on upf.RecordID = upv.RecordID
join upa.PropertyList pl (nolock) on pl.PropertyID = upv.PropertyID
where upv.propertyid = 2
select upf.RecordId, upf.NTName, upf.PreferredName, upf.SID as [SIDfromUserProfile_Full], #temp.SIDfromUserProfileValue
from upa.UserProfile_Full upf (nolock)
join #temp on upf.RecordID = #temp.recordid
where upf.SID != #temp.SIDfromUserProfileValue
drop table #temp
SharePoint 2013查询：sql-- 识别在UserProfile_Full和UserProfileValue之间SID不匹配的配置文件：
-- SharePoint 2013版本
select upf.RecordId, upf.NTName, upf.PreferredName, upv.PropertyVal as [SIDfromUserProfileValue], pl.PropertyName, upv.PropertyID
into #temp
from UserProfile_Full upf (nolock)
join UserProfileValue upv (nolock)on upf.RecordID = upv.RecordID
join PropertyList pl (nolock) on pl.PropertyID = upv.PropertyID
where upv.propertyid = 2
select upf.RecordId, upf.NTName, upf.PreferredName, upf.SID as [SIDfromUserProfile_Full], #temp.SIDfromUserProfileValue
from UserProfile_Full upf (nolock)
join #temp on upf.RecordID = #temp.recordid
where upf.SID != #temp.SIDfromUserProfileValue
drop table #temp
这些查询将帮助您识别在UserProfile_Full和UserProfileValue之间SID不匹配的用户。sqlselect * from userinfo (nolock)
where tp_login like '%YourUsersNameHere%'
and tp_siteid = 'YourSiteCollectionIDHere'
例如：sqlselect * from userinfo (nolock)
where tp_login like '%josh%'
and tp_siteid = '020E1B20-92B7-4CBC-B072-EA9369204350'
如果您不确定站点集合ID，可以运行以下PowerShell命令来获取它：请注意：同一内容数据库中可以存储多个站点集合，因此在查询中包括站点集合ID非常重要。powershell(get-spsite http://YourSiteURLHere.contoso.com).id
如何修复这个问题？
我们需要更新Profile数据库中Profile_Full表中的SID。直接使用SQL更新是不受支持的方法。在受支持的方式中，解决此问题的一种方法是删除所有出现问题的用户配置文件，然后重新导入它们。然而，这些用户将失去所有手动输入的配置文件数据，如“关于我”、“向我提问”、“技能”、“兴趣”等。在大多数情况下，这不是一个好的解决方案。
相反，您可以运行Move-SPUser PowerShell命令，以将Profile_Full表中的SID更新为用户的“好/当前”SID。由于我们将传递相同的帐户名作为“旧”和“新”帐户，SID的值将是用户的唯一净变更。以下是运行此操作以修复单个用户的示例：
powershell$url = "http://www.contoso.com/" $claimsAcc = "i:0#.w|contoso\user1" $user = Get-SPUser -Identity $claimsAcc -Web $url Move-SPUser -Identity $user -NewAlias $claimsAcc -IgnoreSID
要运行Move-SPUser，您需要以具有User Profile Service Application上的Full Control权限的农场管理员身份登录。如果未这样做，可能会导致Null引用异常：Object reference not set to an instance of an object。
如果有大量处于此状态的用户，您将希望在循环遍历每个用户的脚本中运行此操作。下面是一个示例脚本，它从CSV文件中读取受影响的用户名。
完成这些步骤后，您可以再次运行针对Profile数据库的“识别在UserProfile_Full和UserProfileValue之间SID不匹配的配置文件”SQL查询。如果所有用户都得到了修复，它将不再返回任何结果。
重要提示：
如果您有一个发布/消耗场景，其中有其他农场使用User Profile Service Application，您必须在托管UPA的农场中的服务器上运行Move-SPUser脚本。如果这是一个专用的“服务”农场，您可以临时创建一个Web应用程序和站点集合，以便运行该脚本，或者您可以使用Move-SPUser的较少已知的等效方法：$farm.MigrateUserAccount。示例：
powershell$farm = Get-SPFarm $farm.MigrateUserAccount("contoso\user1", "contoso\user1", $false)
