共用方式為


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

適用於:yes-img-132013 yes-img-16 2016yes-img-192019 yes-img-se訂閱版本 no-img-sopMicrosoft 365 中的 SharePoint

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

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

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

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

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

環境安全性清理

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

重要事項

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

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

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

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

環境安全性架構重新設計

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

解決方法:

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

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

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

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

若要重新架構環境,使其仍然使用更細緻的許可權,但不會造成單一 Web 範圍的太多更新或大小調整,請考慮將不同保護的文檔庫移至不同的 Web。

環境階層重新設計

在下圖中,實體架構已變更,因此每個文檔庫都位於唯一許可權的網頁中。 此外,當必須保留專案層級的細部許可權時,最佳做法是將獲得存取權的安全性主體累計數目應限制為大約 2,000 個,但這不是固定的限制。 因此,有效的成員資格,包括所有的「限制存取」成員使用者,每個網頁不應超過約 2,000 位使用者。 如此可以防止每個網頁層級範圍變得過大。

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

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

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

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

若要重新架構環境,使其仍然使用更細緻的許可權,但不會對單一 Web 範圍造成太多更新或重設大小,請考慮使用不同的程式來保護專案。 如果造成大量唯一範圍的原因是自動化程式,例如動態變更物件許可權的事件處理程式或工作流程,則適用此方法。 在此情況下,建議對任何建立專屬安全性範圍的程序進行程式碼變更。

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

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

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

解決方法:

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

如同先前的解決方案,唯一範圍子系的數目不是一個重要問題,而且可以調整為大量。 將新增為限制存取範圍鏈結至第一個唯一許可權 Web 的原則數目將會是限制因素。

另請參閱

其他資源

在 SharePoint Server 中使用微調權限的最佳做法