SharePoint 內幕SharePoint 目錄整合

Pav Cherny

程式碼下載:SharePoint2008_09.exe(2,775 KB)

目錄

SharePoint 目錄管理服務
自訂目錄管理服務
SharePoint 與 ILM
結論

Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 以目錄管理服務的形式提供了目錄同步處理功能,這項服務可在 Active Directory 中針對 SharePoint 資源佈建啟用郵件功能的連絡人和群組物件。針對

SharePoint® 資源佈建這類的收件者物件,可讓使用者在傳送文件和其他資訊時,直接從 Microsoft® Outlook® 通訊錄選取 SharePoint 文件庫、清單和群組。

SharePoint 收件者物件也提供了一種管道,讓您在 Exchange Server 組織中控制郵件傳輸和格式轉換。除此之外,您還可以在 Active Directory® 中設定郵件傳遞限制,藉此預防未經驗證的寄件者 (例如濫發垃圾郵件者) 提交郵件到 SharePoint 文件庫。

不過,SharePoint 目錄管理的功能有限,而且在撰寫本文之時,是以 Exchange Server 2003 為基本郵件系統。就目前而言,如果您是使用 Exchange Server 2007 或是協力廠商郵件系統,您必須以自訂解決方案來延伸或取代內建目錄管理功能,才能達到所要的互通性等級。

在本專欄中,我將簡短評估一下 SharePoint 目錄管理功能,隨後探討克服目前限制的方法。我的前題是,內建目錄管理服務只能滿足最基本的使用者需求,內含各種郵件系統和目錄平台的環境需要有更多的彈性和功能。藉著以自訂解決方案取代內建元件,您便能夠同步處理 SharePoint 收件者資訊與任何提供 API 或匯入功能的目錄解決方案。

為了證明這點,我會向您說明如何以 Exchange Server 2007 相容的方式來同步處理 SharePoint 收件者資訊。您同樣可以使用自訂解決方案,將收件者資訊與 IBM Lotus Notes 或其他系統同步處理。

您也能夠根據 Metadirectory 服務 (例如內含在 Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1) 中的 Identity Information Server) 將目錄佈建程序集中化。更具體的說,我會向您說明如何將 SharePoint 與 ILM 2007 相整合,以協調 SharePoint 文件庫的目錄物件的佈建作業。您可以在本專欄隨附的資料 (可從 Technetmagaine.com 中的「程式碼下載 (Code Downloads)」區段取得) 中找到建置此解決方案的工具、原始程式碼和逐步指示。

SharePoint 目錄管理服務

與 Exchange Server 不同 (幾乎所有設定和收件者資訊都是使用 Active Directory),SharePoint 仰賴的是設定和內容資料庫。SharePoint 因此必須將啟用郵件功能的文件庫、清單和群組的收件者資訊,從資料庫傳播到目錄。畢竟,郵件用戶端會預期在通訊錄中找到收件者資訊,而通訊錄一般是從目錄物件產生。

針對此目的,SharePoint 包含了一個現成的目錄管理服務,它是電子郵件整合 Web 服務 (SharepointEmailWS.asmx) 的一部分,您可以在 SharePoint 3.0 管理中心的 [作業] 頁面上的 [內送電子郵件] 設定下進行設定。[圖 1] 圖解內建目錄管理服務的運作方式。

fig01.gif

[圖 1] SharePoint 目錄管理服務架構 (按一下以放大影像)

當您啟用 Web 伺服陣列以進行目錄管理,然後為文件庫、清單或群組指定電子郵件地址以接收郵件時 (例如利用 EmailSettings.aspx),您等於是以隱含的方式呼叫電子郵件整合 Web 服務在 Active Directory 中佈建相對應的收件者物件。首先,SharePoint 會將電子郵件地址資訊儲存在內容資料庫中。接下來,SharePoint 會使用 Web 應用程式集區帳戶的身分,代表您將佈建要求傳送到電子郵件整合 Web 服務。如果佈建要求失敗,您最後會在內容資料庫中得到電子郵件地址資訊,但在 Active Directory 卻不會有相對應的收件者物件。

其他資源

佈建要求失敗的原因有好幾種。最常見的原因是缺乏 IIS Metabase 存取權限。因為 SharepointEmailWS.asmx 是為了作為應用程式集區帳戶的 Web 服務而設計的,所以此 Web 服務會檢查 IIS Metabase 確定呼叫者是否是應用程式集區帳戶,若不是則拒絕存取,無論您的 SharePoint 網站和 Active Directory 權限的等級為何。

不過,SharepointEmailWS.asmx 會在呼叫者的身分下執行這項存取檢查,因此呼叫應用程式集區帳戶必須要存取 Metabase 才能確認它自己的存取權限。這會強迫您授與應用程式集區帳戶提高權限,以便順利存取。

不用說,網頁伺服器上的提高權限向來是安全性顧慮的源頭。要控制對 ASP.NET Web 服務的存取有更好的方法。況且,SharePoint 也預期在管理中心網站中找到目錄管理服務,但是這個網站在為了縮小受攻擊面而鎖定的 Web 伺服陣列中並不永久可用。因此,如果您想要在您的 SharePoint 生產環境中使用內建目錄管理服務,就必須接受比較脆弱的安全性設定。

另外,也因為內建目錄管理服務是以緊密結合的用戶端/伺服器架構為基礎,而存在了額外的限制。Microsoft.SharePoint.dll 是直接使用 System.DirectoryServices.dll,因此您無法實作您自己的邏輯來自訂佈建程序。舉例來說,內建目錄管理服務實作並不會寫入所有收件者屬性來支援 Exchange Server 2007,而且也沒有任何選項可自訂屬性產生規則。

無法實作您自己的邏輯也暗示了您無法自訂佈建程序進行一些動作,例如實作自訂核准。SharePoint 支援群組的核准程序,但是這項功能是以管理中心網站為基礎。只有 SharePoint 伺服陣列系統管理員能夠核准擱置中的要求,但 SharePoint 系統管理員並不一定是負責核准 Active Directory 佈建程序的人。

或許更為重要的是,對於啟用郵件功能的文件庫和清單來說,並沒有所謂的核准程序。假若您啟用目錄管理,您基本上是把在 Active Directory 中建立啟用郵件功能的連絡人和群組的權限,授與您 Web 伺服陣列當中的所有網站系統管理員。要根據組織單位 (OU) 來建構收件者管理也是不可能的,因為每個 Web 伺服陣列的所有收件者物件都是放在相同的 OU 中。

您無法將收件者物件移到其他 OU 中,因為目錄管理服務會預期在 SharePoint OU 中找到收件者物件,而且您必須在 Active Directory 中授與 SharePoint 管理中心應用程式集區帳戶系統管理權限。另外,要在 SharePoint 與 Active Directory 之間實作雙向同步處理也是不可能的。而變更 Active Directory 中的物件屬性並不能將變更傳播回 SharePoint 環境中。

自訂目錄管理服務

現在證實內建目錄管理服務有留空間以發展出更大的彈性後,讓我們來討論一些其他替代方案。好消息是,SharePoint 可讓您實作自己的目錄管理服務。您只需要在 SharePoint 3.0 管理中心的 [作業] 頁面的 [內送電子郵件] 設定下,將 Web 服務當作遠端目錄管理服務註冊就大功告成了。

如需部署和註冊自訂 Web 服務的詳細逐步指示,請參閱隨附資料中的「Directory Integration Based on a Custom Directory Management Service.xps」工作表。另外,我的自訂 Web 服務也說明了如何在沒有指令程式或 Exchange 管理工具的情況下,在 Active Directory 中佈建 Exchange Server 2007 相容的收件者物件。相對應的原始程式碼位於 EmailIntegrationService 資料夾中。[圖 2] 圖解說明了解決方案的架構。

fig02.gif

[圖 2] 自訂目錄管理服務架構 (按一下以放大影像)

如 SharePoint SDK 中所述,自訂 Web 服務的介面必須遵守目錄管理服務介面。如果您在 MSDN® 網站 (msdn.microsoft.com) 上搜尋「SharepointEmailWS」,就可以找到所有必要的詳細資料。您也可以查看隨附資料中 EmailIntegrationService\App_Code 資料夾內的 Service.cs 檔案。這個檔案會實作必要的 Web 服務介面,而佈建 Active Directory 物件的實際程式碼則位於 SPRecipient.cs 中。例如,SPRecipient.cs 中的 UpdateRecipientAttributes 函數會產生必要的 Exchange Server 2007 屬性。如果您想要開發自己的自訂目錄管理服務,就必須取代 SPRecipient.cs 這個程式碼檔案。

自訂目錄管理服務是克服提高權限需求,以及將 SharePoint 與協力廠商目錄或郵件系統相整合的好工具。您不必檢查 IIS Metabase 來限制 Web 服務對應用程式集區帳戶的存取。相反地,您可以在 Web 服務的 web.config 檔案中新增 <authorization> 區段 (請參閱隨附資料中的範例)。

不過,還是有幾個問題,因為您不能控制 SharePoint 是否以及何時會呼叫您的目錄管理服務。除此之外,當您刪除啟用郵件功能的文件庫或清單時,SharePoint 也不會呼叫目錄管理服務,而使得無效的收件者物件繼續留在 Active Directory 中。無論您是使用內建目錄管理服務還是自訂解決方案,您都無法保證 Active Directory 中的收件者資訊會與 SharePoint 資源保持一致。

SharePoint 與 ILM

為了達成可靠的目錄整合,您應該考慮部署專業目錄管理套件,例如 ILM。這個系統仰賴的是以提取為主的目錄同步處理模型。管理代理程式會從它們連接的來源提取資訊,將資訊匯入通用的 Metadirectory,然後從 Metadirectory 匯出資訊到它們連接的系統中。來源系統一般不會將它們的資訊推入 Metadirectory 中。透過提取資訊,您可以確保與每個同步處理周期保持一致。

另外一個好處是,ILM 包含了幾個支援 Active Directory、Lotus Notes 和各種其他現成系統的管理代理程式。您只需要為 SharePoint 實作一個自訂管理代理程式,就能將 SharePoint 資訊與您環境中其他受到支援的平台同步處理。

您必須實作邏輯從 SharePoint 擷取所要的資訊,將資訊儲存到匯入檔案,然後將匯入的資訊傳輸到 Metadirectory。但是將資訊從 Metadriectory 匯出到 Active Directory 或其他目錄平台時,並不需要實作邏輯。[圖 3] 圖解說明了如何使用 ILM 從 SharePoint 實作同步處理到 Active Directory。要從其他方向佈建目錄物件的 SharePoint 資源來進行同步處理也是可行的,不過這可能沒有必要或是次要的。

fig03.gif

[圖 3] 以 Identity Lifecycle Manager 為主的目錄整合 (按一下以放大影像)

Alex Tcherniakhovski 所著的<連接 ILM 2007 與 SharePoint Service 清單>(英文) 一文是開發 SharePoint 管理代理程式一個不錯的出發點,網址是 blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx。Alex 說明了如何建置 ILM 架構的目錄管理解決方案,仰賴提交給文件庫以 InfoPath® 為主的佈建要求。Alex 的管理代理程式從文件庫擷取所有核准的要求,然後建立相對應的 Metadirectory 物件,之後再匯出到連接的目錄中。

但是在預設的情況下,當您啟用清單或群組的郵件功能時,SharePoint 並不會產生以 InfoPath 為主的佈建要求。您可以透過自訂目錄管理服務來完成這個動作,但是您之後會碰到先前提到的一致性問題,因為 SharePoint 無論如何都不會呼叫目錄管理服務。有基於此,我建議您的管理代理程式直接從您網站集合中的清單和群組擷取所要的 SharePoint 收件者資訊。如果您需要核准程序,隨後可在管理代理程式中針對新資源產生以 InfoPath 為主的佈建要求,後續再處理所有核准的要求。

要擷取 SharePoint 資訊,您有幾個選擇。您可以直接從內容資料庫讀取資訊,使用 SharePoint 物件模型,或是利用 SharePoint Web 服務。

我不建議直接存取內容資料庫,因為未來版本中的資料庫結構可能會有所變化,而可能打斷您的目錄管理解決方案。

在您的管理代理程式中直接使用 SharePoint 物件模型也一樣麻煩,因為物件模型會要求您在本機執行程式碼,而在您環境內每個 SharePoint 伺服陣列中的網頁伺服器上安裝 ILM,可能會使目錄管理基礎結構複雜化。

您可能會想要使用 SharePoint Web 服務,但是這會製造另一個難題,因為您要的資訊透過 SharePoint Web 服務並不容易存取,例如 SharePoing 群組的電子郵件地址資訊,或內送電子郵件伺服器顯示位址。

到最後,似乎實作自訂 SharePoint Web 服務,使用 SharePoint 物件模型來擷取所要的資訊,以 XML 文件的形式把它傳回呼叫者才是上策。現在您可以將 ILM 部署集中化,並透過自訂 SharePoint Web 服務個別的執行個體,整合任何數目的伺服陣列和網站集合,如 [圖 3] 所示。

另外還有一點值得一提的是,進行 ILM 為主的目錄整合,還是需要自訂目錄管理服務。這項自訂服務並不需要執行任何工作,因為 ILM 會佈建目錄物件,但是您必須提供自訂服務,如此一來,您才能在 SharePoint 3.0 管理中心啟用目錄管理。否則的話,您一開始就無法指定電子郵件地址給群組。[圖 4] 說明所得的解決方案架構。

fig04.gif

[圖 4] 以 Web 服務為基礎的 SharePoint 目錄整合 (按一下以放大影像)

您可以把隨附資料中的自訂目錄管理服務變成虛擬服務,方法是在 web.config 檔案中設定 OpMode 參數 (<add key="OpMode" value="dummy"/>)。在這種設定中,自訂服務不會執行任何工作,始終都會傳回 SUCCESS 來回應佈建呼叫。

此外,自訂服務會公開一個 ResolveUsers 方法,SharePoint 管理代理程式可以呼叫這個方法將以 NetBIOS 為主的使用者帳戶名稱解析成辨別名稱,這是佈建群組時的必要步驟 (SharePoint 會把群組成員資格資訊傳回成以 NetBIOS 為主的使用者帳戶名稱清單,但是 Active Directory 預期的則是辨別名稱)。這樣就大功告成了!如需如何部署所得的解決方案的詳細資訊,請參閱隨附資料中的「Configuring Directory Integration based on ILM 2007.xps」。

WSS 3.0 和 MOSS 2007 都包含了目錄管理服務,可將 SharePoint 與 Exchange Server 2003 整合進行以郵件為主的跨平台協作。

不過,還是有幾項限制。使用者必須以自訂解決方案取代內建目錄管理服務。您也可以使用專業目錄管理解決方案,像是 ILM,將 SharePoint 整合到目錄管理基礎結構。這提供了最高度的彈性,而且有助於透過以提取為基礎的同步處理模型確保資訊的一致性。

Pav Cherny 是 IT 專家兼作者,專攻 Microsoft 共同作業與整合通訊技術。其著述包括白皮書、產品手冊和探討 IT 營運和系統管理的書籍。同時 Pav 也是專營管理文件與本土化服務之 Biblioso Corporation 的總裁。