常見於 SharePoint Server 的微調權限問題疑難排解

 

**適用版本:**SharePoint Foundation 2013, SharePoint Server 2013, SharePoint Server 2016

**上次修改主題的時間:**2017-09-06

**摘要:**了解如何疑難排解在 SharePoint Server 和 SharePoint 2013 中包含微調權限的問題。

實作微調權限之後,SharePoint 環境可能會遇到安全性或效能問題。請檢閱下列資訊,協助您解決可能與微調權限相關的問題。

對常見微調權限效能問題的建議問題與解決方案

下列問題可協助降低有關廣泛使用微調權限對效能問題的影響。下列每個問題涵蓋變更環境安全性、物件階層架構,或會造成與微調權限相關之效能問題的自訂程式碼。每個問題由下列的範例環境著手,其中單一網頁包含多個文件庫,每個文件庫都含有許多專屬權限的子物件。

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

問題 1:移除微調權限,並只在網頁層級使用安全性強制

若要重新架構環境使其不再需要微調權限,則可以實作環境清理程序,然後調整範圍的項目數量,以長期提高環境的延展性。下列建議會描述為達到本解決方案所需的環境清理和架構安全性變更。

環境安全性清理

從網頁層級範圍移除使用者時,內部的 [物件模式] 必須從網頁層級下的每個範圍中移除該使用者。移除個別使用者以清理現有的權限是耗時的程序。相反地,先移除每個唯一項目層級範圍,使得該項目設為從其父系物件繼承使用權限。這會比嘗試先移除使用者耗費較少的時間,因為它只針對該項目的單一範圍採取動作。

重要

如果目前的網頁不在網站集合的根目錄中,且若網頁是設定為從父網站繼承權限,則在其下的所有專屬範圍會被移除,且所有「限制存取」成員資格會在單一 SQL Server 來回行程中同時被覆寫。

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

在移除所有項目層級範圍之後,網頁層級範圍上的個別範圍成員資格會由一或多個群組成員資格取代以允許存取。

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

環境安全性架構重新設計

移除現有微調權限及範圍之後,長期的架構計劃應只在網頁層級維持專屬範圍。下圖顯示其可能的結構方式,只留下網頁層級範圍。架構中的核心要求是在文件庫中,相同階層層級內沒有過多的項目,因為處理檢視中項目所需的時間會增加。

解決方案:

在階層架構的任何層級中,項目或資料夾的最大數目應能容納約 2,000 個項目。

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

如果需要對架構進行額外的變更,請考慮將文件庫移到不同的網路或網站集合。為了更密切支援商務需求,以及基於存放內容分類或對象的縮放建議,也可以變更文件庫的數目。

問題 2:依階層式結構變更使用微調權限

若要重新架構環境使其仍然使用微調權限,但不要造成太多更新,或在單一網頁範圍調整大小,請考慮將安全度不同的文件庫移到不同的網頁。

環境階層重新設計

在下列圖表中,已將實體架構變更,使每個文件庫位在專屬權限的網頁中。此外,當必須保留項目層級的微調權限時,最佳作法應將授權存取的安全性主體累計數目限制於大約 2,000,雖然這不是固定的限制。因此,有效的成員資格,包括所有的「限制存取」成員使用者,每個網頁不應超過約 2,000 位使用者。如此可以防止每個網頁層級範圍變得過大。

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

關於專屬範圍的子系數目不是難以處理的問題,且可將其調整為大量。然而,當限制存取達到範圍鏈,添加至第一個專屬權限網站的原則數量將會成為限制因素。

最後,雖然沒有特別的微調權限相關問題,資料夾結構應該保證文件庫的單一階層式層級不超過約 2,000 個項目。此限制可以協助確保使用者所要求的良好檢視效能。

問題 3:依範圍結構變更使用微調權限

若要重新架構環境使其仍然使用微調權限,但不要造成太多更新,或在單一網頁範圍調整大小,請考慮使用不同的安全項目程序。這個方法主要適用於若造成大量專屬範圍的原因是自動化程序,例如事件處理常式或動態變更物件權限的工作流程。在此情況下,建議對任何建立專屬安全性範圍的程序進行程式碼變更。

動態安全性變更程式碼重新設計

在下列圖表中範圍架構已變更,因此範圍成員資格不會在父文件庫與網頁上導致 ACL 重新計算。如前所述,網站的有效成員資格 (包含所有「限制存取」成員) 不應超過約 2,000 個,以免網頁層級範圍變得太大。在此情況下,藉由實作新的 SharePoint 群組來保留所有具備「限制存取」權限的成員,範圍就不會變得太大。當使用 SharePoint ServerSPRoleAssignmentCollection.AddToCurrentScopeOnly 方法,將使用者新增至網頁層級下的個別範圍時,也可以透過額外程式碼將使用者新增至網頁和文件庫層級中建置為「限制存取」權限的新群組。

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

解決方案:

當必須保留項目層級的微調權限時,應將授權存取的安全性主體累計數目限制於大約 2,000,雖然這不是固定的限制。安全性主體的數目增加時,會花費較長時間重新計算二進位的 ACL。如果範圍的成員資格變更時,就必須重新計算二進位的 ACL。在子項目專屬範圍內新增使用者會導致以新的「限制存取」成員來更新父範圍,即使這最終會導致不會變更父範圍的成員資格。在這種情況下,父範圍的二進位 ACL 也必須重新計算。

如同先前的解決方案,專屬範圍的子系數目不是難以處理的問題,且可將其調整為大量。當限制存取達到範圍鏈,添加至第一個專屬權限網站的原則數量將會成為限制因素。

See also

SharePoint Server 2013 的微調權限參考 (英文)
在 SharePoint Server 2013 中使用微調權限的最佳作法