グローバルな Active Directory ドメインと信頼関係のインフラストラクチャの設計

  • [アーティクル]

このシナリオでは、多国籍企業で地理的に離れたオフィス間、および買収した子会社との間で発生するニーズに合わせて、Windows 2000 ドメイン インフラストラクチャを作成する方法を示します。

トピック

目的
設計のロジック
フォレスト構造の作成
Reskit.com フォレスト内でのドメイン構造の作成
明示的な信頼関係の構築
その他の参考資料

目的

このシナリオの目的は以下のとおりです。

  • 2 つの自律的な企業活動のセキュリティ、管理、およびリソースに関する必要性に応えます。

  • 距離的に離れた各企業部門を単一の企業として機能させながら、それぞれで個別の IT 組織を持つことを可能にします。

  • 大陸間のワイド エリア ネットワーク (WAN) リンクを経由するドメイン複製処理を最小限に抑えます。

  • 以前は個別の企業であった製造部門で必要になるセキュリティ面および名前の割り当てに関する特別な注意事項に配慮します。

  • 緊密に連携したヨーロッパの部門間でリソース共有を最適化します。

  • 親会社の北米の本社および支社の運用を 1 つの IT 組織の元で管理します。

次の「設計のロジック」では、上記の目的をどのようにして達成したかを説明します。

設計のロジック

このシナリオでは、多国籍企業 Resource Kit Corporation において、各地域の多数の部門および支社で生じるさまざまなニーズに最善に応えることができるように、Windows 2000 ディレクトリ サービス Active Directory・構造を編成します。図 1 に示すように、各地域にオフィスが存在します。Resource Kit Corporation は、本社を Seattle に置き、アメリカ、カナダ、およびヨーロッパに支社を持ち、買収した子会社がアジアにあります。新しく買収したアジアの子会社は、さまざまな属性を以前の企業から引き継いでいており、Windows 2000 ドメイン構造を持っています。親会社のユーザーと子会社のユーザーは相互に、相手組織のリソースに対して制限付きのアクセスを必要とします。

domain01-01

図 1: Resource Kit Corporation オフィスの地理的な場所

このシナリオでは、架空の企業モデルに対応する Windows 2000 ドメインおよびフォレストの構成を仮定しています。Microsoft® Windows NT® 4.0 ドメインからのドメインの移行については考慮していません。

このシナリオではまた、LAN および WAN の速度に応じてサイトが構成されていることを想定しています。図 1 のマップ上の各場所は、Active Directory 内の個別のサイト オブジェクトとして構成されています。

フォレスト構造の作成

Resource Kit Corporation の Windows 2000 ドメイン インフラストラクチャについて計画する場合、最初に決定する必要があるのは、単一の Windows 2000 Active Directory フォレストとして Resource Kit Corporation 全体を管理できるかどうかです。Resource Kit Corporation の製造拠点と事業オフィスの大半は、北米およびヨーロッパにあります。これらのユーザーはすべて、共通の管理組織に属しています。Resource Kit Corporation はまた、Hong Kong SAR, PRC をベースとし、Tokyo に販売および集配送の拠点を持ち、独立した事業を営む企業を買収して子会社にしています。この子会社には、十分に機能しているドメイン ネーム システム (DNS) ゾーンと有効な IT 組織、ディレクトリ セキュリティ、そして組織単位構造が存在しています。

Resource Kit Corporation は、フォレスト構造のセットアップ方法を決定する際に、単一の Active Directory フォレスト内にオフィスをグループ化した場合の利点を考慮しました。このような構成で得られる利点は、フォレスト内のすべてのドメインで以下の機能を共有できることにあります。

  • 単一のスキーマで、ディレクトリ内に格納されたオブジェクトの種類を定義できます。

  • 単一の構成コンテナで、サイトとサービスを構成、発行できます。

  • 単一の グローバル カタログ で、フォレスト全体を対象にしたディレクトリ検索機能を利用できます。

  • 双方向の推移性の信頼関係を利用できます。

Resource Kit Corporation は、北米のオフィスと Milan の支社で管理構造を共有しているので、それらを 1 つの Active Directoryフォレスト (reskit.com フォレスト) 内に編成することにしました。しかし、買収した企業のドメイン構造は、個別のフォレスト (acquired01-int.comフォレスト) として残し、新しいドメインとして reskit.com フォレストに組み入れません。買収した企業のフォレストの単一のドメインから、新しい親会社 (Resource Kit Corporation) のフォレストのドメインにオブジェクトを移行することもできますが、ユーザーを移行し、管理権限およびポリシーを再び割り当てることを強いるビジネス面のメリットがありません。さらに、Resource Kit Corporation と新しく買収した企業は、本質的に個別の企業実体として運営されているので、買収した企業のドメインと、reskit.com フォレスト内のドメイン間で、スキーマと構成のデータ、およびグローバル カタログを複製してもメリットは得られません。

重要 フォレスト間でオブジェクトを移動させるただ 1 つの方法は、あるフォレストのドメインから別のフォレストのドメインにオブジェクトを移行した後、移行したディレクトリ オブジェクトとリソースについて、権限の委任を再び割り当てることです。

図 2 は、Resource Kit Corporation 組織の 2 つのフォレストのフォレスト ルート ドメインを示しています。

domain01-02

図 2: Resource Kit Corporation の 2 つの分離したフォレスト

Resource Kit Corporation では、次の手順でフォレスト内のドメイン構造を設計しました。子会社 acquired01-int.com の既存のドメイン構造は、Tokyo の営業所を含めて単一のドメインとして、フォレスト内でそのまま使用します。しかし、さまざまな商品グループが存在し、地理的に離れているオフィスもあるので、reskit.com フォレストでは部門を複数のドメインに分割することが必要です。

Reskit.com フォレスト内でのドメイン構造の作成

Resource Kit Corporation は、reskit.com フォレスト内のオフィスに最も適したドメイン構造を決定する必要があります。フォレスト ルート ドメインは削除できないので、慎重に計画することが必要です。また、フォレスト全体の構成について厳格な管理作業を継続的に行うために、少数の管理者に権限を与える以下の 2 つのグループをフォレスト ルート ドメインにだけ格納します。

  • Enterprise Admins グループ。このメンバは、新しいドメインの作成、サイトとサブネットの管理、動的ホスト構成プロトコル (DHCP) サーバーの承認を行うことができます。

  • Schema Adminsグループ。このメンバは、スキーマの変更を承認することができます。

Resource Kit Corporation では、これらの役割をドメイン管理の役割から分離し、フォレスト ルート ドメインが古くなる危険性をなくすために、専用のフォレスト ルート ドメインを使用することにしました。フォレスト ルート ドメイン内で小数のアカウントだけを作成するので、ドメインのサイズは十分に小さく、ネットワーク上のその他の任意のドメイン コントローラに簡単にバックアップでき、中央の場所で災害が発生してもフォレスト ルート ドメインを保護できます。

メモ 既定の設定では、フォレストの最初のドメイン コントローラはグローバル カタログ サーバーです。このドメイン コントローラは、フォレスト内で唯一、グローバル カタログ サーバーとして自動的に有効になります。各ドメインの最初のドメイン コントローラは、ドメインのインフラストラクチャ マスタの flexible single-master operation の役割の所有者です。したがって、フォレストの最初のドメイン コントローラは、ドメインのグローバル カタログ サーバーおよびインフラストラクチャ マスタの双方の役割を担います。フォレスト内に複数のドメインが存在し、ドメイン内に複数のドメイン コントローラが存在する場合、インフラストラクチャ マスタの役割とグローバル カタログ サーバーが一致しない場合があります (ドメイン内のすべてのドメイン コントローラがグローバル カタログ サーバーである場合は当てはまりませんが、このようなケースはあまりありません) 。したがって Resource Kit Corporation では、インフラストラクチャ マスタの役割を、既定のグローバル カタログ サーバー (フォレスト内の最初のドメイン コントローラ) から、reskit.com ドメイン内のグローバル カタログ サーバーではない第 2 のドメイン コントローラに移動させました。

Resource Kit Corporation の本社は Seattle にあり、主な支社は Boston および Vancouver, B.C にあります。これらのオフィスは非常に緊密に連携しています。また、これらのオフィスの責任者グループは、各オフィスのネットワーク管理作業を単一のドメイン構造内の組織単位を通して委任することを考えています。したがってこれらのオフィスは、単一のドメイン (noam.reskit.com) 内に編成されています。

Resource Kit Corporation のMilan 支社は、北米のオフィスと緊密に連携し、reskit.comフォレストのメンバとして同じスキーマ、構成、およびグローバル カタログを共有するメリットを得ることができます。しかし Resource Kit Corporation では、以下の理由のためにMilan 用の個別のドメイン (eu.reskit.com) を作成することに決定しました。

  • 単一のドメインには Domain Admins グループが存在します。このグループのメンバは、すべてのドメイン オブジェクトに対して完全な管理権限を持ちます。Resource Kit Corporation では、あるオフィスの管理者がオフィスの権限を異なる場所の管理者に委任することを望みません。

    注意
    Windows NT 4.0 の場合、オブジェクトのサブカテゴリに対する管理の自律性を実現するには、新しいドメインを作成することが必要です。Windows 2000 では、管理権限の委任の統制についての最善の慣行に従えば、Domain Admins グループのメンバを制限して、すべてのドメイン ディレクトリ オブジェクトに関する管理を委任する権限を持つ選別された少数のユーザーのみをこのグループに含め、組織単位を使用してオブジェクトのサブカテゴリに対する権限を委任します。しかしこのシナリオでは、支社においてこの方法による権限の委任が文化的、政治的な理由のために望ましくないモデルのためのソリューションを示すことを意図しています。

  • ある場所のディレクトリ情報が別の場所のユーザーに役立つことはほとんどないため、異なる場所間、特に大陸間の高価な WAN リンクを経由してオブジェクトを複製することは経済的ではありません。

したがって Resource Kit Corporation では、reskit.com フォレスト内のフォレスト ルート ドメインの下に北米のドメイン (noam.reskit.com) およびヨーロッパのドメイン (eu.reskit.com) の 2 つの子ドメインを作成しました。同じフォレスト内のドメイン間では双方向の推移性の信頼関係 (図中で双方向の矢印によって示されています) が自動的に確立されるので 、あるドメインのメンバが、フォレスト内の任意のドメインにおいてリソースへのアクセスを承認されていれば、そのリソースにアクセスできます。また、同じグローバル カタログを検索することが可能です。

図 3 は、単一のルート ドメインと、2 つの子ドメインを有する reskit.com ツリーを示しています。

domain01-03

図 3: Reskit.com ツリー

Resource Kit Corporation の Avionics 部門では、航空宇宙産業向けの製品を製造しており、機密扱いの連邦政府契約書や文書を扱っています。このような処理を行うには、フォレスト内のほかのオフィスからのさまざまなドメイン セキュリティ ポリシー (パスワードや、セッション チケットの有効期間に関する Kerberos ポリシー、アカウント ロックアウトに対するより厳しい制限など) 、そしてユーザーとリソースを管理するための独立した IT 組織が必要です。次の理由のために、Avionics 部門のための個別のドメイン avionics01-int.com を、新しいドメイン ツリー内に作成します。

  • Avionics 部門には歴史的に、元の企業の DNS 名 avionics01-int.com を保持する必要性があります。したがって、このドメインを reskit.com の子ドメインとして作成することはできません。

  • Avionics 部門では、証明書階層を必要とする証明機関 (CA) を使用しています。この証明機関では、Netscape ルート CA を使用し、Windows 2000 スマート カード ネットワーク ログオン処理をサポートするためにスマートカードとスマートカード読み取り装置を導入しています。

図 4 は、2 つのドメイン ツリーを有する reskit.com フォレストを示しています。avionics01-int.com ツリー ルート ドメインは、フォレスト ルート ドメイン reskit.com に対して推移性を有する双方向の自動的な信頼関係を持ちます。

domain01-04

図 4: 2 つのツリーから構成されるフォレスト

Resource Kit Corporation では、地域の相違に対応するとともに、大西洋を横断してドメインデータを複製するのを回避するために、Seville にある Avionics のヨーロッパ支社を管理するドメイン seville.avionics01-int.com を個別に作成します。この子ドメインは、その親ドメイン avionics01-int.com に対して推移性を有する双方向の信頼関係を持ちます。

図 5 は、2 つのツリーと複数の子ドメインを有する Windows 2000 Resource Kit Corporation フォレスト全体を示しています。

domain01-05

図 5: reskit.com フォレスト全体

明示的な信頼関係の構築

ドメイン eu.reskit.com および seville.avionics01-int.com は同じフォレスト内にあるので、すべての親ドメインと子ドメイン間、同じフォレスト内のすべてのツリー ルート ドメイン間に存在する双方向の推移性を有する自動的な信頼関係を通してリソースを共有できます。しかし、ヨーロッパのいずれかの場所にいるユーザーが相手側のドメインで認証されるには、信頼パスが大西洋と北米大陸を横断し、Seattle の avionics01-int.com ドメイン コントローラに達した後、再び同じ経路を戻る必要があります。したがって Resource Kit Corporation は、これら 2 つのドメイン間でリソースの交換を容易にするために、ショートカット信頼関係と呼ばれる 2 つの明示的な信頼関係を作成しています。この信頼関係は、2 つの子ドメイン間で一方向ごとに手動で作成します (図 6 を参照) 。

domain01-06

図 6: リソースへのアクセスを向上させるための短い信頼パス

Resource Kit Corporation のサポートセンターは Atlanta にあります。Atlanta 支社は、この時点でドメイン コントローラを Windows NT 4.0 から Windows 2000 に移行していないので、Windows 2000 reskit.com フォレストには含まれません。この理由のために、Atlanta オフィスは既存の Windows NT 4.0 ディレクトリ構造を維持していて、依然として企業の Windows 2000 フォレスト インフラストラクチャの外部にあるドメインとして管理されています。

Seattle の Atlanta オフィスと Resource Kit Corporation 本社の間でリソース共有を容易に行うために、Atlanta の Windows NT 4.0 ベースのプライマリ ドメイン コントローラと、Seattle にある noam.reskit.com ドメインの Windows 2000 ベース ドメイン コントローラ間で一方向ごとに手動で外部信頼関係を作成します。この 2 つの一方向の明示的な信頼関係によって、Atlanta のユーザーが noam.reskit.com 内のリソースを使用するための認証を受けることができ、Seattle、Boston、Vancouver にいる noam.reskit.com ドメインのユーザーが Atlanta のリソースを使用するための認証を受けることができます。図 7 は、reskit.com フォレスト ドメイン インフラストラクチャと、Resource Kit Corporation の外部の Windows NT 4.0 ドメインの関係を示しています。

domain01-07

図 7: Reskit.com フォレストと Windows NT 4.0 ドメイン

Resource Kit Corporation では、acquired01-int.com フォレストのオフィスと、reskit.com フォレスト内の noam.reskit.com ドメインのオフィス間でリソースにアクセスすることが必要なため、noam.reskit.com ドメインと acquired01-int.com ドメイン間で 2 つの明示的な一方向の外部信頼関係を手動で作成します。各ドメインのユーザーを、別のフォレストで対応する権限を有する特定のグローバル グループに追加できます。その後、適切な外部信頼関係が存在する構成で、このグローバル グループをそれぞれのドメインのドメイン ローカル グループに追加できます。このドメイン ローカル グループには、外部ユーザーによって使用されるリソースに対する適切なアクセス許可が与えられています。

あるドメインから個々のユーザーを別のドメインのドメイン ローカル グループに追加することもできますが、信頼する側のドメインのリソースへのアクセス手段として、個々のユーザー アカウントではなく、グローバル グループを使用することによって、管理作業を単純化できます。

注意
アクセス許可を割り当てる場合、最善の慣行に従えば、個々のユーザーではなく、常にグループにアクセス許可を割り当てます。

図 8 は、2 つのフォレスト間でリソースを共有することを可能にする信頼関係を示しています。

domain01-08

図 8: 2 つのフォレストのドメイン間の外部信頼関係

その他の参考資料

導入実験のシナリオ

Windows 2000 リソース キット
以下は、『Microsoft Windows 2000 Professional リソース キット』および『Microsoft Windows 2000 Server リソース キット』の参考資料です。オンラインで概要を参照できる章もあります。

  • フォレスト、ドメイン、組織単位の計画の詳細については、『Microsoft Windows 2000 Server リソース キット 1 導入ガイド』の「第 9 章 Active Directory 構造の設計 () 」 (英語) を参照してください。

  • ドメイン、ドメイン ツリー、フォレスト、DNS 名の割り当てについては、『Microsoft Windows 2000 Server リソース キット 3 分散システムガイド 上』の「第 1 章 Active Directory の論理構造」を参照してください。

  • Windows NT 4.0 ドメインの Active Directory への移行については、『Microsoft Windows 2000 Server リソース キット 1 導入ガイド』の「第 10 章 ドメイン移行計画の確定 () 」 (英語) を参照してください。

  • グローバル カタログ サーバーについては、『Microsoft Windows 2000 Server リソース キット 3 分散システムガイド 上』の「第 1 章 Active Directory の論理構造」を参照してください。

  • 信頼関係については、『Microsoft Windows 2000 Server リソース キット 3 分散システムガイド 上』の「第 1 章 Active Directory の論理構造」を参照してください。

  • 認証については、『Microsoft Windows 2000 Server リソース キット 3 分散システムガイド 上』の「第 11 章 認証」を参照してください。

  • リソースへのアクセスの保護については、『Microsoft Windows 2000 Server リソース キット 3 分散システムガイド 上』の「第 12 章 アクセス制御」を参照してください。

  • 証明機関については、『Microsoft Windows 2000 Server リソース キット 3 分散システムガイド 上』の「第 13 章 公開キー技術を使ったセキュリティソリューションの選択」と「第 14 章 暗号化によるネットワークと情報のセキュリティ」を参照してください。

  • DNS について詳しくは、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 6 章 Windows 2000 DNS () 」 (英語) を参照してください。

  • Flexible Single-Master Operations については、『Microsoft Windows 2000 Server リソース キット 3 分散システムガイド 上』の「第7章 FSMO (Flexible Single Master Operations) の管理」を参照してください。

Active Directory – 関連ツール

  • Windows の以前のバージョンから Active Directory にアップグレードする際に役立つ Active Directory 移行ツールについては、『Active Directory 移行ツール概要』を参照してください。

  • ディレクトリを収容するために必要なハードウェアを特定する際に役立つ Active Directory サイズ予測ツールについては、『Windows 2000 Active Directory Sizer Tool』 (英語) を参照してください。

Windows 2000 オンライン ドキュメント

  • Active Directory の詳細については、Windows 2000 Server ヘルプ の「Active Directory」の「概念」の「Active Directoryの概要」の「Active Directory について」および、「Active Directory」の「概念」の「Active Directory について」を参照してください。

  • Active Directory の用語については、『Active Directory 用語集』を参照してください。

  • Windows 2000 の導入については、『Planning and Deployment』 (英語) を参照してください。

  • Windows 2000 インフラストラクチャの詳細については、『Step-by-Step Guides』 (英語) を参照してください。

Microsoft Press

導入実験の詳細と協力企業について

リソース キット導入実験シナリオの凡例

  • Microsoft Windows 2000 リソース キット導入実験シナリオのネットワーク図で使用されている略語や記号について詳しくは、『導入実験シナリオの凡例』を参照してください。

リソース キット導入実験のネットワーク図

  • ネットワークの設計、ネットワーク ルーティング設計、ドメイン ネーム システム (DNS) 設計、および Active Directory 階層の高水準の編成については、『導入実験のネットワーク図』を参照してください。

関連資料

注意
このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして紹介したものです。実際のネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、目的とする機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になる、その他の手順については取り上げていません。すべてのシナリオは、特に表記しない限り Windows 2000 を使用してテストされています。また、ブラウザとして Microsoft Internet Explorer 5 以上を推奨します。