本文章是由機器翻譯。

SharePoint 安全性

修整 SharePoint 搜尋結果以提高安全性

Ashley Elenjickal

下載程式碼範例

Microsoft SharePoint 搜尋會使用通常具有跨來編製索引的內容儲存機制的完整讀取權限的帳戶。因此 ’s 重要當某些內容的一個使用者] 查詢他應該限制只有文件的檢視他有看到的權限。SharePoint 會使用存取控制清單 (ACL) 每份文件相關聯修剪出使用者有沒有權限檢視的查詢結果，但 SharePoint (現成可用的調整) 所提供的預設調整不一定有足夠資料的安全性需求。在這種情況下您可能會想要進一步修剪結果取決於組織 ’s 驗證結構。

這是其中 SharePoint 自訂安全性調整的基礎結構是很有用的。SharePoint 可讓您實作商務邏輯分開的模組中，然後將它整合至做之查詢的查詢處理器的工作流程。在 [安全性] 調整路徑自訂查詢調整會遵循現成可用的安全性調整。因此查詢結果後自訂調整必須等於或小於文件的數字數目回收之前註冊自訂安全性 trimmer (CST) 組件。

在探究 CST 架構之前, 我們提供快速檢視 SharePoint 搜尋和新的宣告驗證基礎結構。

SharePoint 搜尋概觀

高的層級搜尋系統可以分為兩個不連續的部分：收集器管線和查詢處理器管線。

收集器管線這個部分會負責耙梳並編製索引的內容，例如 SharePoint 網站、 HTTP 站台、 檔案的不同儲存機制中共用，Lotus Notes，Exchange Server，以此類推。這個元件都位於 MSSearch.exe 內。若要耙梳儲存機制發出要求時, 收集程式叫用篩選器協助程式載入必要的通訊協定處理常式和連線、 擷取和剖析內容所需的篩選器的 MssDmn.exe。圖 1 代表收集器管線的簡化的的檢視。

圖 1 A Simplifed 檢視 SharePoint 收集程式管線的

SharePoint 可以只耙梳使用 Windows NTLM 驗證帳戶。內容的來源必須授權編目要求，若要存取文件內容的一部分傳送的 Windows 帳戶。雖然在 SharePoint 2010 支援宣告驗證，收集程式仍未宣告感知式的應用程式，並不會存取具有只宣告驗證的內容來源。

查詢處理器管線在 SharePoint 2010，兩個查詢處理器管線中最重要的變更是它的拓樸的延展性和驗證模型。在 Microsoft SharePoint 伺服器 (MOSS) 2007年，Web 前端 (WFE)，為相同的處理序中執行查詢處理器 (搜尋查詢] 和 [站台設定服務，稱為搜尋查詢服務從這裡上)，但在 SharePoint 2010 它可以執行任何地方在伺服陣列中，也會執行為 Web 服務。

WFE 交談搜尋查詢服務，透過 Windows 通訊基礎 (WCF) 呼叫。搜尋查詢服務現在是完全建置 SharePoint 宣告驗證基礎結構的最上層。這會減少其緊密的整合的 Windows 驗證和表單驗證從 SharePoint 搜尋。如此一來 SharePoint 現在支援各種驗證模型。搜尋查詢服務會修剪搜尋結果，根據發出查詢之使用者的權限。自訂安全性 trimmers 搜尋查詢服務稱為現成可用的調整完成之後。在執行查詢時，請查看 相關的各種元件的 圖 2 。

圖 2 的 查詢，源自 SharePoint 網站中的 「 搜尋 」 的工作流程

自訂安全性調整是查詢] 管線的一部分，所以我們限制查詢管線的討論區元件。

在 SharePoint 2010 宣告驗證

需要實作自訂的調整邏輯 CST 組件內的 SharePoint 2010 中宣告驗證支援基本的了解。宣告驗證] 環境中使用者識別身份被維護內部呼叫安全性語彙基元信封。它包含身分判斷提示或使用者相關的宣告的集合。宣告範例包括使用者名稱、 電子郵件地址、 電話號碼、 角色，以此類推。每個宣告會有各種不同的屬性，例如 型別 和 值 。就例如在宣告該 UserLogonName 可能 型別 和目前登入之使用者的名稱可能是 值 。

安全性語彙基元所發出的呼叫安全性權杖服務 (STS) 的實體。這是會回應使用者驗證要求的 Web 服務。在驗證使用者之後 STS 傳送回與所有使用者權限的安全性語彙基元。STS 可以設定來住在相同的 SharePoint 伺服陣列，或作為依賴的廠商到另一個的 STS，outsides 伺服陣列：識別提供者 STS (IP STS)，並藉由合作對象的 STS (RP-STS) 分別。您是否使用 IP STS 或 RP STS 已設計 SharePoint 部署時請仔細考慮。

SharePoint 會使用預設的宣告提供者隨附在簡單的安裝產品。即使您將設定伺服陣列時發出查詢，完全使用 Windows 的驗證向上搜尋服務的應用程式 Proxy 會討論到 STS 解壓縮的安全性中使用者的所有宣告語彙基元。透過 WCF 呼叫，此語彙基元然後會傳遞至搜尋查詢服務。

工作流程的自訂安全性調整

的 圖 3 所示，可表示工作流程邏輯，一個 CST 的簡單的流程圖中。

圖 3 的 一個 CST 的工作流程邏輯

如稍早所述的搜尋查詢服務第一次執行現成可用的安全性調整，並尋找任何 CSTs 搜尋結果與相關聯的目前狀態。藉由定義該特定內容來源為 耙梳規則 方法是與一個 CST 特定內容來源的關聯。如果搜尋查詢服務會尋找任何的 URL，搜尋結果中相關聯的任何 CST 它呼叫該 trimmer。trimmers 會載入至同一個 IIS 工作者處理序，w3wp.exe] 中搜尋查詢服務正在執行中。

一旦載入 trimmer，搜尋查詢服務呼叫 CheckAccess 方法內 trimmer 實作與先前定義的編目規則相關聯的 現成可用的調整 結果集。CheckAccess 方法會決定是否要特定的 URL 包含在最後的結果集傳回給使用者。這是藉由傳回位元陣列。此陣列內部位元設定為 true 或 false 會 「 包含 」 或 「 區塊 」 從最終結果 URL 設定。如果您想要停止處理效能或某些未預期的原因 URL 必須擲回一個 PluggableAccessCheckException。如果您擲回之後處理的 URL 的部分清單已處理的結果傳送給使用者。搜尋查詢服務將會移除所有尚未處理的 URL，從最後的結果集。

在部署自訂安全性 Trimmer 參與的步驟

有簡單地說有五個步驟所涉及的一個 CST 成功的部署：

1. 實作 ISecurityTrimmer2 介面。
   1. 實作初始化和 CheckAccess 使用 Managed 程式碼的方法
   2. 建立組件的簽章檔案，並將它做為專案的一部分包含
   3. 建置組件
2. 將 trimmer 部署到全域組件快取 (GAC) 在執行搜尋查詢服務的所有機器。
3. 建立您想要自訂的修剪的內容來源的編目規則。從搜尋管理網站，您可以執行這項操作。
4. trimmer 註冊使用 「 的 新增 SPEnterpriseSearchSecurityTrimmer Windows PowerShell Cmdlet 的編目規則。
5. 執行您在步驟 3 中建立的編目規則相關聯的內容來源的一個 完整耙梳 。在完整耙梳，才能正確地更新所有相關的資料庫資料表。增量耙梳並不會更新適當的資料表。

實作自訂安全性 Trimmer 介面

MOSS 2007 和 Microsoft 搜尋伺服器 (MSS) 2008年支援自訂的安全性調整，透過介面 ISecurityTrimmer 的搜尋結果。這個介面有兩種方法初始化和 CheckAccess。由於的架構性的變更，在 SharePoint 中] 和 [搜尋系統在 2010年版本中，這兩種方法 won’t 運作在 MOSS 2007 中所顯示的一樣。它們必須 re-implemented 使用 ISecurityTrimmer2 介面。如此一來若想在 SharePoint 2010 註冊 MOSS 2007 trimmer 則會失敗，說 ISecurityTrimmer2 未實作。MOSS 2007 的其他變更包括：

初始化方法的變更在 MOSS 2007，其中一個傳遞的參數是 SearchContext 物件。搜尋系統進入 SearchContext，它提供搜尋內容的站台或搜尋服務提供者 (SSP)。這個類別已被取代，在 2010年。而是，使用 SearchServiceApplication 類別：

void Initialize(NameValueCollection staticProperties, SearchServiceApplication searchApplication);

CheckAccess 方法的變更在 MOSS 2007 和 SharePoint 2010 搜尋查詢服務呼叫 CST 組件。 在 MOSS 2007，CheckAccess 方法所花費的只有兩個的參數，但在 SharePoint 2010，搜尋查詢服務傳遞使用者識別 CheckAccess 到使用的型別 IIdentity 的第三個參數：

public BitArray CheckAccess(IList<String>documentCrawlUrls, IDictionary<String, Object>sessionProperties, IIdentity passedUserIdentity)

ISecurityTrimmer2::Initialize 方法第一次一個 trimmer 載入搜尋查詢服務 IIS 工作者處理序時，會呼叫這個方法。 組件會存留期間的背景工作處理序。 下面是這個方法的簽章，並說明它的運作方式：

void Initialize(NameValueCollection staticProperties, SearchServiceApplication searchApplication);

staticProperties –The trimmer 註冊 Windows PowerShell Cmdlet，新增-SPEnterpriseSearchSecurityTrimmer，採用參數，稱為 「 屬性 」 (在 MOSS 2007 中這稱為 「 configprops 」) 透過它可以傳遞具名值組分隔的 ~。 這可能是用來初始化 trimmer 的類別屬性。

例如：當傳遞 「 superadmin ~ foouser ~ poweruser ~ baruser 」 來新增 SPEnterpriseSearchSecurityTrimmer] 指令程式 NameValueCollection 參數會有兩個項目集合中索引鍵與 「 superadmin 」 和 」 poweruser 」 和值為 「 foouser 」 和 「 baruser，」 分別。

searchApplication –If 您 trimmer 需要更深入的知識的搜尋服務執行個體 SharePoint 伺服陣列的相關、 使用 searchApplication 物件來決定該資訊。 若要了解更多關於 SearchServiceApplication 類別，請參閱 msdn.microsoft.com/library/ee573121(v=office.14) 。

ISecurityTrimmer2::CheckAccess 方法這會實作所有調整邏輯。 在這個方法中，請特別注意兩個層面：由核發的查詢以及大型傳回的查詢集所造成的效能延遲的使用者識別。

以下是這個方法的簽章，並說明它的運作方式：

public BitArray CheckAccess(IList<String>documentCrawlUrls, IDictionary<String, Object>sessionProperties, IIdentitypassedUserIdentity)

documentCrawlUrls –The 集合的 URL 是由這個 trimmer 修剪的安全性。

sessionProperties – 單一查詢執行個體視為一個工作階段。 如果您的查詢會擷取多結果，CheckAccess 方法會呼叫多次。 您可以使用這個參數，共用值，或追蹤的處理這些呼叫之間的 URL。

passedUserIdentity –This 是使用者的發出查詢識別。 它 ’s 的身分的程式碼將允許或拒絕存取內容。

BitArray –You 需要 documentCrawlUrls 中傳回位元陣列的項目數目相等。 設定為 true 或 false 此陣列內的位元會決定該位置 URL 應包含或封鎖寄回給使用者的最終結果集。

UserIdentity在宣告驗證模型時，內建 SharePoint 2010 搜尋查詢引擎。 搜尋查詢服務會通過查詢發行者 ’s 宣告但 IIdentity 參數。 若要取得之發出查詢的使用者的使用者名稱，您必須周遊的比較與 [SPClaimTypes.UserLogonName claim.ClaimType 宣告集合。

下列程式碼片段的程式碼會從宣告語彙基元，擷取使用者的登入名稱:

IClaimsIdentity claimsIdentity = (IClaimsIdentity)passedUserIdentity;

if (null != claimsIdentity)
{
  foreach (Claim claim in claimsIdentity.Claims)
  {
    if (claim == null)
      continue;
    if (SPClaimTypes.Equals(claim.ClaimType, SPClaimTypes.UserLogonName))
      strUser = claim.Value;
  }
}

您可能需要在網站集合層級用來正確地呼叫內部 API 的驗證類型的相關資訊。 若要識別如果使用者登入使用 Windows 驗證，尋找 的 ClaimsType.PrimarySid 的目前狀態。 下列程式碼會尋找 PrimarySid 宣告，並且再從中擷取使用者名稱：

if (SPClaimTypes.Equals(claim.ClaimType, ClaimTypes.PrimarySid))
{
  // Extract SID in the format "S-1-5-21-xxxxx-xxxxx-xxx"
  strUser = claim.Value;
  // Convert SID into NT Format "FooDomain\BarUser"
  SecurityIdentifier sid = new SecurityIdentifier(strUser);
  strUser = sid.Translate(typeof(NTAccount)).Value;
}

為 [表單] 或 [其他類似的非 Windows 驗證提供者查看 Claim.OriginalIssuer 值內宣告。 就例如如果伺服器設定為使用 ASP.NET SQL 成員資格提供者的表單驗證，[Claim.OriginalIssuer 將具有值 」 表單： AspNetSqlMembershipProvider 」：

if (SPClaimTypes.Equals(claim.ClaimType, SPClaimTypes.UserLogonName))
{
  strUser = claim.Value;
  strProvider = claim.OriginalIssuer; // For AspNet SQL Provider value will be
                                      // "Forms:AspNetSqlMembershipProvider"
}

如果查詢由匿名使用者發出，IIdentity.IsAuthenticated 方法的值將會是 false。 在這種情況下 claimsIdentity.Name 會有值"NT AUTHORITY\\ANONYMOUS 登入"。

為使用者內容上的最後一個注意事項，限制使用 API WindowsIdentity.GetCurrent ().Name，以擷取使用者的身分識別。 這一定會讓搜尋查詢服務執行的應用程式集區識別。 System.Threading.Thread.CurrentPrincipal.Identity 會提供您一個傳遞至 CheckAccess 方法相同的識別碼。

效能考量最佳化 CheckAccess 方法，擴展至最大。 如果查詢會傳回結果多 trimmer 可能被呼叫多次。 其中一個常見的方法，來處理這種情況下的是追蹤的透過 sessionProperties 參數 trimmer 內處理的 URL。 一旦方法會處理特定數目的結果集則可以擲回一個 PluggableAccessCheckException。 當擲回此例外狀況時，URL 處理最多點會傳回給使用者。

自訂安全性 Trimmer] 與 [系統記錄檔

一個 trimmer 內部程式碼 can’t 寫入系統記錄檔維護在 <drive> \ 程式 Files\Common Files\Microsoft Shared\Web 伺服器 Extensions\14\LOGS。 trimmer 必須維護它自己的記錄機制的偵錯和稽核。 唯一的例外是當方法擲回 [PluggableAccessCheckException。 訊息字串，指定時擲回會記錄到系統記錄檔。 搜尋查詢服務會記錄到檔案的有用資訊包含已修剪的安全性的文件數目。 就例如下列的記錄項目會提供建議，查詢 CST，來傳遞兩個文件，但零的文件傳送回使用者表示 [CST 修剪那些兩份文件：

04/23/2010 18:13:48.67    w3wp.exe (0x116C)    0x02B4    SharePoint Server Search    Query Processor    dm2e    Medium    Trim results: First result position = '0', actual result count = '0', total docs found = '0', total docs scanned = '2'.    742d0c36-ea37-4eee-bf8c-f2c662bc6a45

自訂安全性 Trimmers 及警示 SharePoint 的搜尋服務有功能，稱為 警示 (available only in Windows authentication mode)，在查詢結果可以發送的變更到透過電子郵件使用者。但是，計時器服務發出警示的查詢時, 搜尋查詢服務會刪去出 CSTs 相關聯的所有 URL 中。

組件簽署需求尋找相符的 CST 存在，搜尋查詢服務呼叫 CST 管理程式碼，從 GAC 載入特定的組件。若要執行此動作，則組件必須有數位簽章。請參閱 「 管理組件和資訊清單簽署 」 ( msdn.microsoft.com/library/ms247066 ) 的方式來簽署組件。一旦組件建置，使用 sn.exe 工具取得稱為公開金鑰語彙基元的 64 位元雜湊。在 trimmer 註冊時需要此語彙基元。

自訂安全性 Trimmer 的部署CST 
assembly 必須存放在搜尋查詢] 和 [站台設定服務正在執行的每一部機器上的 GAC 中。使用中央系統管理 | 系統設定 | 檢查中的機器，在伺服陣列中的每個搜尋查詢] 和 [站台設定服務狀態的伺服器上的服務。如果在服務啟動您必須以該機器匯入 [CST。don’t 混淆搜尋查詢和網站設定服務與包含查詢元件的機器。查詢元件都位於內 MSSearch.exe 提取結果，從索引中。搜尋查詢] 和 [站台設定服務居住在它自己的 IIS 背景工作處理序的 w3wp.exe。

若要註冊]、 [檢視] 和 [刪除 CSTs SharePoint 指令程式

MOSS 2007 用來註冊自訂的 trimmers 的 stsadm.exe 命令列工具，但此工具是過時的並不支援在 SharePoint 2010。而是，使用 Windows PowerShell 指令程式註冊、 檢視和刪除 CSTs。組件應該已經註冊它們 GAC 中可用。這裡 ’s 它們的使用方式：

註冊 –Use 新增 SPEnterpriseSearchSecurityTrimmer 註冊您 trimmer 必須使用組件 ’s 資訊清單的資料，例如版本、 文化特性和 PublicKeyToken。這個範例會註冊 trimmer，名為 「 搜尋服務應用程式 」 的搜尋應用程式：

New-SPEnterpriseSearchSecurityTrimmer -SearchApplication "Search Service Application" -TypeName "SearchCustomSecurityTrimmer.CustomSecurityTrimmerTest, SearchCustomSecurityTrimmer, Version=14.0.0.0, Culture=neutral, PublicKeyToken=4ba2b4aceeb50e6d" -RulePath file://elenjickal2/* -id 102 -Properties superadmin~foouser~poweruser~baruser

指令程式會耙梳規則 (RulePath)，作為 trimmer，組態屬性 (屬性) 的身分識別 (ID) 的整數值和資訊清單的資料，以及實作介面的類別的名稱所組成的名稱。指令程式的參數為：

• 搜尋服務應用程式與內容來源關聯的 SearchApplication–Name
• 包含資訊清單的資料，例如版本、 文化特性和 PublicKeyToken TypeName–This (它也指向實作介面的類別 ； 這會唯一識別從 GAC 的組件)
• trimmer 相關聯的 RulePath–The 耙梳規則
• 唯一識別 trimmer 執行個體的 Id–An int 資料類型
• 名稱/值組的 Properties–Set 隔開 ~

檢視 –Use Get SPEnterpriseSearchSecurityTrimmer 指令程式，並傳遞搜尋應用程式名稱。您可以藉由傳遞 trimmer 識別或您使用登錄時的其他屬性，進一步篩選它 (例如：取得-SPEnterpriseSearchSecurityTrimmer-SearchApplication 搜尋服務應用程式 」)。

刪除 –Use 移除 SPEnterpriseSearchSecurityTrimmer 指令程式，並傳遞搜尋應用程式名稱，以及 trimmer 的識別 (例如：Remove-SPEnterpriseSearchSecurityTrimmer-SearchApplication 搜尋服務應用程式 」 –id 102)。

附註：在註冊 [CST 之後, 的內容來源的完整耙梳是必要的。

疑難排解步驟

以下是一些調查任何非預期的搜尋結果的秘訣：

• 請確定耙梳的規則符合內容的來源位置。
• 檢查耙梳記錄檔，以確定要耙梳內容的來源所使用的帳戶具有其存取權。如果它 doesn’t，會有無法耙梳。
• 請確定查詢使用者檢視內容的權限。
• trimmer 的註冊之後確定執行完整耙梳。
• 請確定 trimmer 的組件是在 GAC 中所有機器的搜尋查詢服務正在執行中。
• 檢查系統記錄檔中的安全性 trimmer 所修剪的文件數目。
• 您可以使用 [公用程式 ProcessExplorer 從 technet.microsoft.com/sysinternals/bb896653 ，以便確定 trimmer 組件載入到 IIS 背景工作處理序 w3wp.exe。
• 將偵錯工具附加至背景工作處理序，組件會載入並透過 trimmer 的邏輯步驟。

查詢處理邏輯彈性

完成，CSTs 提供彈性地擴充查詢處理邏輯，以符合自訂的企業的安全性需求。其中一個應該永遠保持 trimmer 內實作錯誤可能會導致未預期的搜尋的結果，因此 ’s 重要 trimmer 部署在實際執行環境之前先它徹底測試對不同類型的內容來源，並驗證提供者的注意。

Ashley Elenjickal and Pooja Harjani* 已部分的 SharePoint 搜尋功能小組負責在 Microsoft 的自訂安全性 Trimmer。它們可以被達到 AshleyEl@microsoft.comPVaswani@microsoft.com 在分別。*

多虧了要檢閱這份文件的下列的技術專家：Michal Piaseczny