Integrate SharePoint with Custom Directory Solutions

[アーティクル]
08/25/2016

SharePoint の内部SharePoint のディレクトリ統合

Pav Cherny

コードのダウンロード : SharePoint2008_09.exe(2,775 KB)

Microsoft Windows SharePoint Services (WSS) 3.0 および Microsoft Office SharePoint Server (MOSS) 2007 には、Directory Management Service という形式のディレクトリの同期機能が含まれています。この機能を使用すると、Active Directory の SharePoint リソース用に、メールが有効な連絡先およびグループオブジェクトを準備することができます。このような種類の

SharePoint® リソース用の受信者オブジェクトを準備すると、ユーザーはドキュメントや他の情報を送信する際に、Microsoft® Outlook® アドレス帳から SharePoint ライブラリ、リスト、およびグループを直接選択できます。

また、SharePoint 受信者オブジェクトにより、Exchange Server 組織でメッセージ転送や形式変換を制御する方法ももたらされます。特に、スパム送信者などの認証されていない送信者が、Active Directory® のメッセージの配信制限を設定して SharePoint ライブラリにメッセージを送信するのを防ぐことができます。

ただし、SharePoint のディレクトリ管理機能は限られています。この記事の執筆時点では、基盤となるメッセージングシステムとして Exchange Server 2003 を想定しています。現時点では、Exchange Server 2007 かサードパーティのメッセージングシステムを使用する場合に必要なレベルの相互運用性を実現するためには、組み込みのディレクトリ管理機能をカスタムソリューションに拡張するか、置き換える必要があります。

今月のコラムでは、SharePoint のディレクトリ管理機能について簡単に確認し、既存の制限事項を克服する手法について説明します。組み込みの Directory Management Service は、最も基本的なユーザー要件だけを満たすことを前提としています。さまざまなメッセージングシステムやディレクトリプラットフォームが存在する環境では、より優れた柔軟性および機能が必要になります。組み込みのコンポーネントをカスタムソリューションに置き換えることによって、SharePoint の受信者情報と、API やインポート機能を提供する任意のディレクトリソリューションとの同期を取ることができます。

この点を証明するために、Exchange Server 2007 と互換性がある、SharePoint の受信者情報の同期方法について説明します。同様に、カスタムソリューションを使用して受信者情報と IBM Lotus Notes やその他のシステムとの同期を取ることができます。

また、Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1) に含まれている Identity Information Server などのメタディレクトリサービスに基づいてディレクトリの準備処理を一元管理する機能も提供されます。ここでは特に、SharePoint と ILM 2007 を統合して、SharePoint ドキュメントライブラリ用にディレクトリオブジェクトの準備を調整する方法について説明します。このソリューションを構築するためのツール、ソースコード、および順を追った説明は、このコラムの付属リソース (technetmagazine.com のコードダウンロードセクションからダウンロードできます) として入手できます。

SharePoint Directory Management Service

Exchange Server ではほぼすべての構成情報および受信者情報用に Active Directory が使用されますが、それとは異なり、SharePoint では構成データベースおよびコンテンツデータベースが使用されます。そのため、SharePoint では、メールが有効なライブラリ、リスト、およびグループの受信者情報をデータベースからディレクトリに反映する必要があります。いずれにせよ、メッセージングクライアントは受信者情報がアドレス帳で見つかることを期待しており、通常、その受信者情報はディレクトリオブジェクトから生成されるためです。

SharePoint ではこういった目的のために組み込みの Directory Management Service が含まれています。この Directory Management Service は、E-mail Integration (電子メール統合) Web サービス (SharepointEmailWS.asmx) の一部で、SharePoint 3.0 サーバーの全体管理の [サーバー構成の管理] ページの [受信メールの設定] で構成できます。図 1 は、組み込みの Directory Management Service のしくみを示しています。

図 1 SharePoint Directory Management Service のアーキテクチャ(画像をクリックすると拡大表示されます)

ディレクトリ管理のために Web ファームを有効にしてから、EmailSettings.aspx を使用するなどしてライブラリ、リスト、またはグループに電子メールアドレスを割り当ててメッセージを受信できるようにした場合は、E-mail Integration (電子メール統合) Web サービスを暗黙に呼び出して、Active Directory に対応する受信者オブジェクトを準備します。まず、SharePoint では電子メールアドレスの情報がコンテンツデータベースに格納されます。次に、Web アプリケーションプールアカウントの ID を使用して、準備要求が E-mail Integration (電子メール統合) Web サービスに送信されます。準備要求が失敗すると、コンテンツデータベース内に電子メールアドレス情報は格納されますが、Active Directory には対応する受信者オブジェクトが存在しなくなります。

関連リソース

準備要求の失敗には多くの原因があります。最も一般的な原因は IIS メタベースへのアクセス許可がないことです。SharepointEmailWS.asmx はアプリケーションプールアカウントの Web サービスになるよう設計されているため、この Web サービスは IIS メタベースをチェックして、呼び出し元がアプリケーションプールアカウントかどうかを確認します。そうでない場合は、SharePoint サイトおよび Active Directory のアクセス許可レベルに関係なく、アクセスを拒否します。

ただし、SharepointEmailWS.asmx は呼び出し元の ID を使用してこのアクセス確認を実行します。そのため、アプリケーションプールアカウントを呼び出す場合、メタベースにアクセスして、自身のアクセス許可を確認する必要があります。これを成功させるには、アプリケーションプールアカウントのアクセス許可を昇格することが必要になります。

もちろん、Web サーバーで昇格されたアクセス許可は、セキュリティ上の懸念事項の要因になります。ASP.NET Web サービスへのアクセスを制御する場合さらに優れた方法があります。そのうえ、SharePoint ではサーバーの全体管理サイトに Directory Management Service が見つかることを想定していますが、このサイトは、攻撃を受ける可能性のある領域を減らすためにロックダウンされている Web ファームではまったく使用することができません。そのため、SharePoint の運用環境で組み込みの Directory Management Service を使用する場合は、セキュリティ構成が緩和されることを受け入れる必要があります。

組み込みの Directory Management Service が、クライアントとサーバーが緊密に結び付けられたアーキテクチャに基づいていることからさらに制限が生じます。Microsoft.SharePoint.dll は System.DirectoryServices.dll を直接使用します。そのため、独自のロジックを実装して準備処理をカスタマイズすることはできません。たとえば、組み込みの Directory Management Service 実装では、Exchange Server 2007 をサポートするための受信者属性の一部が書き込まれず、属性の生成ルールをカスタマイズするオプションがありません。

独自のロジックを実装できないということは、たとえば、準備処理をカスタマイズして、カスタムの承認を実装できないことを表します。SharePoint では、グループに対する承認プロセスがサポートされますが、この機能はサーバーの全体管理サイトに基づいています。SharePoint ファームの管理者だけが保留中の要求を承認できますが、SharePoint 管理者は必ずしも Active Directory 準備処理の承認を担当するわけではありません。

さらに重要なのは、メールが有効なドキュメントライブラリやリストの承認プロセスがない点です。ディレクトリ管理を有効にすると、基本的に Web ファーム内のすべてのサイト管理者に、Active Directory でメールが有効な連絡先およびグループを作成する権利が与えられます。Web ファームごとのすべての受信者オブジェクトが同じ組織単位 (OU) に格納されるため、OU に基づいて受信者管理を構造化することもできません。

Directory Management Service では SharePoint OU 内で受信者オブジェクトが見つかることを想定しているため、受信者オブジェクトを別の OU に移動することはできません。そのため SharePoint サーバーの全体管理アプリケーションプールアカウントに Active Directory の管理者アクセス許可を付与する必要があります。また、SharePoint と Active Directory の間で双方向同期を実装する方法がありません。Active Directory でオブジェクトの属性を変更しても、その変更は SharePoint 環境には反映されません。

カスタム Directory Management Service

組み込みの Directory Management Service で柔軟性の向上を実現できる余地があることは証明できたので、別の方法についていくつか説明しましょう。よい知らせとしては、SharePoint を使用して独自の Directory Management Service を実装できることが挙げられます。必要な操作は、SharePoint 3.0 サーバーの全体管理の [サーバー構成の管理] ページの [受信メールの設定] で、Web サービスをリモート Directory Management Service として登録することだけです。

カスタム Web サービスを配置および登録するための順を追った詳細な説明については、付属リソースの Directory Integration Based on a Custom Directory Management Service.xps ワークシートを参照してください。また、私が作成したカスタム Web サービスは、コマンドレットや Exchange 管理ツールを使用しないで、Exchange Server 2007 と互換性がある受信者オブジェクトを Active Directory に準備する方法を示しています。対応するソースコードは EmailIntegrationService フォルダにあります。図 2 はこのソリューションのアーキテクチャを示しています。

図 2 カスタム Directory Management Service のアーキテクチャ(画像をクリックすると拡大表示されます)

SharePoint SDK で説明されているように、カスタム Web サービスのインターフェイスは、Directory Management Service インターフェイスに準拠する必要があります。MSDN® Web サイト (msdn.microsoft.com) で "SharepointEmailWS" を検索すると、必要なすべての詳細情報を入手できます。また、付属リソースの EmailIntegrationService\App_Code フォルダにある Service.cs ファイルも確認してください。このファイルは、必須の Web サービスインターフェイスを実装しますが、Active Directory オブジェクトを準備する実際のコードは SPRecipient.cs にあります。たとえば、SPRecipient.cs の UpdateRecipientAttributes 関数は、Exchange Server 2007 の必須属性を作成します。SPRecipient.cs はコードファイルです。独自にカスタム Directory Management Service を構築する場合は、このコードファイルを置き換える必要があります。

カスタム Directory Management Service は、アクセス許可の昇格の必要性をなくし、SharePoint をサードパーティのディレクトリまたはメッセージングシステムと統合するための優れたツールです。IIS メタベースを確認して Web サービスによるアプリケーションプールアカウントへのアクセスを制限する必要はありません。代わりに、Web サービスの web.config ファイルに <authorization> セクションを追加できます (例については、付属リソースを参照してください)。

ただし、いくつか問題が残ります。作成した Directory Management Service を SharePoint が呼び出すかどうかや、呼び出すタイミングを制御できません。特に、メールが有効なドキュメントライブラリやリストを削除した場合、SharePoint は Directory Management Service を呼び出しません。そのため、個々の受信者オブジェクトが Active Directory に残ります。組み込みの Directory Management Service またはカスタムソリューションのどちらを使用する場合でも、Active Directory の受信者情報が SharePoint リソースと一致するという保証はありません。

SharePoint と ILM

ディレクトリの統合を信頼できるものにするには、ILM のような本格的なディレクトリ管理パッケージの展開を検討する必要があります。このシステムでは、収集ベースのディレクトリ同期モデルが使用されます。管理エージェントは接続先のソースから情報を収集し、その情報を共通のメタディレクトリにインポートし、メタディレクトリから情報をエクスポートして、接続先のシステムに格納します。接続元のシステムでは、通常、情報をメタディレクトリに格納しません。情報を収集することによって、それぞれの同期サイクルとの一貫性を保つことができます。

もう 1 つのメリットは、Active Directory、Lotus Notes など市販のさまざまなシステムをサポートするエージェントが ILM に含まれていることです。必要な操作は、SharePoint 用のカスタム管理エージェントを実装して、環境内でサポートされている別のディレクトリプラットフォームと SharePoint 情報との同期を取ることだけです。

SharePoint から必要な情報を取得し、その情報をインポートファイルに保存して、インポートされた情報をメタディレクトリに転送するロジックを実装する必要があります。しかし、その情報をメタディレクトリから Active Directory または別のディレクトリプラットフォームにエクスポートするロジックを実装する必要はありません。図 3 は、ILM を使用して SharePoint から Active Directory への同期を実装する方法を示しています。その他の方向に同期を行ってディレクトリオブジェクト用の SharePoint リソースを準備することもできますが、この方法は不要または省略可能と見なされています。

図 3 Identity Lifecycle Manager ベースのディレクトリ統合(画像をクリックすると拡大表示されます)

SharePoint の管理エージェントを開発する際は、手始めに blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx にある Alex Tcherniakhovski の記事「ILM 2007 と SharePoint Services リストの接続」を参照することをお勧めします。Alex は、ドキュメントライブラリに送信された InfoPath® ベースの準備要求を使用する、ILM を基にしたディレクトリ管理ソリューションを構築する方法を説明しています。Alex の管理エージェントは承認されたすべての要求をドキュメントライブラリから取得し、対応するメタディレクトリオブジェクトを作成します。その後、メタディレクトリオブジェクトが接続先のディレクトリにエクスポートされます。

しかし SharePoint の既定では、リストまたはグループのメールを有効にしたときに、InfoPath ベースの準備要求は生成されません。カスタム Directory Management Service を使用するとこの操作を実現できますが、そうすると、どのような状況でも SharePoint から Directory Management Service が呼び出されないことが原因で前述した一貫性の問題が発生します。このような理由から、作成した管理エージェントでは、必要な SharePoint の受信者情報をサイトコレクション内のリストおよびグループから直接取得することをお勧めします。承認プロセスが必要な場合は、管理エージェントで新しいリソース用の InfoPath ベースの準備要求を生成し、その後承認されたすべての要求を処理します。

SharePoint 情報を取得するオプションはいくつかあります。SharePoint オブジェクトモデル、または SharePoint Web サービスを利用して、コンテンツデータベースから情報を直接読み取ることができます。

コンテンツデータベースに直接アクセスすることはお勧めできません。将来のバージョンではデータベース構造が変更される可能性があり、それによりディレクトリ管理ソリューションが機能しなくなるためです。

管理エージェントで SharePoint オブジェクトモデルを直接使用することは、同じように少し複雑になります。オブジェクトモデルではコードをローカルで実行することが求められますが、環境内のあらゆる SharePoint ファーム上の Web サーバーに ILM をインストールすることは、ディレクトリ管理のインフラストラクチャを複雑にする可能性があるためです。

SharePoint Web サービスを使用することを考えるかもしれませんが、そうすると、SharePoint Web サービスを使用して必要な情報 (SharePoint グループの電子メールアドレス情報や受信メールサーバーの表示アドレス) に簡単にアクセスできないため、別の問題が発生します。

結局、SharePoint オブジェクトモデルを使用するカスタム SharePoint Web サービスを実装して必要な情報を収集し、その情報を XML ドキュメントの形式で呼び出し元に返すのが最善のように思えます。図3 に示されているように、カスタム SharePoint Web サービスの個別のインスタンスを使用して、ILM の展開を一元化し、さまざまなファームおよびサイトコレクションを統合することができます。

触れておかなければならない点がもう 1 つ残っています。それは、ILM ベースのディレクトリ統合では、カスタム Directory Management Service の必要性がなくならない点です。このカスタムサービスでは、ILM によってディレクトリオブジェクトが準備されるため、何も行う必要がありません。ですが、SharePoint 3.0 サーバーの全体管理でディレクトリの管理を有効にできるようにするカスタムサービスを提供する必要があります。そうしないと、たとえば、最初に電子メールアドレスをグループに割り当てることができません。図4 は最終的なソリューションアーキテクチャを示しています。

図 4 Web サービスを基にした SharePoint のディレクトリ統合(画像をクリックすると拡大表示されます)

web.config ファイルの OpMode パラメータ (<add key="OpMode" value="dummy"/>) を設定することによって、付属リソースに含まれているカスタム Directory Management Service をダミーのサービスに変更できます。この構成では、何も行わなくても、カスタムサービスにより、準備の呼び出しに応答して常に成功が返されます。

また、カスタムサービスは ResolveUsers メソッドを公開します。このメソッドは、SharePoint の管理エージェントから呼び出され、NetBIOS ベースのユーザーアカウント名を識別名に解決します。この手順は、グループを準備するときに必要になります (SharePoint はグループのメンバシップ情報を NetBIOS ベースのユーザーアカウント名の一覧として返しますが、Active Directory では識別名が前提とされています)。これで処理は完了です。最終的なソリューションの配置方法の詳細については、付属リソースに含まれている Configuring Directory Integration based on ILM 2007.xps ファイルを参照してください。

WSS 3.0 および MOSS 2007 には Directory Management Service が含まれており、さまざまなプラットフォームで動作するメッセージングベースのコラボレーション用に、SharePoint を Exchange Server 2003 に統合できます。

ただし、いくつかの制限があります。ユーザーは組み込みの Directory Management Service をカスタムソリューションに置き換える必要があります。また、ILM などの本格的なディレクトリ管理ソリューションを使用して、ディレクトリ管理のインフラストラクチャに SharePoint を統合することもできます。この方法によって最も高いレベルの柔軟性が提供され、収集ベースの同期モデルを使用することによって情報の一貫性が保たれます。

Pav Cherny は、主にコラボレーションとユニファイドコミュニケーションに関するマイクロソフトテクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイトペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズサービスの専門企業 Biblioso Corporation の代表取締役です。

目次

その他のリソース