排查 SharePoint Server 的常见细化权限问题

适用于:yes-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

实施细化权限时,SharePoint 环境可能会遇到安全或性能问题。 查看以下信息,以帮助解决可能与细化权限相关的问题。

下列问题可帮助减轻与细化权限广泛使用相关的性能问题的影响。 下面每个问题均涉及环境安全变更、对象层次结构或导致与细化权限相关的性能问题的自定义代码。 每个问题都从以下示例环境开始,其中单个 Web 包含多个文档库,每个文档库具有许多唯一权限的子对象。

阐述包含多个文档库的单个 Web,每个库都带有大量具有独特权限的子对象。

问题 1:删除细化权限并仅在 Web 级别实施安全机制

若要重新构建环境,使其不再需要精细的权限,可以实施环境清理过程,然后可以调整作用域内项的数量,以提高环境的长期可伸缩性。 下列建议介绍了实现此解决方案所需的环境清理和架构安全变更。

环境安全清理

将用户从 Web 级别作用域删除时,内部对象模型必须将用户从 Web 级别下的每个作用域中删除。 删除各个用户以清理现有权限是一个非常耗时的过程。 相反,首先删除各个独特的项目级别作用域,以便项目设置为从父对象继承权限。 这比尝试先删除用户所需的时间更短,因为它会仅对项目的单个作用域起作用。

重要

如果当前站点不是网站集的根,且站点设置为继承父站点权限,在单次 SQL Server 往返中,其下的所有唯一作用域将遭删除,同时访问权限有限的所有成员资格将遭覆盖。

阐述通过从 Web 级范围删除用户来清除权限。执行此操作时,内部 OM 必须从 Web 级下的每个范围中删除该用户。

删除所有项目级别作用域后,Web 级别作用域的各个作用域成员资格将替换为一个或多个组成员资格,以允许访问。

阐述在具有一个或多个组成员资格的 Web 级范围上替换允许其在所有项目级范围都已删除后进行访问的单个范围成员资格。

环境安全体系结构重新设计

删除现有细化权限和作用域后,应制定长期体系结构计划以仅在 Web 级别维护独特作用域。 下图显示了这可能如何构建,以便仅保留 Web 级别作用域。 体系结构中的核心要求是文档库中的同一层次结构级别上不要有太多项,因为处理视图中的项所需的时间会增加。

解决办法:

层次结构中任何级别的最大项目数或文件夹数应为 2,000 左右。

阐述 Web 级范围应以何种体系结构构建。

如果需要对体系结构进行更多更改,请考虑将文档库移动到不同的网站或网站集。 文档库的数量也可能会改变以更好地支持基于存储内容目标受众分类的业务需求和扩展建议。

问题 2:使用按层次结构更改的细化权限

若要重新构建环境,使其仍使用细化权限,但不会导致对单个 Web 范围进行过多更新或调整大小,请考虑将不同安全的文档库移动到不同的 Web。

环境层次结构重新设计

在下图中,物理体系结构已更改,以便每个文档库都位于唯一权限的 Web 中。 此外,当必须保留项级细化权限时,作为最佳做法,将授予访问权限的安全主体的累积数量应限制在大约 2,000 个,尽管这不是固定限制。 因此,包括所有受限访问成员用户的每个 Web 的有效成员资格应为不超过 2,000 名用户左右。 这可以防止每个 Web 级别作用域变得太大。

Illustrates a document library that is in a uniquely- permissioned Web. The membership of each Web should not exceed 2,000 users.

唯一范围子级的数量不是一个重大问题,可以扩展到大量。 但是,将作为作用域链的受限访问添加到第一个独特许可 Web 的主体数量将成为一个限制因素。

最后,尽管不是关于细化权限的特定问题,文件夹结构应保证文档库的单个层次结构级别不会超过大约 2,000 个项目。 此限制有助于保证用户请求的视图的良好性能。

问题 3:使用按作用域结构更改的细化权限

若要重新构建环境,使其仍使用细化权限,但不会导致对单个 Web 范围进行过多更新或调整大小,请考虑使用其他保护项的过程。 如果大量唯一范围的原因是自动进程(例如事件处理程序或动态更改了对象权限的工作流),则这一点适用。 在这种情况下,建议对创建独特安全作用域的进程进行代码更改。

动态安全更改代码重新设计

在下图中,作用域体系结构已更改,因此范围成员身份不会导致父文档库和 Web 上的 ACL 重新计算。 如上所述,包括所有受限访问成员的 Web 的有效成员资格不应超过 2,000 左右,以防 Web 级别作用域变得太大。 在这种情况下,通过实施新的 SharePoint 组来保存应具有受限访问权限的所有成员,作用域不会变得太大。 使用 SharePoint Server SPRoleAssignmentCollection.AddToCurrentScopeOnly 方法将用户添加到 Web 级别下的各个范围时,还可以通过额外代码将这些用户添加到在 Web 和文档库级别建立为具有有限访问权限的新组。

阐述不会引起父文档库和 Web 级 ACL 重新计算的范围成员资格。

解决办法:

当必须保留项级细化权限时,将授予访问权限的安全主体的累积数量应限制为大约 2,000 个,尽管这不是固定的限制。 当安全主体的数量增加时,重新计算二进制 ACL 需要更长的时间。 如果作用域的成员资格发生变化,必须重新计算二进制 ACL。 在子项目的独特作用域添加用户会导致为父作用域更新新的受限访问成员,即使这最终不会导致父作用域成员资格产生任何变化。 当出现这种情况时,还必须重新计算父作用域的二进制 ACL。

与前面的解决方案一样,唯一范围子级的数量不是一个重大问题,并且可以扩展到大量。 将作为有限访问范围链添加到第一个唯一权限 Web 的原则数将是一个限制因素。

另请参阅

其他资源

在 SharePoint Server 中使用细化权限的最佳做法