常見於 SharePoint Server 的微調權限問題疑難排解Troubleshoot common fine-grained permissions issues for SharePoint Server

摘要:了解如何疑難排解在 SharePoint Server 和 SharePoint 2013 中包含微調權限的問題。Summary: Learn about how to troubleshoot issues that include fine-grained permission in SharePoint Server and SharePoint 2013.

實作微調權限之後,SharePoint 環境可能會遇到安全性或效能問題。請檢閱下列資訊,協助您解決可能與微調權限相關的問題。After you implement fine-grained permission, a SharePoint environment could experience security or performance issues. Review the following information to help resolve issues that might be related to fine-grained permissions.

下列問題可協助降低有關廣泛使用微調權限對效能問題的影響。下列每個問題涵蓋變更環境安全性、物件階層架構,或會造成與微調權限相關之效能問題的自訂程式碼。每個問題由下列的範例環境著手,其中單一網頁包含多個文件庫,每個文件庫都含有許多專屬權限的子物件。The following issues can help reduce the effect of performance issues that are related to the extensive use of fine-grained permissions. Each of the following issues covers changes to the environment security, object hierarchy or custom code that is contributing to the performance issues that are related to fine-grained permissions. Each issue starts with the following example environment where a single web contains multiple document libraries, each with many uniquely-permissioned child objects.

說明單一 Web 包含多個文件庫,每一個都含有大量具專屬權限的獨特子物件。

問題 1:移除微調權限,並只在網頁層級使用安全性強制Issue 1: Remove fine-grained permissions and use security enforcement only at web level

若要重新架構環境使其不再需要微調權限,則可以實作環境清理程序,然後調整範圍的項目數量,以長期提高環境的延展性。下列建議會描述為達到本解決方案所需的環境清理和架構安全性變更。To re-architect the environment so that it no longer requires fine-grained permissions, an environment cleanup process can be implemented, and then the number of scoped items can be adjusted to improve the scalability of the environment over the longer term. The following recommendations describe the environment cleanup and architectural security changes that are required to achieve this solution.

環境安全性清理Environmental security cleanup

從網頁層級範圍移除使用者時,內部的 [物件模式] 必須從網頁層級下的每個範圍中移除該使用者。移除個別使用者以清理現有的權限是耗時的程序。相反地,先移除每個唯一項目層級範圍,使得該項目設為從其父系物件繼承使用權限。這會比嘗試先移除使用者耗費較少的時間,因為它只針對該項目的單一範圍採取動作。When a user is removed from the web-level scope, the internal Object Model must remove the user from every scope below the web level. Removing individual users to clean up existing permissions is a time-consuming process. Instead, first remove each unique item-level scope so that the item is set to inherit permissions from its parent object. This will take less time than trying to remove users first, because it has to act on only a single scope for the item.

重要

如果目前的網頁不在網站集合的根目錄中,且若網頁是設定為從父網站繼承權限,則在其下的所有專屬範圍會被移除,且所有「限制存取」成員資格會在單一 SQL Server 來回行程中同時被覆寫。If the current web is not at the root of the site collection, and if the web is then set to inherit permissions from its parent web, all the unique scopes under it will be removed, and all the Limited Access memberships will be overwritten at the same time in a single SQL Server round trip.

說明從 Web 層級範圍移除使用者來進行權限清除。執行這個動作時,內部 OM 必須從 Web 層級以下的每一個範圍中移除該使用者。

在移除所有項目層級範圍之後,網頁層級範圍上的個別範圍成員資格會由一或多個群組成員資格取代以允許存取。After all item-level scopes are removed, individual scope memberships at the web-level scope can be replaced with one or more group memberships to allow access.

說明使用一或多個群組成員資格來取代 Web 層級範圍上的個別範圍成員資格,以允許在移除所有項目層級範圍之後加以存取。

環境安全性架構重新設計Environmental security architecture redesign

移除現有微調權限及範圍之後,長期的架構計劃應只在網頁層級維持專屬範圍。下圖顯示其可能的結構方式,只留下網頁層級範圍。架構中的核心要求是在文件庫中,相同階層層級內沒有過多的項目,因為處理檢視中項目所需的時間會增加。After the existing fine-grained permissions and scopes are removed, the long-term architecture plan should be to maintain a unique scope only at the web level. The following diagram shows how this might be structured so that only the web-level scope remains. The core requirement in the architecture is not to have too many items at the same level of hierarchy in the document libraries, because the time that is required to process items in the views increases.

解決方案:Resolution:

在階層架構的任何層級中,項目或資料夾的最大數目應能容納約 2,000 個項目。The maximum count of items or folders at any level in the hierarchy should be about 2,000 items.

說明應如何設定 Web 層級範圍結構的架構。

如果需要對架構進行額外的變更,請考慮將文件庫移到不同的網路或網站集合。為了更密切支援商務需求,以及基於存放內容分類或對象的縮放建議,也可以變更文件庫的數目。If additional changes are needed to the architecture, consider moving document libraries to different webs or site collections. The number of document libraries could also be changed to more closely support business needs and scaling recommendations that are based on the taxonomy or audience of the stored content.

問題 2:依階層式結構變更使用微調權限Issue 2: Use fine-grained permissions by hierarchical structure changes

若要重新架構環境使其仍然使用微調權限,但不要造成太多更新,或在單一網頁範圍調整大小,請考慮將安全度不同的文件庫移到不同的網頁。To re-architect the environment so that it still uses fine-grained permissions, but without causing too many updates to or sizing of a single web scope, consider moving differently secured document libraries to different webs.

環境階層重新設計Environment hierarchy redesign

在下列圖表中,已將實體架構變更,使每個文件庫位在專屬權限的網頁中。此外,當必須保留項目層級的微調權限時,最佳作法應將授權存取的安全性主體累計數目限制於大約 2,000,雖然這不是固定的限制。因此,有效的成員資格,包括所有的「限制存取」成員使用者,每個網頁不應超過約 2,000 位使用者。如此可以防止每個網頁層級範圍變得過大。In the following diagram, the physical architecture was changed so that each document library is in a uniquely-permissioned web. Additionally, when item-level fine-grained permissions must be preserved, as a best practice the cumulative number of security principals who will be granted access should be limited to approximately 2,000, although this is not a fixed limit. Therefore, the effective membership of each web that includes all Limited Access members users, should be no more than approximately 2,000 users. This keeps each web-level scope from growing too large.

說明位於具專屬權限之 Web 中的文件庫。每個 Web 的成員資格不應超過 2,000 位使用者。

關於專屬範圍的子系數目不是難以處理的問題,且可將其調整為大量。然而,當限制存取達到範圍鏈,添加至第一個專屬權限網站的原則數量將會成為限制因素。The number of uniquely-scoped children is not a significant issue, and can scale to large numbers. However, the number of principles that will be added as limited access up the chain of scopes to the first uniquely permissioned web will be a limiting factor.

最後,雖然沒有特別的微調權限相關問題,資料夾結構應該保證文件庫的單一階層式層級不超過約 2,000 個項目。此限制可以協助確保使用者所要求的良好檢視效能。Lastly, although not specifically an issue about fine-grained permissions, the folder structure should guarantee that no single hierarchical level of the document library ever exceeds about 2,000 items. This limit can help guarantee good performance of views requested by users.

問題 3:依範圍結構變更使用微調權限Issue 3: Use fine-grained permissions by scope structure changes

若要重新架構環境使其仍然使用微調權限,但不要造成太多更新,或在單一網頁範圍調整大小,請考慮使用不同的安全項目程序。這個方法主要適用於若造成大量專屬範圍的原因是自動化程序,例如事件處理常式或動態變更物件權限的工作流程。在此情況下,建議對任何建立專屬安全性範圍的程序進行程式碼變更。To re-architect the environment so that it still uses fine-grained permissions, but without causing too many updates to or sizing of a single web scope, consider using a different process of securing items. This is mainly applicable if the cause of the large number of unique scopes was an automated process such as an event handler or workflow that dynamically changed object permissions. The recommendation in this case is to make a code change to whatever process was creating the unique security scopes.

動態安全性變更程式碼重新設計Dynamic security changing code redesign

在下列圖表中範圍架構已變更,因此範圍成員資格不會在父文件庫與網頁上導致 ACL 重新計算。如前所述,網站的有效成員資格 (包含所有「限制存取」成員) 不應超過約 2,000 個,以免網頁層級範圍變得太大。在此情況下,藉由實作新的 SharePoint 群組來保留所有具備「限制存取」權限的成員,範圍就不會變得太大。當使用 SharePoint Server SPRoleAssignmentCollection.AddToCurrentScopeOnly 方法,將使用者新增至網頁層級下的個別範圍時,也可以透過額外程式碼將使用者新增至網頁和文件庫層級中建置為「限制存取」權限的新群組。In the following diagram, the scope architecture was changed so that scope membership does not cause ACL recalculation at the parent document library and web. As mentioned earlier, the effective membership of the web that includes all Limited Access members, should be no more than approximately 2,000 to keep the web-level scope from growing too large. In this case, by implementing a new SharePoint group to hold all members who should have Limited Access rights, the scope won't grow too large. When users are added to individual scopes under the web level by using the SharePoint Server SPRoleAssignmentCollection.AddToCurrentScopeOnly method, they can also be added, by additional code, to the new group that was established as having Limited Access rights at the web and document library level.

說明不會在父文件庫與 Web 上導致 ACL 重新計算的範圍成員資格。

解決方案:Resolution:

當必須保留項目層級的微調權限時,應將授權存取的安全性主體累計數目限制於大約 2,000,雖然這不是固定的限制。安全性主體的數目增加時,會花費較長時間重新計算二進位的 ACL。如果範圍的成員資格變更時,就必須重新計算二進位的 ACL。在子項目專屬範圍內新增使用者會導致以新的「限制存取」成員來更新父範圍,即使這最終會導致不會變更父範圍的成員資格。在這種情況下,父範圍的二進位 ACL 也必須重新計算。When item-level fine-grained permissions must be preserved, the cumulative number of security principals who will be granted access should be limited to about 2,000, although this is not a fixed limit. When the number of security principals increases it takes longer to recalculate the binary ACL. If the membership of a scope is changed, the binary ACL must be recalculated. The addition of users at a child item unique scope will cause parent scopes to be updated with the new Limited Access members, even if this ultimately results in no change to the parent scope membership. When this occurs, the binary ACL for the parent scopes must also be recalculated.

如同先前的解決方案,專屬範圍的子系數目不是難以處理的問題,且可將其調整為大量。當限制存取達到範圍鏈,添加至第一個專屬權限網站的原則數量將會成為限制因素。As in the previous solution, the number of uniquely scoped children is not a significant issue, and can scale to large numbers. The number of principles that will be added as limited access up the chain of scopes to the first uniquely-permissioned web will be a limiting factor.

另請參閱See also

其他資源Other Resources

Fine-grained permission reference for SharePoint ServerFine-grained permission reference for SharePoint Server

Best practices for using fine-grained permissions in SharePoint ServerBest practices for using fine-grained permissions in SharePoint Server