Active Directory フォレスト トポロジ

 

適用先: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

トピックの最終更新日: 2007-08-01

Microsoft Windows Server 2003 と Microsoft Exchange Server 2007 はどちらもディレクトリ サービスに Active Directory ディレクトリ サービスを使用するため、Exchange 2007 を Active Directory 構造に統合する方法を決定する必要があります。Active Directory には、Active Directory トポロジを定義するために組み合わせて使用する次の論理要素が含まれます。

  • フォレスト
  • 1 つ以上のドメイン
  • 1 つ以上の Active Directory サイト

Active Directory フォレスト

フォレストは、ディレクトリ サービスの最も外側の境界を表します。フォレスト内のすべてのリソースが、リソースが存在するフォレスト内の場所に関係なく相互を暗黙的に信頼するように、フォレストは継続的なセキュリティ コンテキスト内で機能します。各フォレスト内には、共通のディレクトリ スキーマとディレクトリ サービスの構成が存在します。フォレストは、1 つまたは複数のドメインから構成できます。フォレスト トポロジには 2 つの種類があります。それは、単一フォレストと複数フォレストです。

単一のフォレストのトポロジ

単一のフォレストのトポロジでは、Exchange は組織全体にわたる単一の Active Directory フォレストにインストールされます。すべてのユーザーおよびグループ アカウントとすべての Exchange 構成情報は、同じフォレストにあります。

組織に単一の Active Directory フォレストがある場合は、そのフォレストに Exchange 2007 を実装できます。最も豊富な電子メール システム機能を提供し、最も効率化された管理モデルを備えているという理由から、単一のフォレストの Exchange 設計をお勧めします。単一のフォレストにすべてのリソースが含まれるため、単一のグローバル アドレス一覧 (GAL) にフォレストのすべてのユーザーが含まれます。次の図は、このシナリオを示しています。

単一フォレストでの Exchange の展開

単一のフォレストのオプションには以下の利点があります。

  • 最も豊富な電子メール システム機能を提供します。
  • 効率化された管理モデルを提供します。
  • 既存の Active Directory 構造を利用します。
  • 既存のドメイン コントローラおよびグローバル カタログ サーバーを使用します。
  • GAL の同期を必要としません。

単一のフォレストの主な欠点は、管理者が Active Directory と Exchange オブジェクトの管理責任を共有または分割する方法を決定する必要があることです。

複数のフォレストのトポロジ

最も豊富なメッセージング機能が提供される単一のフォレストのトポロジをお勧めしますが、さまざまな理由により、複数のフォレストを実装する必要がある場合もあります。それらの理由のいくつかは、次のとおりです。

  • メッセージング サービスの分離が必要な複数のビジネス単位が存在する。
  • 異なるスキーマ要件を有する複数のビジネス単位が存在する。
  • 吸収、合併、または事業の再編成が行われた。

どのような場合であっても、ビジネス単位の厳密な境界を作成する唯一の方法は、ビジネス単位ごとに個別の Active Directory フォレストを作成することです。Active Directory 構成がこの条件に当てはまる場合、Exchange を実装するためにお勧めする方法は、Exchange リソース フォレストを使用することです。Exchange リソース フォレストの詳細については、後の「リソース フォレストのトポロジ」を参照してください。

ただし、吸収や合併、または複数のフォレストが Exchange の独自のインスタンスを既に実行しているなどの理由で、リソース フォレストにすることが適切でないと考えられる場合もあります。このような場合は、フォレスト間のトポロジを実装できます。

フォレスト間のトポロジ

フォレスト間のトポロジでは、企業には複数の Active Directory フォレストがあり、フォレストにはそれぞれ 1 つの Exchange 組織が含まれています。リソース フォレストのトポロジとは異なり、ユーザー アカウントはメールボックスから分離されていません。その代わり、ユーザー アカウントと、このアカウントに関連付けられたメールボックスは同じフォレストに含まれます。

フォレスト間のトポロジを実装する主な利点は、Exchange 組織間でデータの分離とセキュリティの境界を維持できることにあります。このトポロジの欠点には、以下のものがあります。

  • 最も豊富なメッセージング機能が提供されません。
  • 1 つのフォレストから別のフォレストにメールボックスを移動する場合、ターゲット フォレストに委任先に対する連絡先があるか、委任先のメールボックスを同時に移動しない限り、メールボックスの委任アクセス許可は保持されません。
  • フォレスト間で空き時間情報を同期し、その情報を使用して会議をスケジュールすることはできますが、Microsoft Office Outlook の [ほかのユーザーのフォルダを開く] 機能を使用して他のフォレストのユーザーの予定表を表示することはできません。
  • 他のフォレストから移動されたグループは連絡先として表されるため、グループのメンバを表示することはできません。連絡先として表されるグループを含むフォレストにメールが送信されるまでは、グループ メンバシップは展開されません。
  • フォレスト間のディレクトリ オブジェクトの同期だけでなく、空き時間情報データのレプリケーションも必要です。ディレクトリ同期で最も一般的に使用されてきたソリューションは、Microsoft Identity Integration Server (MIIS) 2003 Service Pack 2 (SP2) または Identity Integration Feature Pack for Microsoft Windows Server Active Directory with SP2 でした。さまざまなフォレストの Exchange 組織間で空き時間情報および予定表情報を共有するために、Exchange 2007 の可用性サービスを使用できます。

複数のフォレストを含む複雑な Exchange 組織

リソース フォレストのトポロジ

Exchange の実行専用の Active Directory フォレストを個別にセットアップする必要がある場合があります。たとえば、保持する必要がある既存の Active Directory フォレストがあるとします。あるいは、Active Directory オブジェクトと Exchange オブジェクトの管理を分離する必要があるとします。このため、Exchange の実行専用の Active Directory フォレストを個別にセットアップする必要が生じる場合があります。個別の専用フォレストは、Exchange リソース フォレストと呼ばれます。リソース フォレスト モデルでは、ユーザー、コンピュータ、およびアプリケーション サーバーがインストールされている Active Directory フォレストとは別の Active Directory フォレストに Exchange がインストールされます。Active Directory の管理と Exchange の管理の間にセキュリティの境界を必要とする企業では、通常このオプションを使用します。

Exchange リソース フォレストは、Exchange の実行とメールボックスのホスト専用です。ユーザー アカウントは、アカウント フォレストと呼ばれる 1 つ以上のフォレストに含まれます。アカウント フォレストは、Exchange リソース フォレストとは別のフォレストです。アカウント フォレストと Exchange リソース フォレストの間に一方向の信頼が作成され、Exchange フォレストがアカウント フォレストを信頼できるようになります。これにより、アカウント フォレスト内のユーザーに Exchange リソース フォレストのメールボックスへのアクセスが許可されます。Exchange 組織は Active Directory フォレストの境界を越えることができないため、Exchange リソース フォレストで作成される各メールボックスは Exchange リソース フォレスト内に対応するユーザー オブジェクトを持つ必要があります。Exchange リソース フォレストのユーザー オブジェクトは、ユーザーによってログオンされることはなく、攻撃ポイントになることを避けるために無効にされています。一般的に、ユーザーは重複アカウントが存在することを認識しません。Exchange リソース フォレストのアカウントは無効になっていて、ログオンのために使用されないため、アカウント フォレストにあるユーザーの実際のアカウントにメールボックスにログオンするアクセス許可を与える必要があります。Exchange リソース フォレストの無効なユーザー オブジェクトの msExchMasterAccountSID 属性にアカウント フォレストのユーザー オブジェクトのセキュリティ識別子 (SID) を含めることにより、アクセスが許可されます。

Exchange リソース フォレストを使用している場合、ディレクトリ同期が不要になる可能性があります。Exchange と Outlook の観点から、ディレクトリ サービスに一覧表示されるすべてのオブジェクトは 1 つの場所から、この場合は Exchange リソース フォレストをホストするディレクトリ サービスから取得されます。ただし、アカウント フォレストに GAL 関連のデータが存在する場合は、GAL を使用するために同期を実行して Exchange リソース フォレストにデータを取得する必要があります。さらに、アカウント フォレストでアカウントを作成するときに、メールボックスを持つ無効なアカウントが Exchange リソース フォレストに作成されるように、プロセスをセットアップする必要がある場合があります。

アカウント フォレストの有効なユーザーは、リソース フォレストの無効なユーザーに接続されたメールボックスに関連付けられます。この構成により、ユーザーは異なるフォレストにあるメールボックスにアクセスすることができます。このシナリオでは、リソース フォレストとアカウント フォレストの間に信頼関係を構成します。管理者がアカウント フォレストでユーザーを作成するたびに、メールボックスを持つ無効なユーザーが Exchange リソース フォレストに作成されるように、準備プロセスをセットアップする必要がある場合もあります。

Exchange リソースはすべて単一のフォレストに含まれるため、単一の GAL にフォレストのすべてのユーザーが含まれます。専用の Exchange フォレスト シナリオの主な利点は、Active Directory の管理と Exchange の管理の間のセキュリティの境界です。

このトポロジの欠点には、以下のものがあります。

  • リソース フォレストの実装により、Exchange の管理と Active Directory の管理の分離が可能になります。ただし、リソース フォレストの展開に関連するコストがこの分離の必要性を上回る場合があります。
  • Exchange を実行する Microsoft Windows サイトに、追加のドメイン コントローラとグローバル カタログ サーバーをインストールすると、コストが増加します。
  • Active Directory の更新を Exchange に反映するための準備プロセスが必要です。一方のフォレストにオブジェクトを作成するときは、対応するオブジェクトがもう一方のフォレストに作成されるようにする必要があります。たとえば、一方のフォレストにユーザーを作成するときは、もう一方のフォレストに、そのユーザー用のプレースホルダが作成されるようにします。対応するオブジェクトは、手動で作成することができます。また、このプロセスを自動化することもできます。

リソース フォレストのシナリオには、Exchange をホストする 1 つのフォレストを含む複数のフォレストというシナリオがあります。複数の Active Directory フォレストがある場合、Exchange を展開する方法は、フォレスト間で保持する必要がある独立性の程度によって異なります。ディレクトリ オブジェクトに対してはセキュリティ (フォレスト) の境界を必要とするが、Exchange オブジェクトは共有できるビジネス単位を抱える企業は、いずれかのフォレストで Exchange を展開し、そのフォレストを使用して企業内の他のフォレストのメールボックスをホストすることを選択できます。Exchange リソースはすべて単一のフォレストに含まれるため、単一の GAL にすべてのフォレストのすべてのユーザーが含まれます。

このシナリオの主な利点には、以下のものがあります。

  • 既存の Active Directory 構造を使用します。
  • 既存のドメイン コントローラおよびグローバル カタログ サーバーを使用します。
  • フォレスト間の厳密なセキュリティの境界を提供します。

このシナリオの欠点には、以下のものがあります。

  • Active Directory の更新を Exchange に反映するための準備プロセスが必要です。たとえば、フォレスト A に新しい Active Directory ユーザーを作成すると、アクセス許可を持つ、メールボックスが有効なオブジェクトが生成されるようなスクリプトを作成できます。このオブジェクトはフォレスト B では無効になります。
  • フォレスト管理者は、Active Directory オブジェクトと Exchange オブジェクトの管理責任を共有または分割する方法を決定する必要があります。

リソース フォレストを含む複雑な Exchange 組織

Active Directory ドメイン

ドメインは、まとめて管理されるセキュリティ プリンシパルとその他のオブジェクトをグループ化したものです。ドメインは柔軟性に富んでいます。どの構成をドメインに実装するかについては、管理者の判断に任されています。たとえば、ドメインは、物理的に単一の場所に配置されているユーザーおよびコンピュータのグループを表すことも、多くの場所または地理的に広い範囲に配置されているすべてのユーザーおよびコンピュータを表すこともあります。管理およびインフラストラクチャのサポートの統合が進むと、一般的に、サポート コストを削減するために地理的に広い範囲にわたってドメインが展開されます。ただし、ディレクトリ サービスの範囲が拡大すると共に、できる限り効率的に適切なリソースへのディレクトリ アクセスが可能になるようにする必要があります。

Active Directory サイト

Active Directory サイトは、信頼性の高い接続を有する Active Directory 内のコンピュータの論理グループを表します。Active Directory サイトでは、ディレクトリ リソースの特定のセットまたはグループを使用するクライアント コンピュータをパーティションに分割できます。Active Directory サイトは、接続状態の良い 1 つ以上の TCP/IP サブネットであり、管理者は Active Directory のアクセスおよびレプリケーションを構成することができます。これらのサブネットは、物理的なトポロジに対応する場合も対応しない場合もあります。

次の図は、Active Directory の論理的な定義と物理的な場所の間で最も一般的に展開される関係のいくつかを示しています。

フォレスト、ドメイン、場所、およびサイト

Active Directory の展開シナリオ

Exchange を Active Directory と統合するための主なシナリオには、次の 4 つあります。

  • 単一フォレスト
  • リソース フォレスト
  • フォレスト間
  • 吸収および合併

次の表は、各シナリオの利点をまとめたものです。

Active Directory シナリオ 説明 このシナリオを使用する理由

単一フォレスト

ユーザーとユーザーのメールボックスは同じフォレストに含まれます。

  • 最も豊富なメール システム機能のセット。
  • 管理が効率化されている。
  • 既存の Active Directory 構造を使用している。
  • 他のフォレストとの同期を必要としない。

リソース フォレスト

Exchange の実行および Exchange メールボックスのホストのために 1 つのフォレストを専用に用意します。メールボックスに関連付けられたユーザー アカウントは、1 つ以上の別のフォレストに含まれます。

  • Active Directory と Exchange の管理の間にあるセキュリティの境界。
  • 複数のフォレスト環境での Exchange の展開が簡略化されている。
  • ネットワークおよびユーザー アカウント インフラストラクチャの制御が制限されている。

フォレスト間

Exchange は個別のフォレストで実行されますが、電子メール機能は複数のフォレストにわたって利用できます。

  • データとサービスの分離が必要な複数のビジネス単位が存在する。
  • 異なるスキーマ要件を有する複数のビジネス単位が存在する。
  • 吸収、合併、または再編成

吸収および合併

吸収および合併が行われると、多くの場合、組織が結合されるまでに複数の Exchange 組織が共存することになります。この場合の考慮事項は、複数のフォレストが存在する場合のシナリオと同様ですが、移行に関する追加の考慮事項があります。

吸収および合併は複数のフォレスト展開の特殊な例で、移行時の問題についてさらに注意を要します。

参照している情報が最新であることを確認したり、他の Exchange Server 2007 ドキュメントを見つけたりするには、Exchange Server TechCenter を参照してください。