複数フォレストの考慮点

この資料の目的は、Microsoft® Windows® 2000 Server または Microsoft® Windows Server 2003 オペレーティング システムを実行しているドメイン コントローラを持つ複数フォレスト間で、コラボレーションのレベルの変化に対応するために必要な作業やインフラストラクチャの概要を紹介することです。この資料では、複数フォレストの環境が必要な事例や複数フォレストの環境を選択すべき事例を挙げ、このような環境での企業の総コストへの影響を分析します。

トピック

  対象読者

  はじめに

  複数フォレストの展開

  複数フォレスト展開の追加コスト

  フォレスト間での機能の追加構成

  複数フォレスト機能の実装とコストのまとめ

対象読者

この資料は、Active Directory の展開をデザインしているか、複数の Active Directory フォレストを必要とする可能性を認識しているか、または複数フォレストに変更する必要がある既存の単一のフォレスト環境を持っている設計者またはプロジェクト マネージャを対象にしています。この資料を使って、複数の Active Directory フォレストの展開が総コストに及ぼす影響を理解し、計画を立てることができます。

この資料は、複数フォレストの展開時期を推奨したり、複数フォレストの展開方法を規定するガイドラインではありません。目的は、フォレスト間のコラボレーションの実現に必要な、高レベルな構成変更の概要を示すことです。マイクロソフトは、このような構成変更の実装の詳しい指示を提供する展開ガイドを発行する予定です。

複数フォレストの展開を考慮する条件に関する詳細については、「Design Considerations for Delegation of Administration in Active Directory」(英語) を参照してください。このドキュメントは、Microsoft® TechNet Web サイト (https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/addeladm.mspx) で参照できます。

一般的な Active Directory 展開に関する情報については、「Best Practice Active Directory Design for Managing Windows Networks」(英語) を参照してください。このドキュメントは、Microsoft TechNet Web サイト(https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx) で参照できます。

Windows 2000 Server 環境で Active Directory を含むMicrosoft® Exchange 2000 Server の展開に関する情報については、「Best Practice Active Directory Design for Exchange 2000」(英語) を参照してください。このドキュメントは、Microsoft Web サイト (https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=F53662B9-4E69-40CE-AA19-7B0C48710403) からダウンロードできます。

ページのトップへ

はじめに

フォレストのルート ドメインの管理者は、Active Directory® のスキーマ データ、構成データ、ドメイン コントローラを管理でき、フォレスト全体の監視ができます。管理者に与えられたこのような権限は、悪意のあるユーザーによって乱用される可能性があります。さらに、自律性と分離性が必要な場合は、単一ドメインによる展開では十分に対応できない場合があります。特に大規模組織には、組織上、法律上、運用上の理由により独立したフォレストで運用する必要性があります。

複数フォレストを展開する必要性は、最初に展開を計画するときに、認識され、調整されます。また、展開後の組織変更により、計画していなかった必要性が生じる場合もあります。どちらの場合も、以下に示すような重要な問題点があります。

• 計画済みの複数フォレストの展開 : 複数フォレストの計画中に、実装に新たなコストが生じることに対して、それに見合う利点があるかどうかを十分に評価します。
• 計画していなかった複数フォレストの展開 : ビジネス上の意思決定の結果として、展開済みの環境にフォレストの追加が必要になる合併、買収、再編成が生じる場合、複数フォレストの実装、フォレスト間のコラボレーションに対応する、柔軟なプロセスを準備します。

複数の Active Directory フォレストへ移行する Windows 展開の担当部門は、単一の Active Directory フォレストでは既定で利用できるいくつかの機能も、複数フォレストの展開では新たな構成が必要になることを理解した上で移行を担当する必要があります。

 注
Active Directory を使用するアプリケーションでは、一部の単一フォレストの機能が複数フォレスト展開では使用できません。たとえば、あるメールボックス関連の機能は、Microsoft® Exchange 2000 Server を実装した複数フォレスト展開では使用できないので、回避策が必要になります。このような機能やソリューションについては、この資料の後半の「フォレスト間で使用できない機能」を参照してください。

組織内に複数フォレストが存在する環境で、データやサービスを提供するためには、次の機能に新たな構成が必要になります。

• フォレストの境界をまたがるドメイン ネーム システム (DNS) の名前解決。
• 複数フォレスト間でのアドレス一覧情報の同期や予定表の空き時間情報などの、Microsoft Exchange 2000 Server 以降の機能。
• フォレスト間でのリソースへのアクセス。
• フォレストの境界にまたがるインフラストラクチャ データの同期。
• 複数フォレスト間でのアプリケーション データの同期。
•  注
  この資料では、順を追った構成の指示は提供しません。マイクロソフトは、今後、展開の情報に重点を置いた展開ガイドを発行する予定です。

この資料では、それぞれの新たな構成の論理的根拠を説明します。複数フォレスト展開の計画済み状態、または計画されていない状態の概要とその影響も説明します。

この資料では説明しないこと

単一の Active Directory フォレストではなく、複数の Active Directory フォレストをいつ実装するかを推奨するのは、この資料の目的ではありません。複数フォレストを展開する予定があり、運用上、組織上、法律上、Active Directory の必要性が分析済みで、複数の Active Directory フォレストの作成が必要であると既に判断していると想定しています。

これらの条件を検討するために、次に示す資料を先にお読みください。

• サービスの自律性、サービスの分離性またはデータの分離性を実現するための、複数フォレストへの分割、Windows ネットワークの分割を考慮する条件の説明については、「Design Considerations for Delegation of Administration in Active Directory」(英語) を参照してください。このドキュメントは、Microsoft TechNet Web サイト (https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/addeladm.mspx) で参照できます。
• 一般的な Active Directory 展開の計画に関する情報については、「Best Practice Active Directory Design for Managing Windows Networks」(英語) を参照してください。この資料は、Microsoft TechNet Web サイト (https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx) で参照できます。
• なお、この資料では下記の情報は提供しません。
• 複数フォレストでどのように機能を構成するかの順を追った指示。マイクロソフトは、構成変更の実装を指示する展開ガイドを発行する予定です。
• 企業が合併したときに、複数フォレストを統合するか、"ブリッジ" するかどうかの推奨事項、またはその方法。
• 再構成の準備のために、フォレストをどのように分離するかの指示。

ページのトップへ

複数フォレストの展開

複数フォレストを展開する場合、ディレクトリ サービスを独立して管理する必要性 (自律性)、または干渉される心配なくデータやサービスを管理すること (分離性) を考慮して決定を下します。Microsoft® Windows® NT 4.0 オペレーティング システムの展開では、ドメインが基本的なコンポーネントであり、管理や境界が分離されています。Microsoft® Windows 2000 の Active Directory の導入と共に、新しい概念である "フォレスト" が導入されました。フォレストは、すべてのドメインに対するサービスやデータを含みます。

Active Directory ドメインでのサービスとデータ分離性または自律性の可用性は、そのドメインの管理者やフォレストの管理者だけでなく、フォレスト内の他のドメインの管理者にも依存します。

フォレストをデザインするときは、管理の独立性を維持するにはコストがかかることを覚えておいてください。相互運用性やコラボレーションと、自律性や分離性とを十分に比較検討する必要があります。

自律性と分離性の管理

Active Directory の管理は、2 つの一般的なカテゴリに分類できます。

• サービス管理 : ディレクトリ サービスの構成と配信。
• データ管理 : ディレクトリ コンテンツの作成と管理。(アカウント管理、組織的な単位の管理。

Active Directory は、管理領域の制御を委任することができます。委任はフォレスト、ドメイン、組織単位など、いくつかのレベルで発生します。独立の必要性は、組織の性質に応じて、このような各レベルで、さらにサービスやデータのそれぞれの分類ごとに幅広く変化します。

基本的には、ドメインや組織単位を使用してデータを管理したり、フォレストのルート レベルでサービスの管理者を信頼することにより、単一フォレスト内で十分なレベルの制御を委任することができます。ただし、以下の独立の必要性は、単一フォレストの委任制御の制限事項を超える場合があります。

• サービスの自律性 : スキーマ コンテナや構成コンテナを個別に管理および操作できるようにします。このレベルの制御の必要性は、通常、組織の構成または運用上の必要性の影響を受けます。たとえば、企業の 1 部門が、IT (情報技術) 部門本部の承認に依存せずに、スキーマを拡張するディレクトリ対応のアプリケーションをインストールするような場合です。
• サービスの分離性 : 組織外のユーザーや管理者以外のユーザーが、ディレクトリ サービスの運用に干渉できないようにします。このレベルの制御の必要性は、通常、法律上または運用上によるものです。たとえば、ホスティング企業が、ユーザーの社内にドメイン コントローラを設置すると仮定します。そのドメイン コントローラでの操作によってフォレスト全体でのサービス配信に影響を与える可能性があります。この場合は、ディレクトリ サービスの他のユーザーを適切に保護するために、ユーザーの運用を独自のフォレストに分離します。
• データの分離性 : 管理者以外のユーザーが、特定のスコープ以外のドメイン コントローラまたはフォレスト内のメンバ コンピュータ上のデータを、制御または表示できないようにします。この必要性は、通常、法律上の必要性に基づきます。たとえば、財務団体の場合、特定の法域内のユーザー、コンピュータ、管理者に対して、その法域以外のコンピュータにあるデータへのアクセスを制限することが、法律によって必要とされる場合です。

計画されていない展開

複数フォレストの展開の必要性は、常に、事前に計画されているわけではありません。単一フォレストの展開から複数フォレストの展開への変更は、次のようなビジネス上の決定の際に必要になります。

• 合併と買収 : 合併、買収された組織が、既存のフォレストを使用すると仮定すると、新規組織と元の組織の異なる部署からのユーザーとリソースの間でのコラボレーションを可能にする必要があります。
• 再編成 : 企業の一部の組織を売却すると決定したとき、組織の実際の分離より前に、移転予定部門のユーザーとリソースを調整するフォレストを作成し、元のフォレストと分離されるフォレスト間のコラボレーションを可能にできます。
• 基礎展開 : IT 部門本部に相談なく、組織内の部門が独自のフォレストを展開する場合、次の項目を検討してください。

• 中心となるフォレストがまだ IT 部門によって展開されていない場合は、Active Directory のデザイン要件を満たすフォレストを提供するという条件で、組織全体の主要フォレストとして既存のフォレストを使用します。
• IT フォレストがすでに存在している場合は、IT フォレストと基礎フォレストを、1 つの中心となる IT フォレストにマージします。
• IT フォレストがすでに存在している場合は、複数フォレストの展開を実装します。

コラボレーションのレベル

コラボレーション機能は、どのレベルでフォレスト間で有効になる必要があるかを決定します。結果的には、複数フォレストの展開に関連する新たなコストの部分を決定することになります。フォレスト間で機能を有効にするコストを評価する最初の手順は、ビジネスが必要としているコラボレーション機能を評価することです。次の事例を使用して、必要なコラボレーションに基づいて、有効にする機能を決定します。

事例 1 : アドレス一覧情報のみを共有する組織

運用上および組織上独立性を必要とする組織の場合は、コラボレーションの必要性はほとんどありません。たとえば、競合企業のビジネスを管理している銀行の親会社を考えます。ビジネス上の競合により、単一フォレストに統合したり、メッセージング システムを変更したり、リソースを共有したりすることはありません。ただし、このような銀行の従業員は、企業の他部門の個人の電話番号、オフィスの場所、人事管理情報を調べたり、電子メールで連絡を取る必要があります。

このような組織には、次のような運用上の条件と要件があります。

• リソースは共有しません。
• フォレスト間ではユーザーを認証しません。
• Exchange Server 組織を独立させますが、必要に応じて、フォレスト間でアドレス一覧を表示できるようにします。

この事例では、異なるフォレストのユーザーのアドレス情報を表示できることが、唯一の必要条件です。この事例に唯一必要な構成は、Exchange のアドレス一覧をフォレスト間で同期できるようにすることです。この追加機能にかかるコストは、Microsoft® Identity Integration Server 2003 のような、ディレクトリ データを同期する製品を展開し、運用するコストです。統合されたアドレス一覧の同期のソリューションは、アドレス一覧の同期を実装するために、Identity Integration Server 2003 と連係して機能します。

アドレス一覧の同期の実装に関する詳細については、この資料の後半の「フォレスト間での Exchange データの同期」を参照してください。

事例 2 : スケジュール情報を共有する組織

この事例では、アドレス一覧情報の表示に加えて、独立したフォレストのユーザーが、他の人と会議を設定する必要があり、他の Exchange のパブリック フォルダを使ったワークフロー アプリケーションを使用します。この種のコラボレーションを必要とする組織の例は、互いに競合する複数の企業 (たとえば、製薬会社) を持つ親会社です。この理由のため、この企業は、独立したフォレスト、メッセージング システム、フォレスト外からのリソースのアクセスの阻止などを必要としています。しかし、同時に、共同調査プロジェクトを実施する必要があります。この共同調査プロジェクトには、仮想チームで一緒に作業をする異なる組織の専門家がかかわっています。これらの専門家が、互いに会議や電話会議を設定できるようにするために、パブリック フォルダを同期させることを組織は決定します。パブリック フォルダには、予定表の空き時間情報が格納されるシステム フォルダを含んでいます。

独立した Exchange の組織を持つビジネスの場合、このレベルのコラボレーションには次のような必要条件があります。

• リソースは共有しません。
• フォレスト間ではユーザーを認証しません。
• 事例 1 で説明したように、アドレス一覧を同期します。
• 予定表の空き時間情報を同期します (パブリック フォルダの同期)。

予定表の空き時間の同期には、フォレスト間での Exchange パブリック フォルダの同期を含みます。会議を設定するために必要な空き時間情報は、Active Directory ではなく、Exchange サーバーのパブリック フォルダのみに格納されています。この機能を可能にするソリューションは、パブリック フォルダの同期ツールを使用して、フォレスト間で Exchangeパブリック フォルダの内容を同期することです。

パブリック フォルダの同期に関する詳細については、この資料の後半の「フォレスト間での Exchange データの同期」を参照してください。

事例 3 : リソースを共有する組織

この事例では、組織は他のフォレストのユーザー グループに、1 つのフォレストのリソースへのアクセス許可を割り当ることができる必要があります。さらに、ユーザーは、グローバル アドレス一覧を使用して、組織全体の他のユーザーを調べることができる必要があります。また、予定表の空き時間の表示も可能で、異なるフォレストに存在する人と会議を設定できる必要があります。

この事例は、次のような場合に通常使われます。

1. 2 つの組織が合併し、管理者がディレクトリまたはメッセージング インフラストラクチャ、あるいはその両方を統合することを決定した場合です。ディレクトリやメッセージング インフラストラクチャの統合には時間がかかります。単一フォレストでのメッセージング環境をシミュレートするために、両フォレストの全ユーザーに対して、アドレス一覧を表示でき、予定表の空き時間を利用でき、フォレスト外部からリソースにアクセスできるシングル サインオンに関する作業が IT 部門に発生します。
2. 2 つの組織は合併しますが、一方の組織のドメイン コントローラは、もう一方の組織のドメイン コントローラに比べよりも、セキュリティ レベルの劣る場所にあります。セキュリティ レベルの劣る組織の IT 部門は、もう一方の組織のドメイン コントローラの物理的なセキュリティ レベルを受け入れられません。この理由のため、管理者はディレクトリとメッセージング インフラストラクチャを統合しないことを決定しました。同時に、それらの 2 つの組織のビジネスは、密接にコラボレーションを行う必要があります。フォレスト外部のリソース にアクセスするためのシングル サインオンを必要とするコラボレーションや、単一フォレストで利用できるものと同等のメッセージング環境を必要とします。
3. 企業は、主要な実稼動フォレストを展開する前に、新しい構成、運用、アプリケーションの動作を検証するために、試験的なフォレストを展開します。全ユーザー アカウント従業員はフォレスト間で平等に信頼され、両フォレストでさまざまなリソースにアクセスする必要があります。したがって、ユーザー アカウントがどちらのフォレストに存在するかにかかわらず、ユーザーは同じリソースにアクセスできる必要があります。単一のメッセージング システムの展開は、ユーザー アカウントがフォレスト間で平等に信頼されている環境では実現可能です。この組織は、Exchange サーバーを各フォレストに展開して、完全に主要な実稼動フォレストの環境を評価することを選択しました。このようにすると、新しい構成、運用、アプリケーションが主要な実稼動フォレストに展開される前に、メッセージングの問題点を認識できます。

このレベルのコラボレーションには、次のものを含みます。

• ブリッジされた DNS インフラストラクチャ。
• 独立した Exchange の組織。ただし、通常はグローバル アドレス一覧を表示できます。
• 独立したフォレスト内の Exchange 組織間で予定表の空き時間を同期します。
• 両方のフォレストにまたがるユーザー間でリソースを共有します。

• 制御された細かい共有または完全な共有を行います。
• セキュリティ グループは、両フォレストのメンバを含むことができます。
• アクセス制御リスト (ACL) は、セキュリティの担当者を両方のフォレストから一覧表示できます。

• フォレスト間でのシングル サインオン : リソースにアクセスするためのユーザー ログオンの方法は、どのフォレストでも同じです。

この事例のソリューションは、異なるフォレストにサーバーを配置する DNS の構成変更が必要になります。リソースにアクセスできるようにするには、リソースを共有するための適正なグループとアクセス許可だけでなく、異なるフォレストのドメイン間での信頼関係が必要になります。Windows Server 2003 のフォレストの機能レベルの場合は、各フォレスト内のすべてのドメイン間に双方向の推移的な信頼関係を有効にする、フォレストの信頼関係を利用できます。Windows Server 2003 以外の機能レベルを持つ、Windows 2000 のフォレストまたは Windows Server 2003 のフォレストの場合は、リソースを共有できるようにするために、特定のドメイン間での明示的な信頼関係を手動で作成する必要があります。

 注
異なるフォレストでの Windows 2000 ドメイン間の外部の信頼関係は、セキュリティ識別子 (SID) のフィルタを既定値のオフにして作成されます。外部の信頼関係を実装する場合は、サポート技術情報の文書 289243、「Windows 2000 における偽造された SID による特権の昇格」を参照してください。この資料を検索するには、Web Resources ページ  の「Microsoft Knowledge Base」(英語) を参照してください。

DNS のブリッジの詳細については、この資料の後半の「異なるフォレスト間で DNS 名前解決を可能にする」を参照してください。フォレスト間でのリソース共有とシングル サインオンを可能にする方法の詳細については、この資料の後半の「フォレスト間でのリソース アクセスを可能にする」を参照してください。アドレス一覧の同期に関する詳細については、この資料の後半の「フォレスト間での Exchange データの同期」を参照してください。

事例 4 : 1 つの Exchange 組織に完全に統合され、共有される組織

管理者は、メッセージング ソリューションを提供するコストを削減するために、単一の Exchange 2000 の組織を企業全体にサービスを提供するように展開することを検討するかもしれません。単一の Exchange Server 組織は、追加構成なしで、複数フォレストに移行できるので、このソリューションにより、より密接な統合が実現します。

より密接に統合している複数フォレストの組織の例としては、組み立てラインを停止して、組織に損失を与えることはできない無停止組み立てラインを持っている工場があります。組み立てラインの機能は Active Directory 統合アプリケーションに依存しているので、IT チームは、組み立てラインの重要な役割を考慮し、外部に依存しない独立した組み立てラインのフォレストを展開します。このフォレストは、ネットワークの接続状況に依存しません。IT 部門が障害の対応に必要な時間を考慮すると、企業のフォレストに提供されるサービスのレベルは受け入れられないでしょう。

一部のユーザーが、組み立てラインのフォレストのアカウントを持っています。これらのユーザーは定期的に社内を移動して、組み立てラインのフォレストに参加するラップトップを使用します。彼らは、企業のフォレストに配置したプリンタを使用するために、企業のフォレスト内の分散ファイルシステム (DFS) サーバー上のファイル共有にアクセスする必要があります。事例 3 で説明した DNS 統合やリソース共有に加えて、これらのユーザーの必要性に対応するために、次の機能が構成されます。

• サイトとサブネットの同期。
• プリンタ情報。

サイトとサブネットの詳細については、この資料の後半の「サイトとサブネットの同期」を参照してください。フォレスト間で利用可能なプリンタ情報の作成の詳細については、この資料の後半の「フォレスト間でのプリンタの設置」を参照してください。

ページのトップへ

複数フォレスト展開の追加コスト

複数フォレストを展開する際に最も考慮すべき点は、追加チームの提供、複数展開のためのトレーニング、追加の構成などの新たなコストがかかることです。単一フォレストに比べて、複数フォレストを展開する際には、以下のような新たなコストがかかります。

• 設計 : 異なるチームが、個別にフォレストを設計する必要があり、新たな IT 専門家をトレーニングするコストや、設計プロセス自体に費やされた時間に関するコストが必要になります。
• 実装 : 異なるチームが、個別にフォレストを展開、監視、運用する必要があり、新たな IT 専門家をトレーニングするコストや、それらの活動に費やされた時間に関するコストが必要になります。
• フォレスト間のコラボレーション : 単一フォレストの展開では必要のなかった、追加機能の構成や監視に関するコラボレーションの追加コストは、下記のとおりです。

• フォレスト管理者とドメイン管理者との間のコラボレーション。
• 新たなソフトウェアとハードウェア。

• 新たな構成に必要なトレーニング。
• 複数フォレストにまたがって単一フォレストの機能を実装するのに必要な特定の機能の実際の構成。

複数フォレストの展開が必須ではなく、オプションである場合は、展開前に追加コストを考慮した上で、サービスの自立性、サービスの分離性、データの分離性のメリットがあるかどうかを再考する必要があります。

ページのトップへ

フォレスト間での機能の追加構成

複数フォレストの展開の際にユーザーと管理者によって行われる操作の大部分は、1 つのフォレスト内での機能に依存しています。ただし、一部の操作は、フォレストの境界にまたがって機能を拡張する新たな構成を必要とします。

共同で複数フォレストを操作する際のコラボレーションの管理に加えて、以下の機能は、フォレスト間のコラボレーションを可能にするために新たな構成を必要とします。

• DNS 名前解決 : ドメイン コントローラとリソース ロケーションの機能を提供するために、フォレスト間の DNS 名前解決を有効にします。
• リソースへのアクセス。

• ユーザー ドメインとリソース ドメイン間の信頼関係を確立します。
• 異なるフォレストのアクセスを適正なグループに許可するように、リソースのアクセス制御リスト (ACL) を構成し、フォレスト間でのフォレストの役割を調整するために新しいグループを作成します。

• サイトとサブネットの同期 : 各フォレストが、ネットワーク全体のスコープを認識できるようにします。たとえば、あるクライアントに、他のフォレストであっても最も近いドメイン コントローラにアクセスすることを許可し、最小のネットワーク トラフィックで DFS ファイル共有へのアクセスを可能にするために、同じサイトとサブネットを全フォレストで構成します。
• アプリケーションデータの保存と取得 : 全フォレストのコンピュータが、どのフォレストのアプリケーション データにもアクセスできるようにします。
• プリンタの設置 : プリンタ情報を同期します。
• Exchange Server 統合 : アドレス一覧や予定表の空き時間の同期を可能にします。

ここは、高度な各構成の本質を説明しますが、特定の構成の指示は提供しません。マイクロソフトは、ここで説明した機能を可能にする方法を説明する展開ガイドを発行する予定です。

異なるフォレスト間で DNS 名前解決を可能にする

Active Directory の展開を正常に行うには、名前を解決するための DNS が必要になります。ユーザーとコンピュータによるドメイン コントローラやリソースの配置には、コンピュータの DNS 名から IP アドレスを解決できる必要があります。

問題点

複数フォレストでは、1 つのフォレスト内のユーザーとコンピュータが、他のフォレスト内のリソースとドメイン コントローラを認識できるように、名前解決がフォレスト間で機能する必要があります。

DNS 名前空間の設計と単一の Active Directory フォレストの展開の DNS サポートの提供については、「Best Practice Active Directory Design for Managing Windows Networks」(英語) を参照してください。このドキュメントは、Microsoft TechNet Web サイト(https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/bpaddsgn.mspx) で参照できます。複数の Active Directory 展開を設計するプロセスでは、個別のフォレストごとに以下の推奨事項に従ってください。個別の Active Directory フォレストごとに DNS の設計を完了した後、フォレスト間での名前解決を可能にするための、必要条件を分析する必要があります。

異なるフォレストの名前空間から名前を解決するには、以下の必要性を考慮します。

ユーザーとコンピュータは、異なるフォレストに参加するリソースの名前を解決する必要があります (たとえば、Exchange サーバー、ファイル共有、またはサービス)。

ユーザーとコンピュータは、そのフォレスト内のリソースを認証する目的で、異なるフォレストのドメイン コントローラの名前を解決する必要があります。

ほとんどの事例では、異なるフォレスト間での名前解決を保証する必要があります。

解決策

フォレスト間での名前解決を可能にするための新たな DNS 構成の必要性は、現在の DNS インフラストラクチャと、新しい Active Directory フォレストのために計画された DNS 設計に依存します。最も一般的な DNS 事例を以下に説明します。関係する構成必要条件もそれぞれに列挙します。

組織 B の DNS サーバーが、組織 A の名前空間内の名前のクエリに応答できるようにするには、名前空間でより上位の階層のゾーンをホストする DNS サーバーが、組織 A サーバーの上位の階層のゾーン データを含む、セカンダリ ゾーンをホストするように構成します。

• 図 1 で、組織 A は、ルート (“.”) ゾーンをホストするルート DNS サーバーを持っています。この事例では、組織 A のルート ゾーンをホストするルート DNS サーバーに委任が設定されています。この委任は、DNS サーバーのホスト (A) のリソース レコードとネーム サーバー (NS) リソース レコードから構成され、DNS サーバーは、組織 B の最も上位のレベルの DNS ドメインをホストします。これらのリソース レコードの効果は、組織 B の名前空間内の名前で、組織 A が発行したクエリが、組織 B のDNS サーバーを参照することです。図 1 では、組織 A から 組織 B への委任を示しています。

  

  図 1:組織 B で名前解決を可能にするための、組織 A のルートゾーンをホストする DNS サーバーからの委任

• 図 2 では、組織 A にはルート ゾーンがありませんが、Windows Server 2003 オペレーティング システムのメンバを実行する DNS サーバーが、クエリを名前空間へ、最終的にはインターネットへ転送するように構成されています。この事例では、特定のサフィックス (この場合は、サフィックス B.com) で終了するクエリを転送するために、条件付き転送が、組織 A の DNS サーバーで構成される必要があります。組織 A の DNS サーバーは、組織 B の名前空間のすべてのレベルに転送されます。図 2 は、組織 A から 組織 B への条件付き転送を示します。

  

  図 2: 組織 A から組織 B への条件付き転送

   注
  条件付き転送は Windows Server 2003 でのみ使用できます。

• 図 3 では、組織 B にはルート ゾーンがなく、組織 B の DNS サーバーは、Windows 2000 Server ファミリのメンバを実行しています。組織 B の DNS サーバーが、組織 A の名前空間内の名前のクエリに応答できるようにするには、名前空間の上位の階層のゾーンをホストする DNS サーバーが、組織 A サーバーの上位レベル ゾーン データを含む、セカンダリ ゾーンをホストするように構成します。図 3 で示すように、これらのセカンダリ ゾーンをホストする組織 B サーバーは、組織 A の名前のセカンダリ ゾーンが確実に更新されるように、組織 A DNS サーバーからゾーン転送を実行する必要があります。

  

  図 3: 組織 B 内の組織 A のためのセカンダリゾーン

フォレスト間でのリソース アクセスを可能にする

異なるフォレストのリソースへのアクセスは、適切な信頼関係、ユーザーとグループの管理、信頼しているドメインのアクセス制御を必要とします。ドメイン間でのリソースの共有は、"Microsoft® Windows® 2000 Server リソース キット" に同梱されている『展開計画ガイド』の「Active Directory 構造の設計」で説明されています。リソース アクセスと、複数の Windows Server 2003 フォレストの管理のモデルは大変似ていますが、いくつか基本的な違いがあります。

問題点

フォレスト A のユーザーが、フォレスト B のリソースにアクセスする必要がある場合、フォレスト B のリソース管理者は、リソースのアクセス制御リスト (ACL) に、フォレスト A のユーザー アカウントを追加する必要があります。リソースへの同等なアクセスが必要なユーザーが数多くいると仮定して、必要とされる全リソースに対して、全ユーザーの個別のアカウントを ACL に追加することは、現実的ではありません。よりスケーラブルな管理モデルでは、フォレスト A のユーザーに、フォレスト B のリソースへのアクセスを許可する必要があります。

解決策

ユーザーがフォレストを超えたリソースに対するアクセスを許可する環境では、ユーザーがフォレスト内の異なるドメインのリソースへアクセスすることを許可する環境に似ています。最も効果的な管理モデルは、下記のとおりです。

以下のように、異なるフォレストのドメイン間での信頼関係を作成します。

• 2 つの Windows Server 2003 のフォレストで、全ドメイン間でリソース共有を可能にするには、フォレストのルート ドメイン間でフォレストの信頼関係を作成します。この信頼関係は、Windows Server 2003 のフォレストで効果的です。2 つのフォレストの全ドメイン間での、双方向の推移的な信頼関係を有効にします。この場合のフォレストの信頼関係は、2 つのフォレストを超えることはありません。

 注 :
推移的な信頼関係は、ドメイン ツリーなどのドメインのセットを経由して流れ、ドメインとそのドメインを信頼する全ドメインとの信頼関係を形成します。たとえば、ドメイン A がドメイン B と推移的な信頼関係を持っていて、ドメイン B がドメイン C を信頼している場合、ドメイン A はドメイン Cを信頼します。推移的な信頼関係は、単一方向にも双方向にもなり得ます。Kerberos ベースの認証と Active Directory のレプリケーションが必要になります。

異なるフォレストでの特定のドメイン間でのリソースの共有を可能にするには、特定のドメイン間で外部一方向で非推移的なドメインの信頼関係 (明示的な信頼) を作成します。

同じ種類のリソースにアクセスする必要があるユーザーのセットを表すには、役割ベースのグローバル グループを全ドメインおよびこれらのユーザーを含むフォレストに作成します。

 注
一部のフォレストには、そのようなグループが既に作成されている場合があります。

グローバル グループに対応するユニバーサル グループを作成します。

複数フォレストで関連するリソースへのアクセス許可を割り当てることができるように、複数のグローバル グループをユニバーサル グループに追加します。

 注
ユニバーサル グループは、Windows 2000 混在モード ドメイン、または Windows 2000 混在ドメインの機能レベルを持つ Windows Server 2003 ドメインのセキュリティ グループとしては使用できません。それらは配布グループで利用可能です。Active Directory の機能レベルの情報については、Windows Server 2003 ヘルプとサポート センターを参照してください。

フォレスト外部からアクセスされる必要があるドメイン内のリソースに対して、全ドメインでリソース ベースのドメインのローカル グループを作成します。

ユニバーサル グループ (または混在モード ドメインのグローバル グループ) を、各フォレストから組織にまたがるドメイン ローカル グループに追加し、そのドメイン ローカル グループを使用して、それぞれのドメイン内のリソースへのアクセス許可を割り当てます。

新規ユーザー アカウントが異なるフォレスト内のリソースにアクセスする必要がある場合、それぞれのグローバル グループにアカウントを追加します。新規リソースがフォレスト間で共有される必要がある場合は、適切なドメイン ローカル グループをそのリソースの ACL に追加します。この方法で、グループのメンバシップに基づいてリソースにアクセスできるようになります。

図 4 と 5 は、単一フォレストと複数フォレスト、また Windows 2000 と Windows Server 2003 のこのモデルを比較しています。図 4 では、フォレスト A は、混在モードの Windows 2000 ドメインを持っています。そのため、ユニバーサル グループは使用できません。ドメイン A とドメイン C からのグローバル グループは、ドメイン B のドメイン ローカル グループに追加されています。また、そのグループは、ドメイン B リソースの ACL にも追加され、適切なレベルのアクセスを提供するグループにアクセス許可が割り当てられました。複数フォレストの展開では、単一フォレストの展開で 3 つのドメインに使用されるているのと同じ、3 つのフォレストのモデルに従います。

図 4 の事例は、利用可能なユニバーサル グループを持たないドメインに適用されます。ユニバーサル グループを使用できないドメインは、以下のようなドメインです。

• 混在ドメイン モードの Windows 2000 ドメイン。
• 混在した Windows 2000 ドメインの機能レベルの Windows Server 2003 ドメイン。

図 4 の、グループの略称は以下のとおりです。

• グローバル グループ (GG) 。
• ドメイン ローカル グループ (DLG) 。

図 4: ユニバーサルグループが使用できない場合のリソース共有

図 5 では、複数のグローバル グループが、ドメイン ローカル グループに追加された 1 つのユニバーサル グループに追加されています。単一フォレストでは、役割ごとに 1 つのユニバーサル グループのみが必要とされます。複数フォレストではユニバーサル グループは、異なるフォレストのリソースにアクセスする必要があるユーザーを持つフォレストごとに作成されます。同じフォレストの複数のグローバル グループが、同じローカル リソースにアクセスする必要があるときに、このアプローチが役に立ちます。

しかし、コンピュータ ローカル グループはセキュリティ トークンには追加されません。ユニバーサル グループを使用できるドメインは、以下のドメインです。

• ネイティブ ドメイン モードのWindows 2000 のドメイン。
• Windows 2000 ネイティブまたは Windows Server 2003 のドメインの機能レベルの Windows Server 2003 ドメイン。

図 5 の、グループの略称は以下のとおりです。

• グローバル グループ (GG) 。
• ドメイン ローカル グループ (DLG) 。
• ユニバーサル グループ (UG) 。

図 5: ユニバーサルグループが使用できる場合のリソース共有

ドメイン ローカル グループへのグループの追加とコンピュータ ローカル グループへのグループの追加

一般的な規則としては、グローバル グループへのドメイン ローカル グループの追加や、ユニバーサル グループへのグローバル グループの追加は、多くのユーザーに複数のリソースへのアクセスを許可する必要がある場合に効果的です。ユーザーが少数の場合は、ユニバーサル グループまたはリソースに直接追加できます。

さらに、ユニバーサル グループまたはグローバル グループをドメイン ローカル グループまたはコンピュータ ローカル グループに追加する選択肢がある場合は、ドメイン ローカル グループではなく、コンピュータ ローカル グループを使用します。それは、アクセス トークンが構築されている場合、セキュリティ プリンシパルがメンバである、ドメイン ローカル グループ、グローバル グループ、ユニバーサル グループが、トークンに含まれているためです。このように、トークンのエントリは、入れ子になったグループのメンバシップを含み、ユーザー A がグループ G のメンバで、グループ G がグループ GR のメンバであれば、ユーザー A のアクセス トークンは、グループ G とグループ GR の両方を含むことを意味します。最大 1,500 のエントリをトークンに追加できます。ユーザーが多すぎるグループに属している場合は、この制限を超える可能性があります。しかし、コンピュータ ローカル グループは入れ子になっていません。

したがって、リソース アクセスがコンピュータごとに有効で、コンピュータのメンバが多くない場合、コンピュータ ローカル グループの使用は、ドメイン ローカル グループのメンバが入れ子になる可能性が回避される、適切な選択肢です。

たとえば、ユーザーに Exchange サーバーを管理する権限を許可する場合、ドメイン ローカル グループを作成したり、そのドメイン ローカル グループを Exchange 管理者グループまたは Exchange サーバーのオブジェクトやアクセス許可設定の ACL に追加したり、ユーザーのアカウントまたはグループをドメイン ローカル グループに追加するよりも、アカウントやグループを Exchange サーバーのコンピュータ ローカル グループに追加することのほうがより効果的です。

フォレスト間でのリソース アクセスのセキュリティについての考慮点

データの分離性、サービスの分離性、またはその両方のために複数フォレストを作成する場合でも、他のフォレスト (または、他のフォレスト内の個別のドメイン) との信頼関係を作成できます。他のフォレストでユーザーをグループに追加し、ユーザーがリソースへのアクセスを許可されるように設定できます。ただし、以下のグループには、他のフォレストのユーザーを追加しないでください。

• サービス管理を担当するグループ、またはサービス管理グループのメンバシップを管理するグループ。
• 保護されたデータを格納しているコンピュータに管理制御権を持つグループ。
• 保護されたデータにアクセス権を持つグループ、保護されたデータにアクセス権を持つ、ユーザーやグループ オブジェクトの管理を担当するグループ。

これらのグループに他のフォレストのユーザーを含めると、他のフォレストでセキュリティ違反が発生し、保護されたデータが開示されたり、サービスの割り込みが発生する可能性があります。

これらの管理グループの情報については、「Design Considerations for Delegation of Administration in Active Directory」(英語) を参照してください。このドキュメントは、Microsoft TechNet Web サイト (https://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/plan/addeladm.mspx) で参照できます。

サイトとサブネットの同期

サイトとサブネットの情報は、ネットワークの物理的なトポロジを表し、Active Directory の構造とは関係しません。Active Directory は、それぞれの IP アドレスと Active Directory のサブネット オブジェクトによって決定されるアドレスの範囲の関係によって、ネットワーク上のコンピュータの場所を判断できます。サブネットはサイトに関連付けられ、サイトは適切なネットワーク接続の領域を識別します。サイトは、通常、広域ネットワーク (WAN) のリンクに接続します。このため、理想的な接続は、サイトの境界をまたがらない接続です (トラフィックは WAN のリンクを横断しません)。サイトとサブネットの情報は、Windows 2000、Microsoft® Windows® XP、または Windows Server 2003 オペレーティング システムのメンバを実行しているコンピュータに、同じサイトまたは近いサイトに以下のコンピュータとサービスを配置することを可能にします。

• ドメイン コントローラ、グローバル カタログ サーバー、キー配布センター (KDC)。
• 要求済みリソースをホストする分散ファイル システム (DFS) サーバー。

問題点

両方のフォレスト内のサイトとサブネット情報が識別可能な場合、コンピュータの場所とサービスの場所はサイトによって最適化されます。同じサイトまたは近いサイトにコンピュータやサービスを配置できるかどうかは、適切なサイトとサブネット情報が Active Directory で利用できるかどうかにある程度依存します。

サイトとサブネット情報の同期を確立することは、複数フォレスト展開の必須項目ではありません。複数フォレスト環境が存在している期間内であればどの時点でも、サイトとサブネットの同期を確立できます。確立しないという判断も可能です。サイトとサブネット情報の同期を確立することを決定した場合、どのくらい早く確立できるのかは、フォレスト間で同一サイト トポロジを持たないことによる影響の度合に依存します。

たとえば、組織にフォレスト A と フォレスト B があり、サイトとサブネット情報が両フォレスト間で同期されていないと仮定します。以下の事例は、サイトの認識度に影響される、フォレスト間の運用のパフォーマンスでの 3 つ一般的な影響を説明しています。

• ログオン プロセス
• ファイルのダウンロード
• 認証

これらの事例を使用して、ネットワーク トラフィックまたは要求の実行時間、またはその両方が軽減されるかどうかを判断し、フォレスト間でのサイトとサブネット情報の同期が必要かどうかを検討してください。

フォレスト間でのログオンのプロセス

フォレスト A のユーザーがフォレスト B のコンピュータにログオンする場合、ログオン プロセスは、フォレスト A のユーザーのドメインのドメイン コントローラの場所を必要とします。フォレスト B のコンピュータのサイトが フォレスト A の Active Directory で指定されていない場合、コンピュータは、フォレスト A のユーザーのドメインの (最も近いものでなく) すべてのドメイン コントローラを検索します。

WAN によってドメイン コントローラが接続されている場合、このログオン プロセスは、WAN のトラフィックに影響します (トラフィックの量は、移動プロファイルのサイズと同様に、グループ ポリシーやログオン スクリプトに依存します)。この接続により、ログオンしている間だけでなく、ログオフでもトラフィックが生成されます。通常、100 キロバイト (KB) から、数百 KB です。ログオン トラフィックで利用可能な WAN の帯域幅によっては、WAN 上でのログオンの実行時間が増加します。この欠点が受け入れ可能であれば、特に、大部分のユーザーが独自のフォレストのコンピュータにログオンすることを予想していれば、フォレスト間でデータを同期する保証をすることほど、サイトとサブネット情報は重要ではありません。

フォレスト間でのファイルのダウンロード

フォレスト B に参加したコンピュータにログオンしたユーザーが、複数の DFS サーバーにホストされているファイルを要求したとき、フォレスト A のサイトとサブネット情報がフォレスト B で利用可能な場合、フォレスト A に参加する最も近いサーバーがダウンロードのためにアクセスされる DFS サーバーになり得ることができます。DFS サーバーのサイトがフォレスト B で指定されていない場合は、任意の (リモート サイトの) DFS サーバーからファイルがダウンロードされることがあります。DFS サーバーのサイトがフォレスト B で利用可能な場合、フォレスト A のサーバーが検索されます。

 注
Windows Server 2003 の DFS の機能強化は、フォレスト B に参加していて、目的のファイルをホストする次に近い DFS サーバーからファイルがダウンロードされます。

リモート DFS サーバーからファイルをダウンロードすると、WAN 上のネットワーク トラフィックが増加します (トラフィックの量は、ダウンロードするファイルのサイズによって異なります)。潜在的にダウンロード時間は増加します (遅延はファイルをダウンロードするのに利用可能な帯域幅に依存します)。この問題が重要視されていない場合、特に、ユーザーが DFS サーバーからのみファイルをダウンロードすることがあらかじめ予想されている場合、サイトとサブネット情報の同期は重要ではありません。

フォレスト間での認証

ユーザーが、異なるフォレストでリソースを認証する必要があるとき、ユーザーのコンピュータまたはドメイン コントローラ (使用している認証メカニズムに依存します) は、リソースが所属するドメインのドメイン コントローラにアクセスする必要があります。ドメイン コントローラの場所は、同一のサイトとサブネット情報が両方のフォレストで構成されているときのみ、フォレスト間で最も近いサイトに最適化されます。ただし、ユーザーの認証によって生成されるトラフィックによって、著しい遅延を生じさせることはないため、ローカルドメイン コントローラにアクセスされるかどうかは、重要ではありません。

解決策

サイトのミラーリングとサブネット情報の最初の解決策は、同じサイト オブジェクトとサブネット オブジェクトを全フォレストに作成することです。それらのオブジェクトを作成した後で、両方のフォレストで同等にサイトとサブネット情報が確実に管理されるようにするために、2 つの方法を使用できます。

• ディレクトリ データ同期製品 (たとえば、Microsoft Identity Integration Server 2003) を使用して、サイトとサブネット情報が 1 つのフォレストで変更されたときに、データの同期を行います。このアプローチは、高度な自動化が特徴であり、Microsoft Identity Integration Server 2003 の構成情報が配置された後は、実質的に管理者を必要としません。ただし、このアプローチは、サービスの分離が必要な事例では受け入れられません (同期先フォレストのサービス管理者は、同期元フォレストのサービス管理者を信頼しません)。
• サイトとサブネット情報が変更されたときに、各フォレストでネットワーク管理者がサービス管理者に知らせ、サービス管理者がそれぞれのフォレストで情報を更新するというビジネス プロセスを確立します。このアプローチは、独立したフォレストにサービスの分離性が必要なユーザーにとって最も効果的です。ただし、このアプローチは、複数フォレストでミラー化された情報を作成するために、高度な管理者オーバーヘッドを必要とします。

マイクロソフトは、ネットワーク トポロジの情報をミラー化するための同期に必要な、サイト オブジェクトとサブネット オブジェクト、およびその属性を説明する展開ガイドを発行する予定です。

フォレスト間でのアプリケーション データの取得

Active Directory にアプリケーション固有のデータ ( 構成情報など) を格納または取得するアプリケーション ファミリが急速に増えています。アプリケーション アーキテクチャは、Active Directoryにアプリケーション固有のデータが格納されると仮定します。データは サービス プロバイダや管理者によって Active Directory の場所に設定されます。

問題点

サービスやクライアントアプリケーションが、データを取得したり、サービスを検索する必要があるとき、Active Directory に対して検索を実行し、データを取得します。通常、多くのクライアントは、サービス プロバイダと同じフォレストに参加していますが、複数フォレストでは、この条件に常に当てはまるわけではありません。

たとえば、サービス App1 のサービス プロバイダは、フォレスト A に参加したコンピュータ上で動作しており、クライアントがフォレスト A のみでそれらのサービス プロバイダを検索できるようにする情報を登録します。この場合、フォレスト B のクライアントが、サービス App1 のサービス プロバイダを発見するために Active Directory に照会すると、そのクエリが失敗し、クライアントはサービス プロバイダを検索できません。

クライアントは、サービス プロバイダを検索するために、Active Directory に格納されたデータを常に使用するわけではありません。クライアントや他のサービス プロバイダは、Active Directory からデータを取得する必要がある場合もありますが、他のどのサービス プロバイダも検索する必要はありません。以下の解決策は、両方の事例に適用されます。

解決策

クライアントが異なるフォレストの Active Directory の情報を検索できるようにするために、以下の 2つのアプローチを使用できます。

• 各フォレストにサービス プロバイダを展開します。
• フォレスト間でデータの同期を取ります。

どちらのアプローチを選択するかは、以下のアプリケーションの必要条件によって異なります。

• 負荷の共有。
• 最も近いサービス プロバイダの発見。
• 自律性または分離性、あるいはその両方 (セキュリティ上の理由による)。

新たなサービス プロバイダの展開

以下の事例は、さまざまなアプリケーションの必要条件に基づいて、新たなサービス プロバイダの展開を必要とする条件を説明します。

負荷の必要条件

1 つのフォレストに展開されているサービス プロバイダが、複数フォレストからのクライアント要求の負荷に耐えることができない場合、新たなサービス プロバイダの展開が必要になります。すべてのフォレストに個別のサービス プロバイダ展開することにより、フォレスト間でアプリケーション固有データを同期する必要がなくなります。

フォレスト間でのデータの同期

以下の事例は、さまざまなアプリケーションの必要条件に基づいて、複数フォレスト間でデータの同期が必要になる条件を説明します。

最も近いサービス プロバイダ

ネットワーク トラフィックが集中する、または応答時間に影響を受けやすいアプリケーションの場合、クライアントが最も近いサービス プロバイダを検索することが重要になります。この場合、複数サイトに及ぶネットワーク全体に対応するサービス プロバイダを展開することは適切ではありません。各サイトのフォレストごとに、少なくとも 1 つのサービス プロバイダを展開する必要があります。ただし、複数フォレストが重なり合うサイトに広がっている場合、フォレストごとにサービス プロバイダを重複させることは、ハードウェアやサービス プロバイダのサポートのコストを不必要に増加します。この場合、クライアントが異なるフォレストに属している場合でも、異なるフォレスト間でアプリケーション固有データの同期を取ることにより、あるフォレストのクライアントが一番近いサービス プロバイダを検索することを可能にします。フォレストの認証の情報に関係なく、同じサイト内の全クライアントによって使用可能なサービス プロバイダの例は、この資料の後半の「フォレスト間でのプリンタの設置」を参照してください。

フォレスト間でアプリケーション データを共有しない

以下の場合は、フォレスト間でのアプリケーション データの提供は現実的ではありません。

自律性または分離性

一部のアプリケーションでは、サービスの可用性やサービス プロバイダの近接性以外に、管理者が自立性に関する新たな必要条件を持つ場合があります。たとえば、(独自のフォレストを所有している) 1 つの事業部のアプリケーションまたはサービスの所有者は、(組織の他の部分とは構成が一致しない) 特別な構成のサービス プロバイダを必要とします。このフォレストのユーザーは、他のフォレストのサービス プロバイダを使用しません。このユーザーは同じフォレスト内のサービス プロバイダのみに依存する必要があります。この場合、フォレスト間でアプリケーション固有データを同期する理由はありません。

自律性と分離性の必要条件以外にも、セキュリティ上の理由から、サービスの所有者は、そのユーザーとコンピュータが独自のフォレストのサービス プロバイダのみ使用することを要求する場合があります。異なるフォレストのサービス管理者は、フォレストに参加しているコンピュータに格納されているサービスとデータについてフル コントロール権限を持っていることを覚えておいてください。サービスの提供が他のフォレストに依存することを許可できない場合 (たとえば、他のフォレストが侵害された場合) は、そのサービス固有のデータをユーザーのフォレストに同期してはいけません。

フォレスト間でアプリケーション固有データを同期するための、Microsoft Identity Integration Server 2003 の使用についての考慮点

一部のアプリケーション固有データを同期する決定をした場合、推奨する同期のソリューションは Microsoft Identity Integration Server 2003 です。このソリューションは、以下の管理連係を含みます。

• Microsoft Identity Integration Server 2003 の管理者は、Microsoft Identity Integration Server 2003 を、アプリケーション固有のデータを同期するように構成します。
• アプリケーションの所有者は、フォレスト間で同期する必要のあるオブジェクトや属性の説明と共に、Microsoft Identity Integration Server 2003 管理者を提供します。
• フォレスト管理者は、Microsoft Identity Integration Server 2003 の管理者に、情報を読み取り、書き込むディレクトリの場所を示します。

アプリケーションの管理者とのコラボレーションでは、個別のフォレストの管理者は、データの同期に参加する場合は、各アプリケーションに相対的に決定する必要があります。この決定は、アプリケーション固有のデータを他のフォレストと共有する必要性、他のフォレストのアプリケーション固有のデータを使用する必要性、またセキュリティ要件に基づく必要があります。

アプリケーション データを書き込むための資格情報

Microsoft Identity Integration Server 2003 が特定のアプリケーションの固有データを書き込むことを許可する決定を行うときに、データを書き込むために、Microsoft Identity Integration Server 2003 がどの資格情報を使用する必要があるかを、フォレスト管理者が決定する必要があります。推奨している手法は、Microsoft Identity Integration Server 2003 にデータの書き込みを許可するために、その資格情報を専用に使用するユーザー アカウントを作成することです。管理者はアプリケーションごとに独立した資格情報を作成する必要はありません。また、別のアプリケーションによって使用されるデータと同じ資格情報を使用することもできます。

アプリケーション データの書き込みのためのセキュリティについての考慮点

フォレストの管理者は、Microsoft Identity Integration Server 2003 がデータを書き込むコンテナに、適切な書き込みアクセス許可を追加する必要があります。セキュリティの必要条件によって異なりますが、対象のフォレストの管理者は、これらの資格情報が、異なるフォレストのデータを上書きできないようにする必要があります。

Microsoft Identity Integration Server 2003 の管理者が同期サーバーを適切に構成することを信頼していても、また Microsoft Identity Integration Server 2003 管理者が悪意のある人物である可能性を完全に除去できる場合でも、まだ管理者が強要される可能性は存在します。Microsoft Identity Integration Server 2003 の管理者が、不意にフォレスト全体や特定の機能のデータを書き換えてしまう危険性を最小にするためには、同期されたオブジェクトが作成されるための組織単位の作成に加え、Microsoft Identity Integration Server 2003 に与えられるデータの作成、更新、削除が可能な書き込み許可が、この組織単位のみに制限されるようにする必要があります。

1 つの組織単位にアクセスを制限することにより、Microsoft Identity Integration Server 2003 が組織単位外のデータに上書きできる可能性がなくなります。このアプローチを取る場合、フォレスト管理者は、Microsoft Identity Integration Server 2003 の管理者に、フォレスト階層のこの組織単位の場所を通知する必要があります。また、条件を満たすディレクトリ上のさまざまなオブジェクトに読み取りや書き込みを行うために、あらゆるアプリケーションの必要条件を満たす必要があります。たとえば、一部のアプリケーションは、Active Directory 階層の特定の場所、およびその場所だけにデータがあることを期待しています。

 注
Microsoft Metadirectory Services Version 2.2 を使用している場合、Microsoft Metadirectory Services 2.2 を専門としている Microsoft Consulting Services (MCS) コンサルタントを雇い、データの同期を可能にするために Microsoft Metadirectory Services 2.2 を構成することをお勧めします。

フォレスト間でのプリンタの設置

Active Directory のプリンタ オブジェクトの存在は、そのフォレストにアカウントを持つコンピュータに、特定の特性を持つプリンタ (たとえば、カラー印刷やホッチキス留めをサポートするプリンタ) や、コンピュータの近くに配置されているプリンタの参照を可能にします。

問題点

複数フォレストの事例では、ユーザーは物理的にプリンタと同じ場所にあるコンピュータにログオンします。ただし、コンピュータのアカウントとプリンタの情報は異なるフォレストに存在しています。この場合、ユーザーはプリント サーバーとプリンタ名を指定することにより、異なるフォレストにプリンタを配置できます。フォレストのメンバシップにかかわらず、ユーザーが近くにあるプリンタを参照できるようにします。

解決策

プリンタ名を指定することにより、フォレスト管理者が追加の構成を必要としないで、特定のプリンタを使用するコンピュータを構成できます。ただし、1 つのフォレスト内のユーザーに、別のフォレストのプリンタを参照させる場合、この資料の「フォレスト間でのアプリケーション データの取得」で説明したように、Microsoft Identity Integration Server 2003 を使用して、フォレスト間でプリンタ データを同期することを検討してください。

マイクロソフトは、この機能をどのように可能するかの指示を記載した展開ガイドを発行する予定です。

フォレスト間での Exchange データの同期

Exchange 2000 Server は Active Directory を使用して、構成情報やユーザー情報を格納し、ユーザー認証やアクセス許可管理をユーザーに提供します。複数の Exchange 組織が展開される複数フォレストの展開では、複数フォレスト間での複数 Exchange 組織のメールなどに関連するデータを同期するために、新たな構成が必要になります。

Exchange 組織と Active Directory

"Exchange 組織" は、1 台以上の Exchange サーバーで構成され、各 Exchange 組織は、1 つの Active Directory フォレストに対応します。Exchange サーバーは、アドレス情報のグローバル カタログへのアクセスに依存します。各フォレストは独立したグローバル カタログを持っているので、Exchange 組織は 1 つのフォレストのみに関連付けられます。

ただし、複数フォレストは、メール サービスに同じ Exchange 組織を使用できます。Exchange 組織は、その構成情報の格納に1 つのフォレストだけを使用するので、複数フォレストに対応する 1 つの Exchange 組織は、新たに別フォレストでの展開は必要としません。

フォレスト間のユーザーでのメールの送信と受信に、異なるフォレストのユーザー アカウントは同じ Exchange 組織に使用できても、1 つの Exchange 組織のサーバーは 1 つの Active Directory フォレストにしかアクセスできません。それぞれのフォレストに独立した Exchange 組織を展開し、1 つのビジネス組織として機能させるには、それぞれの Active Directory の Exchange メール受信者を同期するために、新たな構成が必要になります。

異なるフォレスト(Exchange 組織)からアドレス情報にアクセスするには、関係する各ディレクトリでの同期により作成、管理される全メール受信者のプロキシ アドレス オブジェクトを必要とします。このプロキシ アドレス オブジェクトが所定の場所にあると、Exchange サーバーが 1 つのディレクトリをクエリするときに、シャドウ オブジェクトとして作成された情報だけでなく、そのフォレストの元のメール受信者の情報も表示できます。

1 つの Exchange 組織

1 つの Exchange 組織が複数のフォレストに対応するかどうかにかかわらず、Exchange 組織は依然として "Exchange フォレスト" と呼ばれるフォレストだけに関連付けられます。1 つのフォレストにアカウントを持つユーザーは、同じフォレストまたは異なるフォレストにメールボックスを持ちます。ただし、メールボックスのデータは Exchange サーバーに格納されているので、メールボックスは常に Exchange サーバーと同じフォレストに存在します。

たとえば、フォレスト A と フォレスト B が 1 つの Exchange 組織を共有する事例では、Exchange サーバーはフォレスト B のみにインストールされます。ユーザー A は、フォレスト A にユーザー アカウントを持っており、ユーザー A のメールボックスはフォレスト B に格納されています。フォレスト A のユーザーとフォレスト B にあるユーザーのメールボックスを関連付けるには、フォレスト B にユーザー A のために無効なユーザー アカウントが作成されます。ユーザー A のメールは、フォレスト B の Exchange サーバーに格納されており、無効なアカウントの属性はフォレスト A のユーザー A のアカウントに関連ズけられます。この種の Exchange 環境は、"リソース フォレスト モデル" と呼ばれます。

図 6 は、Exchange サーバー上にメールボックスを持つユーザー アカウントが、異なるフォレストに存在するExchange の組織を示しています。この事例では、フォレスト A のユーザー オブジェクトは、Exchange サーバーをホストするフォレスト B のそれぞれの Exchange メールボックスに関連付けられた無効なユーザー アカウントを持っています。

図 6: 異なるフォレストでユーザーとメールボックスを持つ 1 つの Exchange 組織

1 つの Exchange の組織は、図 7 で示すように、複数のフォレストを持つことができます。

図 7: 複数フォレストに対応する 1 つの Exchange 組織

複数の Exchange 組織

同じ企業が複数フォレストに Exchange サーバーを展開するとき、それぞれの Exchange 組織は独立した Exchange フォレストを持ちます。そのため、独立したグローバル カタログ、グローバル アドレス一覧を持ちます。各フォレストのユーザーが、他のフォレストのアドレス一覧情報を参照できるようにするには、新たな構成が必要になります。この要件を実現するには、複数の Exchange 組織でメールの受信者の情報の同期を取る必要があります。

図 8 は複数フォレストに Exchange サーバーを展開している複数フォレストの企業を示します。

図 8: 複数の Exchange 組織と複数フォレスト

 注
Exchange 2000 Server 向けに Active Directory の推奨事例を規定することはこの資料の目標ではありません。Windows 2000 Server 環境で Exchange 2000 Server の Active Directory を設計する情報については、「Best Practice Active Directory Design for Exchange 2000」(英語) を参照してください。このドキュメントは、Microsoft Web サイト (https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=F53662B9-4E69-40CE-AA19-7B0C48710403) からダウンロードできます。

複数の Exchange 組織が、同じ複数フォレストの企業の独立したフォレストに対応する展開については、以下のことを可能にするために、新たな構成が必要になります。

• 全フォレストでの、グローバル アドレス一覧の表示。
• 全フォレストでの、予定表の空き時間情報の表示。

この資料の構成情報は、複数のフォレストに Exchange サーバーが展開されているすべての事例を扱っていますが、企業のすべてのフォレスト内にこの構成情報が必要なわけではありません。

アドレス一覧の同期

1 つの Exchange 組織を持つ複数フォレストの環境では、グローバル アドレス一覧にアクセスするために、すべてのユーザー アカウントが Exchange フォレストのグローバル カタログ サーバーを参照します。ユーザーが異なるフォレストに存在しても、Exchange はこれらのユーザーに対して 1 つのグローバル アドレス一覧を使用するので、アドレス一覧情報の同期は必要ありません。

複数の Exchange 組織を持つ複数フォレストの環境では、それぞれの Exchange フォレストが独自のアドレス一覧を持っているので、フォレスト間でアドレス一覧のデータを同じように表示するためには、同期が必要になります。

グローバル アドレス一覧は、メールを受信できるフォレストのエンティティの一覧です。メールの受信者は、ユーザー アカウント (有効なアカウントと無効なアカウントの両方)、連絡先、配布グループ、セキュリティ グループです。Exchange 管理者は、メールの受信者情報のグローバル リストの異なる表示も作成して、アドレス一覧と同様に表示できる受信者の論理グループを生成できます。

すべての Outlook クライアントは、Exchange サーバーの名前を使ってプロファイルを構成します。Outlook クライアント ユーザーがアドレス帳を開いたとき、またはユーザーがメッセージを作成して、名前またはアドレスを [宛先] フィールドに入力したときに、Outlook クライアントは Exchange サーバーに指定されたグローバル カタログ サーバーを使用して、グローバル アドレス一覧または他のアドレス一覧の内容を検索します。

問題点

Outlook クライアントはアドレスを調べるために、グローバル カタログ サーバーと単一フォレストにある Exchange サーバーを使用する必要があります。このため、単一フォレスト内のクライアントは、同じ Exchange 組織の他のフォレストのアドレス一覧を表示できますが、異なる Exchange 組織のフォレストのアドレス一覧は表示できません。そのため、複数 Exchange 組織を持つ複数フォレストの展開では、以下の問題点に対処する必要があります。

• ユーザーは、異なるフォレストのオブジェクトのメール アドレスなど、アドレス帳のデータを照合できる必要があります。
• Outlook クライアントは、独自のフォレスト内ですべてのアドレスを解決できる必要があります。

図 9 は、各フォレストに Exchange サーバーを持つ 2つの Active Directory フォレストと各フォレストのメールが有効なユーザーを示しています。それぞれのフォレストのグローバル アドレス一覧 (GAL) は、他のフォレストのユーザーを含んでいません。このため、Exchange クライアントによるクエリは、他のフォレストのアドレス一覧は検索しません。

図 9: 独立した Exchange グローバルアドレス一覧 (GAL) を持つ 2つのフォレスト

図 9 で示す構成では、独立した Exchange 組織が 2 つのフォレストに展開されます。この場合、新たな構成を行う前は、フォレスト A はフォレスト B に存在するフレッドのアカウントを含んでいません。同様に、フォレスト B はフォレスト A に存在するジョンのアカウントを含んでいません。そのため、フォレスト A のグローバル アドレス一覧にアクセスするOutlook クライアントのユーザー が、アドレス帳を開くとき、フレッドはアドレス帳では検索されません。ジョンもまたエイリアスを使用してフレッドにメールを送ることができません。フレッドへメールを送信するには、SMTP の完全なアドレスを使用する必要があります。

同様の制限が、異なるフォレストに存在する配布リストやリソース (たとえば、会議室) にも適用されます。たとえば、配布リストがフォレスト A に存在する場合、新たな構成なしでは、Outlook クライアントがフォレスト B に存在するグローバル カタログからグローバル アドレス一覧情報を取得しているユーザーは、フォレスト B のアドレス帳のこの配布リストを確認できません。

解決策

アドレス帳の他のフォレストのメールの受信者を確認できるようにするには、メールの受信者がフォレスト間で同期を取られる必要があります。この事例では、メールの受信者は双方向に同期が取られます。

フォレスト間でのユーザーとグループの同期

異なるフォレストのユーザーが、アドレス帳で相互に参照できるようにする解決策は、プロキシ アドレスを持つメールが有効なオブジェクトを、Exchange 2000 Server を展開したフォレストに作成することです。プロキシ アドレス オブジェクトは、連絡先オブジェクトにより表現されます。図 10 では、フォレスト A に存在するジョンのメール アカウントは、フォレスト B に存在する連絡先オブジェクトである John により表されています。それに対して、フォレスト B に存在するフレッドのメールアカウントは、フォレスト A に存在する連絡先オブジェクトである Fred により表されています。Microsoft Identity Integration Server 2003 のような、ディレクトリ データ同期製品により同期が行われます。

図 10: 2 つのフォレスト間でのメールボックスの同期

この例では、両フォレストの管理者は、アドレス帳で、フォレスト B のユーザーにフォレスト A のユーザーを表示できるようにしたいと思っています。その後管理者は、以下の操作を実行するために、Microsoft Identity Integration Server 2003 のような、ディレクトリ同期サーバーを構成できます。

• メールが有効な全オブジェクトでフォレスト A を検索します。
• フォレスト B に対応する連絡先オブジェクトを作成します。

これらの操作は、ソース フォレストにメールが有効なオブジェクトが追加、削除、修正されたときに、全フォレストの情報を動的に更新するために定期的に実行するようスケジュールを設定できます。この同期によって複製されたユーザー オブジェクトは、Exchange サーバーの受信者更新サービス(既定値では毎分実行します) によって、グローバル アドレス一覧を含む既存のアドレス一覧を適切に更新します。その後、フォレスト B のユーザーであるフレッドが、フォレスト A からのユーザーであるジョンをアドレス帳で検索しようとしたとき、ジョンはフォレスト B の連絡先オブジェクトにより表されているので、フレッドはジョンを検索できます。

さらに、電子メール アドレスが連絡先オブジェクトに含まれているので、フォレスト B のユーザーはジョンのエイリアスを指定することにより、メッセージを送信できます。Exchange サーバーは、ジョンの連絡先オブジェクトに、ユーザーであるジョンのエイリアスの完全 SMTP アドレスを配置します。その後、ユーザーであるジョンのメールボックスを含む Exchange Server サービスに適切にメッセージを転送します。

ソース フォレスト (データが読み込まれるフォレスト) の管理者の決定と、対象フォレスト (ソース フォレストの適切なデータに対応するデータが更新されるフォレスト) に依存しますが、適切な構成を仮定して、Microsoft Identity Integration Server 2003 が一方向または双方向の同期を実行します。

メールが有効なセキュリティ グループや配布グループと同様に、このフォレストの外部で同期される連絡先オブジェクトのプロセスは非常によく似ています。表 1 で示すように、これらのオブジェクト型のすべては、連絡先として他のフォレストに同期されます。

表 1

ソース ディレクトリ	対象ディレクトリ
ユーザー	連絡先
連絡先	連絡先
グループ	連絡先

Exchange を使用しないフォレストでの、アドレスの同期の追加事例

上記の事例は、独立した Exchange 組織を展開する複数フォレストに適用されます。下記の条件で、Exchange サーバーを展開しないフォレストにアドレス一覧の同期が展開されます。

• メールボックスが有効なユーザー アカウントの属性は、ログオン ユーザー アカウントと共にフォレストに伝達される必要があります。たとえば、人事データベースが、通常、Exchange フォレストのユーザー アカウントの電話番号を更新し、他のアプリケーションがユーザー アカウント フォレストでこの情報を照合する場合、同期が必要になります。
• アドレス帳を使用する Outlook 以外のアプリケーション。

グローバル アドレス一覧の同期のコスト

グローバル アドレス一覧や他のアドレス一覧の同期のコストは、Microsoft Identity Integration Server 2003のような、ディレクトリ データ同期製品を実装するコストです。実装するすべての同期インフラストラクチャ用に、1 台の Microsoft Identity Integration Server 2003 サーバーが必要になります。たとえば、すべてのフォレストに対して、グローバル アドレス一覧の同期を集中管理する Microsoft Identity Integration Server 2003を使用することを決定した場合、コストは、1 台のサーバー コンピュータで Microsoft Identity Integration Server 2003 を実行するコストと、プロセスを管理する Microsoft Identity Integration Server 2003 管理者です。ただし、フォレスト管理者が互いに信頼せず、独自のソリューションを実行する場合、それぞれのフォレストが Microsoft Identity Integration Server 2003 サーバーと、フォレストに着信するデータを管理するための Microsoft Identity Integration Server 2003 管理者が必要になります。

どの同期ソリューションを使用するか

上記のオブジェクトの同期を可能にするソリューションは、複数の Exchange 組織間でのアドレス一覧の同期に使用されます。ただし、Microsoft Identity Integration Server 2003 の使用を強くお勧めします。Microsoft Identity Integration Server 2003 は、Microsoft Identity Integration Server 2003 の構成で指定したビジネス ルールにしたがって、複数の Active Directory フォレスト間のディレクトリ データを同期できます。

Microsoft Metadirectory Services (MMS) Version 2.2 をお使いの場合は、グローバル アドレス一覧の同期を可能にするために、MMS 2.2 に必要な構成を実行するマイクロソフトのコンサルタントを雇用することをお勧めします。

マイクロソフトは、Microsoft Identity Integration Server 2003 の出荷と同時に、Microsoft Identity Integration Server 2003 の構成を自動化する、グローバル アドレス一覧 (GAL) 同期ソリューションを提供する予定です。GAL 同期ソリューションは、グローバル アドレス一覧の同期を実行するための連絡先オブジェクトや配布グループの作成も含め、Microsoft Identity Integration Server 2003 の構成を大幅に簡略化します。GAL 同期ソリューションは、ユーザーの大多数のビジネス ルールを満たすことができるMicrosoft Identity Integration Server 2003 の構成を実行します。同時に、ユーザーはグローバル アドレス一覧の同期データに関して、個別のビジネス ルールに基づいて Microsoft Identity Integration Server 2003 の構成を修正できる柔軟性を持ちます。GAL 同期ソリューションの情報については、発行予定の『Multiforest Deployment Guide』に記載する予定です。

グローバル アドレス一覧の同期の管理上の考慮点

Microsoft Identity Integration Server 2003 によって、グローバル アドレス一覧データの同期を可能にするために、ソース フォレストと対象フォレストは以下のような情報を Microsoft Identity Integration Server 2003 管理者に提供する必要があります。

• ソース フォレストの管理者は、同期するオブジェクトの読み取りアクセス許可を持つユーザー アカウントを作成します。このアカウントの資格情報は、ソース フォレストからオブジェクトを読み取るために Microsoft Identity Integration Server 2003 によって使用されます。ソース フォレスト管理者は、グループ メンバシップの拡張を許可するかどうかを指定します。
• 対象フォレストの管理者は、Microsoft Identity Integration Server 2003 が新規連絡先オブジェクトを作成する組織単位を作成または識別します。管理者は、ユーザー アカウントを作成し、組織単位内のオブジェクトの作成、削除、更新 (書き込み) をアカウントに許可するために、組織単位のアクセス許可を与えます。組織単位の外部の対象フォレスト データおよびソース フォレスト データを使った改ざんの可能性を除去するために、管理者が同期オブジェクトの作成の目的で作成した組織単位、およびメール機能を保持する必要がある組織単位の外部アカウントの特定の属性のみに書き込みを許可します。
•  注
  フォレスト管理者がフォレストの内外両方でデータの同期を行うことを決定した場合、読み取りと書き込みの両方の操作を実行するために、管理者は同じユーザー アカウント資格情報を使用する必要があります。

グローバル アドレス一覧の同期のリスク モデル

グローバル アドレス一覧の同期を可能にすることに適用される 2 つの主なリスク モデルがあります。2 つのモデルは、同じ組織内に共存できます。これらのリスクは、すべての同期ソリューションのより一般的なコンテキストに適用されます。

• 個別のフォレスト管理者は、フォレスト間でデータを同期するために、集中管理する Microsoft Identity Integration Server 2003 管理者を信頼します。集中管理する Microsoft Identity Integration Server 2003 管理者が、故意にまたは偶然に Microsoft Identity Integration Server 2003 の間違った構成を行う可能性があるという危険性を容認していることになります。規則としては、同期を実行するために Microsoft Identity Integration Server 2003 が使用する資格情報を持つユーザーが、悪意のあるアクティビティを許可するアクセス許可を持たないようにすることにより、各フォレスト管理者はフォレストのデータの漏洩や改ざんを防ぐことができます。このアプローチをお勧めします。
• 個別のフォレスト管理者は、集中管理する Microsoft Identity Integration Server 2003 管理者が、故意にまたは偶然に Microsoft Identity Integration Server 2003 の間違った構成を行う可能性があるという危険性を容認しません。この事例では、各フォレスト管理者は、フォレストからフォレストへ、または双方向のデータの同期を実行する Microsoft Identity Integration Server 2003 サーバーを展開します。この事例で必要な唯一の連係は、パートナーのフォレスト管理者は、適切なデータの読み取りや書き込みを許可するのに十分な資格情報を提供する必要があります。このアプローチは、やや複雑でより高いコストがかかります。コストは、関係するフォレストの数に依存します。

予定表の空き時間情報の同期

カレンダ情報は、予定表の空き時間を表示することで、ユーザーが会議のスケジュールを設定できるようにします。メンバ間または異なるフォレスト間で頻繁に会議が開催される場合は、スケジュールの空き時間情報が、異なるフォレストの Exchange 組織間での空き時間を考慮した会議開催通知を可能にします。

問題点

ジョンは、フォレスト A にメールボックスを持っていて、Outlook を使用してフレッドとの会議のスケジュールを設定したいと思っています。フレッドのメールボックスはフォレスト B に存在します。ジョンは、また、フォレスト C からメンバを招待したいと思っています。図 11 に示すように、ジョンが他のフォレストのユーザーやグループの空き時間情報を参照できない場合、会議のスケジュールを個人的に連絡して確認する必要があります。

図 11: 予定表のデータが使用できない場合のスケジュール

予定表の空き時間情報は、Active Directory ではなく、Exchange 2000 サーバーのシステム パブリック フォルダに格納されています。このため、異なるフォレスト間でのグローバル アドレス一覧情報の同期だけでは、ユーザーに、他のフォレストの Exchange 組織のメールボックスを持つユーザーやリソースの空き時間情報を表示できるようにすることは不可能です。

解決策

フォレスト A にメールボックスを持つユーザーに、フォレスト B と フォレスト C 内の Exchange 組織にメールボックスを持つユーザーとリソースのスケジュール情報を表示できるようにするには、フォレスト B とフォレスト C の Exchange サーバーに格納されているシステム パブリック フォルダのデータが、フォレスト A の Exchange サーバーのシステム パブリック フォルダに含まれている必要があります。このような同期を可能にするには、Microsoft Exchange Interorg Replication Utilityを使用することをお勧めします。このツールの使用の情報については、サポート技術情報の文書 238573、「[XADM] InterOrg Replication ユーティリティのインストール、構成、使用」を参照してください。この資料を検索するには、Web Resources ページ (https://support.microsoft.com/default.aspx?scid=fh;JA;KBHOWTO) の「Microsoft Knowledge Base」(英語) を参照してください。

大部分の複数フォレスト環境では、1 台の同期サーバーが複数フォレストを調整できます。図 12 は、3 つのすべてのフォレスト間で予定表の空き時間情報の同期を取るために、Interorg Utilityを実行する 1 台のサーバーを使用する複数フォレストの展開を示しています。この事例では、各フォレストは他の 2 つのフォレストと双方向でデータの同期を取ります。

図 12: 1 台のサーバーにより 3 つのフォレスト間で同期が取られる予定表の空き時間情報

移行についての考慮点

複数の Active Directory フォレストを含む環境、および異なる Active Directory フォレストの複数の Exchange 組織を含む環境では、組織の変更または各従業員の配置替えにより、多くの場合、ユーザー アカウント、コンピュータ アカウント、グループ、メールボックスなどの移行が必要になります。

ユーザーの移行

ユーザーの移行には、アカウント、グループ、コンピュータ アカウントの移行があります。フォレスト間でユーザー アカウントを移行するには、Active Directory 移行ツール (ADMT) を使用します。ADMT の使用方法と ADMT のダウンロードに関する情報については、Web Resources ページ (https://www.microsoft.com/windows/reskits/webresources/) の Active Directory リンクで「Active Directory Migration Tool Overview」(英語) を参照してください。

メールボックスの移行

異なるフォレストの異なる Exchange 組織間でメールボックスを移行するには、Exchange Server 移行ウィザードを使用します。ユーザーのメールボックス アカウントの移行の方法の詳細については、Exchange のオンライン ヘルプを参照してください。

ユーザーのメールボックスとユーザー アカウントの両方を移行する必要がある場合、ユーザーのメールボックスよりも先にユーザー アカウントを移行します。

その他のテクノロジについての考慮点

グループ ポリシーとメッセージ キューの機能は、複数の Windows フォレスト間で直接転送できません。この資料の後半の「グループ ポリシー」と「メッセージ キュー」で説明するように、いくつかの回避策を利用できます。

さらに、異なるフォレストのドメイン間または 2 つのWindows Server 2003 フォレスト間の信頼関係を使用する場合、この資料の後半の「フォレスト間のログオンへのユーザー プリンシパル名の使用」で説明するように、フォレストにまたがってログオンするためにユーザー プリンシパル名 (UPN) を使用するかどうかの検討は、選択した UPN サフィックスおよび作成した UPN の形式に関する決定に影響することがあります。

グループ ポリシー

グループ ポリシーは、ユーザーとコンピュータを管理する場合の制御を提供します。グループ ポリシーは、同じフォレスト内のドメイン、組織単位、サイトに適用できます。複数フォレストで、同じグループ ポリシー オブジェクトを適用することはできません。

フォレスト管理者は、必要に応じて、個別のグループ ポリシー オブジェクトをドメイン、組織単位、サイトに適用できます。たとえば、合併した組織を管理していて、元のフォレストの各ドメインのユーザーとコンピュータに影響するように、同一のグループ ポリシー オブジェクトを適用する場合、個別のグループ ポリシー オブジェクトを他の (合併した) フォレストの各ドメインのすべてのユーザーとコンピュータに適用します。

フォレスト間でのグループ ポリシー管理が重要になるその他の事例は、テストから実稼動までの事例です。たとえば、多くのユーザーは、準備段階で、実稼動フォレストに似た、独立したテスト フォレストを管理します。ポリシーの展開はテスト環境でテストが行われた後、実稼動フォレストでテスト的に展開を始めます。

グループ ポリシー管理コンソール (GPMC) は、フォレスト間でグループ ポリシー オブジェクトをインポートして、コピーすることにより、複数フォレスト間でのグループ ポリシーの管理を可能にします。GPMC は、Windows Server 2003 リリース後まもなく、Microsoft Web サイトで入手可能になります。グループ ポリシー管理は Windows XP Professional および Windows Server 2003 オペレーティング システムを実行するコンピュータのみで機能しますが、Windows 2000 Server ファミリの Service Pack 2 以降のメンバを実行するドメイン コントローラ上のグループ ポリシー オブジェクトをリモートに管理できます。

メッセージ キュー

メッセージキュー (MSMQ) を使用し、複数の Active Directory フォレストの境界にまたがって実行されるアプリケーションの展開を計画している場合、アプリケーションの開発者は以下の推奨事項に従う必要があります。

• 以下のように、目的のキューに直接形式名を使用します。

• メッセージ キューは、目的の名前を解決するために Active Directory を使用しません。
• ユーザーは、メッセージ キュー組み込みの認証機能や暗号化機能を使用できません。

• アプリケーションが Windows XP または Windows Server 2003 プラットフォームで実行される場合、クライアントの認証を使用した HTTPS 経由のメッセージキューを使用します。

メッセージ キューの詳細については、Windows 2000 Server のヘルプまたは Windows Server 2003 のヘルプとサポート センターを参照してください。

フォレスト間のログオンへのユーザー プリンシパル名の使用

ユーザー プリンシパル名 (UPN) は、電子メール名に似ていますが、ドメインへのログオンに使用されるユーザー アカウント名の変形です。構文は、<ユーザー名>@<文字列> の形式です。UPNを使用して、同じフォレストまたは異なるフォレスト内の異なるドメイン間で同じログオン名を使用できます。

UPN には 2 つの形式があります。

• 暗黙的 : 常に userID@DNSDomainName の形式です。たとえば、johns@corp.contoso.com は、John Smith のアカウントの UPN です。彼のユーザー ID は johns で、アカウントは corp.contoso.com フォレストのメンバです。この暗黙の UPN は、明示的な UPN が定義されているかどうかにかかわらず、常にユーザーのアカウントに関連付けられます。
• 明示的 : 常に string@Anystring の形式です。"string" と "Anystring" は、管理者により明示的に定義されます。たとえば、John Smith は ITJS@coneast という UPN を持っています。明示的 UPN は、組織がドメイン名やフォレストの構造を公開したくない場合に便利です。

UPN "サフィックス" は UPN を派生した名前空間を示す文字列です。UPN サフィックスは、完全な UPN の右端のアット マーク (@) の右側のすべての文字列を含みます。右端の @ マークの左側のすべての文字列は、他の @ マークを含んでいても、ユーザー名の一部と考えられます。UPN サフィックスは構造内でフラットまたは階層のいずれかになることがありますが、一般的に、フラットな名前空間を識別するために使用されます。

UPN は主にドメイン間の対話型ログオンに使われます。複数フォレストでは、UPN ログオンはいくつかの条件でフォレスト間で利用できます。以下の条件のいずれかを満たすときは、UPN を異なるフォレストのドメインへのログオンに使用できません。

• 共有 UPN サフィックス : 複数のフォレストが同じ UPN サフィックスを使用している場合、ユーザーは信頼しているフォレストのドメインにログオンするために UPN を使用できません。独自のフォレスト内でのログオンにのみ、UPN を使用できます。
• 明示的な UPN と外部信頼関係 : 異なるフォレストのドメイン間で外部信頼関係が作成されると、それぞれのドメインのユーザーは、他のフォレストの信頼しているドメインにログオンするために、明示的に作成された UPN を使用できません。暗黙の UPN だけを使用できます。

表 2 は、異なるフォレストのドメイン間に存在するさまざま種類の信頼関係によって、フォレスト間で対話形式でログオンするためにユーザーが UPN を使用できるかどうか、および UPN サフィックスが複数フォレスト間で共有されるかどうかをまとめたものです。

表 2 フォレスト間でログオンするために UPN を使用できるかどうか

フォレスト間の信頼の種類	明示的 UPN	暗黙的 UPN	共有 UPN サフィックス
異なるフォレストのドメイン間で信頼関係なし	不可	不可	適用なし
異なるフォレストのドメイン間で外部信頼関係なし	不可	可	不可
Windows Server 2003 のフォレスト間でのフォレストの信頼関係	可	可	不可

 注
Windows Server 2003 の Active Directory フォレストの機能レベルを持つフォレスト間で、フォレストの信頼関係を使用できます。Active Directory の機能レベルの情報については、Windows Server 2003 ヘルプとサポート センターを参照してください。

この要約では、複数フォレストで UPN サフィックスを共有しても、他のフォレストのドメインに対話形式でログオンする必要がない場合、外部信頼関係またはフォレストの信頼関係のどちらも使用できます。

他のフォレストに対話形式でログオンする際、UPN を使用するには、各フォレストで一意となる UPN サフィックスを使用します。この場合、対話形式のログオンは、以下のように使用できます。

• フォレストの信頼関係を使用する場合、明示的 UPN と暗黙的 UPN の両方を使用できます。
• 外部ドメイン信頼関係を使用する場合、暗黙的 UPN のみを使用できます。

フォレスト間で使用できない機能

複数フォレストの展開では、経験上、どのような場合でも多くのユーザーが使用しない機能は異なるフォレスト間で有効にできなくなっていますが、複数フォレストを展開する場合の影響の全貌が明らかになるように、この資料では有効にできない機能も含めて説明します。

フォレスト間でのメール フォルダの委任

フォレスト内では、他のユーザーのメールボックスのメール フォルダにアクセスできるように、ユーザーの権威を委任できます。

問題点

2 人のユーザーのメールボックスが異なるフォレストの Exchange サーバー組織によってホストされている場合、1 つのフォレストのユーザーは他のフォレストのユーザーのメール フォルダにアクセスできません。

この問題点の典型的な例は、秘書に予定の管理を委任したい企業幹部の例です。このような企業幹部と秘書のメールボックスが、異なる Active Directory フォレスト内の Exchange サーバー組織に存在している場合、このような管理の委任は不可能です。

回避策

他人のメール フォルダにアクセスする必要があるユーザーのメールボックスが、同じ Exchange サーバー組織に存在するようにします。また、ユーザーが異なる Exchange サーバー組織にホストされているメールボックスにアクセスする必要がある場合、他のメールボックスにアクセスする必要のあるユーザーのために、適切なフォレストにメールボックスを作成します。たとえば、上記の企業幹部と秘書の場合、秘書は、企業幹部のフォレストに新たなメールボックスが必要になります。

ページのトップへ

複数フォレスト機能の実装とコストのまとめ

この資料をお読みになった後、表 3 の情報を使用して、複数フォレストの機能を組織に実装する相対的なコストを見積ります。

表 3フォレスト間の機能と構成コスト

有効な機能	構成コスト
アドレス一覧情報の表示	Microsoft Identity Integration Server 2003 同期サーバーの展開 同期管理者のトレーニングとサポート 対象フォレストごとに同期データ コンテナを作成 フォレストごとに同期アカウントを作成 同期のアクセス許可を有効にする GAL 同期ツールの実行
予定表の空き時間情報の表示	「アドレス一覧情報の表示」の構成コストに以下のコストを加算します。 PF 同期サーバーの展開 PF 同期管理者のトレーニングとサポート Exchange 組織間での MAPI 対応のローカル エリア ネットワーク (LAN) 接続の確認
DNS インフラストラクチャのブリッジ	以下の複数の DNS 構成 委任 条件付き転送 (Windows Server 2003 のみ) セカンダリ ゾーン
リソース アクセス	信頼関係の構成 フォレストの信頼関係 (Windows Server 2003 のみ) または 外部ドメイン信頼関係 (Windows Server 2003 または Windows 2000) グループの作成 役割ベースのグローバル グループ リソース ベースのドメイン ローカル グループ 使用可能であれば、ユニバーサル グループ グローバル グループまたはユニバーサル グループのローカル グループへの追加 リソースへのアクセス許可の適用
アプリケーション データの取得	プロバイダの構成 または データを同期するために、Microsoft Identity Integration Server 2003 を構成 (この表の「アドレス一覧情報の表示」のコストを参照)
プリンタの場所	プリンタの場所をクライアントで構成 または プリンタ アプリケーション データを同期するために、Microsoft Identity Integration Server 2003 を構成 (この表の「アドレス一覧情報の表示」のコストを参照)

ページのトップへ