排查 SharePoint Server 的常见细化权限问题
适用于：
2013 2016 2019 Subscription Edition 
SharePoint in Microsoft 365
实施细化权限时，SharePoint 环境可能会遇到安全或性能问题。 查看以下信息，以帮助解决可能与细化权限相关的问题。
常见细化权限性能问题的建议问题和解决方案
下列问题可帮助减轻与细化权限广泛使用相关的性能问题的影响。 下面每个问题均涉及环境安全变更、对象层次结构或导致与细化权限相关的性能问题的自定义代码。 每个问题从以下示例环境开始，其中单个 Web 包含多个文档库，每个文档库包含很多具有独特权限的子对象。
问题 1：删除细化权限并仅在 Web 级别实施安全机制
要重新构建环境使其不再需要细化权限，可以实施环境清理过程，然后可以调整作用域内的项目数量，以改进环境的长期可伸缩性。 下列建议介绍了实现此解决方案所需的环境清理和架构安全变更。
环境安全清理
将用户从 Web 级别作用域删除时，内部对象模型必须将用户从 Web 级别下的每个作用域中删除。 删除各个用户以清理现有权限是一个非常耗时的过程。 相反，首先删除各个独特的项目级别作用域，以便项目设置为从父对象继承权限。 这比尝试先删除用户所需的时间更短，因为它会仅对项目的单个作用域起作用。
重要
如果当前站点不是网站集的根，且站点设置为继承父站点权限，在单次 SQL Server 往返中，其下的所有唯一作用域将遭删除，同时访问权限有限的所有成员资格将遭覆盖。
删除所有项目级别作用域后，Web 级别作用域的各个作用域成员资格将替换为一个或多个组成员资格，以允许访问。
环境安全体系结构重新设计
删除现有细化权限和作用域后，应制定长期体系结构计划以仅在 Web 级别维护独特作用域。 下图显示了这可能如何构建，以便仅保留 Web 级别作用域。 体系结构中的核心要求是确保文档库中的相同层次结构级别中没有过多项目，因为这会增加处理视图中的项目所需的时间。
解决方案：
层次结构中任何级别的最大项目数或文件夹数应为 2,000 左右。
如果需要对层次结构进行其他更改，请考虑将文档库移到其他 Web 或网站集。 文档库的数量也可能会改变以更好地支持基于存储内容目标受众分类的业务需求和扩展建议。
问题 2：使用按层次结构更改的细化权限
要重新构建环境以使其仍使用细化权限，但不导致单个 Web 作用域出现太多更新或要进行大小调整，请考虑将保护方式不同的文档库移动到不同的 Web。
环境层次结构重新设计
下图中的物理体系结构已更改，以便每个文档库位于一个权限独特的 Web 中。 此外，当必须保留项目级细化权限时，作为最佳实践，应将被授予访问的安全主体累计数量限制在 2,000 左右，但这并非是固定的。 因此，包括所有受限访问成员用户的每个 Web 的有效成员资格应为不超过 2,000 名用户左右。 这可以防止每个 Web 级别作用域变得太大。
具有独特作用域的子项数量并非重要问题，可以扩展到较大的数量。 但是，将作为作用域链的受限访问添加到第一个独特许可 Web 的主体数量将成为一个限制因素。
最后，尽管不是关于细化权限的特定问题，文件夹结构应保证文档库的单个层次结构级别不会超过大约 2,000 个项目。 此限制有助于保证用户请求的视图的良好性能。
问题 3：使用按作用域结构更改的细化权限
要重新构建环境以使其仍使用细化权限，但不导致单个 Web 作用域出现太多更新或要进行大小调整，请考虑使用保护项目的不同进程。 如果独特作用域数量很大的原因是自动化进程，例如动态更改对象权限的事件处理程序或工作流，这将基本适用。 在这种情况下，建议对创建独特安全作用域的进程进行代码更改。
动态安全更改代码重新设计
在下图中，更改了作用域体系结构，确保作用域成员资格不会导致在父文档库和 Web 重新计算 ACL。 如上所述，包括所有受限访问成员的 Web 的有效成员资格不应超过 2,000 左右，以防 Web 级别作用域变得太大。 在这种情况下，通过实施新的 SharePoint 组来保存应具有受限访问权限的所有成员，作用域不会变得太大。 使用 SharePoint Server SPRoleAssignmentCollection.AddToCurrentScopeOnly 方法将用户添加到 Web 级别下面的各个作用域时，可以通过其他代码将其添加到在 Web 和文档库级别确定为具有受限访问权限的新组。
解决办法：
当必须保留项目级细化权限时，应将被授予访问的安全主体累计数量限制在 2,000 左右，但这并非是固定的。 当安全主体的数量增加时，将需要更长时间重新计算二进制 ACL。 如果作用域的成员资格发生变化，必须重新计算二进制 ACL。 在子项目的独特作用域添加用户会导致为父作用域更新新的受限访问成员，即使这最终不会导致父作用域成员资格产生任何变化。 当出现这种情况时，还必须重新计算父作用域的二进制 ACL。
与在前一种解决方案中一样，独特作用域的子项数量并非重要问题，可以扩展到较大的数量。 将作为作用域链的受限访问添加到第一个独特许可 Web 的主体数量将成为一个限制因素。