Windows 2000 システム展開ガイド

第 9 章 ‐ Active Directory 構造の設計

Microsoft® Windows® 2000 Server (以下 Windows 2000 Server) には、Active Directory™ と呼ばれるディレクトリ サービスが含まれています。この章で説明する Active Directory の概念、アーキテクチャ要素、および機能を理解することで、IT 部門のスタッフは Microsoft® Windows® 2000 (以下 Windows 2000) Active Directory の展開に不可欠な設計書を作成できます。

この章を読む前に、自社の IT 管理グループ、管理階層、およびネットワーク トポロジについて確認しておいてください。社内の現状を正確に理解していれば、この章の計画ガイドラインを実施に移すときに役立ちます。

トピック

Active Directory の概要
Active Directory を計画する
フォレスト計画を作成する
ドメイン計画を作成する
組織単位計画を作成する
サイト トポロジ計画を作成する
Active Directory 構造を設計するための作業リストを計画する

この章の目的
この章では、次の計画書の作成方法について説明します。

  • フォレスト計画

  • 各フォレストのドメイン計画

  • 各ドメインの組織単位 (OU) 計画

  • 各フォレストのサイト トポロジ計画

Resource Kit の関連情報

  • ドメインを Windows 2000 に移行する方法については、このマニュアルの「第 10 章 ドメイン移行方針の決定」を参照してください。

  • Kerberos プロトコルなど Windows 2000 のセキュリティ規格の詳細については、このマニュアルの「第 11 章 分散セキュリティ計画の作成」を参照してください。

  • アドバンスト ネットワーキングの詳細については、このマニュアルの「第 7 章 ネットワーク接続方針の決定」を参照してください。

  • Microsoft® IntelliMirror・(以下 IntelliMirror) またはグループ ポリシーの詳細については、このマニュアルの「第 24 章 変更管理と設定管理」を参照してください。

  • Active Directory の技術的な詳細については、『Microsoft® Windows® 2000 Server Resource Kit』の分冊、『Distributed Systems Guide』を参照してください。

  • ドメイン ネーム システム (DNS) の詳細については、『Microsoft® Windows® 2000 Server Resource Kit』の分冊、『TCP/IP Core Networking Guide』の「Introduction to DNS」および「Windows 2000 DNS」を参照してください。

Active Directory の概要

Active Directory は、分散セキュリティのバックボーンであると共に、サービス公開のフレームワークとしても位置付けられるなど、多くの役割を果たします。Active Directory は、管理者がネットワーク リソースを体系化し、ユーザー、コンピュータ、およびアプリケーションを管理し、イントラネットおよびインターネット アクセスのセキュリティを確保する上で中心となるサービスです。

Active Directory を利用する分散アプリケーションが増えれば、アプリケーション特有のディレクトリ サービスを実装および管理せずに済むため、管理コストおよびハードウェア コストを節約できます。

メモ : Windows 2000 Server および Microsoft® Windows® 2000 Professional (以下 Windows 2000 Professional) と、Active Directory を展開する順番には特に決まりはありません。Active Directory を先に展開することも、一緒に展開することも、後で展開することもできます。Active Directory を先に導入しなければならないというわけではありません。メンバ サーバーおよびクライアント コンピュータをアップグレードすると、Windows 2000 の数多くの新機能を利用できます。メンバ サーバーのアップグレードの詳細については、このマニュアルの「第 15 章 メンバ サーバーのアップグレードとインストール」を参照してください。

Active Directory の主な機能

Windows 2000 Active Directory の機能によって、ネットワークに次のような多くの利点がもたらされます。

セキュリティ
Active Directory は、新しいセキュリティ機能に必要なインフラストラクチャを提供します。相互認証を使用すると、クライアントはサーバーの ID を確認してから機密データを送ることができるようになります。また、セキュリティ対策として公開キーをサポートすることにより、ユーザーは、パスワードの代わりにスマート カードを使用してログインできます。

簡単で柔軟な管理
Active Directory のオブジェクトは属性ごとにアクセス権を設定でき、管理権限をきめ細かく委任できます。管理権限を委任すると、社内の管理責任を効率的に分散させ、ドメイン全体を管理しなければならないユーザーの数を減らすことができます。

スケーラビリティ
Active Directory は、ロケータ メカニズムとしてドメイン ネーム システム (DNS) を使用します。DNS は、階層型、分散型でスケーラビリティの高いインターネット用のネームスペースであり、コンピュータ名およびサービス名を伝送制御プロトコル/インターネット プロトコル (TCP/IP) アドレスに変換します。

Active Directory は、ドメインに基づいて情報を格納します。ドメインは、通信速度と信頼性が時々刻々と変わる大規模ネットワークにおいて、ディレクトリを分散させるためのパーティションといえます。Active Directory は、データベース テクノロジをサポートしており、数百万単位のオブジェクト (ユーザー、グループ、コンピュータ、共有ファイル フォルダ、プリンタなど) を格納できることが実証されています。スケーラブルなロケータ、パーティション、およびスケーラブルなストレージを組み合わせることにより、会社の規模拡大に応じてディレクトリの規模を柔軟に拡大できます。

高い可用性
シングル マスタ レプリケーションを実行する従来のディレクトリは、照会に対しては高い可用性を示しますが、更新に対しては操作の可用性は高くありません。Active Directory はマルチ マスタ レプリケーションを実行するため、照会と更新の両方で高い可用性を示します。

拡張性
スキーマ (ディレクトリ サービスに使用できるオブジェクト クラスの定義) は拡張可能です。管理者および開発者は、各自のニーズに合わせてディレクトリを調整できます。

オープン規格のサポート
Active Directory は、次のような標準プロトコルに基づいて作成されています。

  • DNS : Active Directory を実行しているサーバーの検索に使用

  • ライトウェイト ディレクトリ アクセス プロトコル (LDAP) : 照会と更新に使用

  • Kerberos プロトコル : ログオンと認証に使用

これらのオープン規格をサポートしているため、Active Directory では LDAP ベースのアドレス ブックなど、各種クライアント ソフトウェアを使用できます。

プログラムによる簡単なアクセス
Active Directory サービス インターフェイス (ADSI) は、Visual Basic Script などのスクリプト言語を始めとするさまざまなプログラミング プラットフォームからアクセスできます。ADSI を使用すると、管理者およびソフトウェア開発者は、強力なディレクトリ対応アプリケーションを短時間で作成できます。ディレクトリ対応アプリケーションの例としては、ディレクトリからデータまたは構成情報を読み取るアプリケーションが挙げられます。

新しいテクノロジの基盤を提供する

上記の基本的な利点のほか、Active Directory は、Windows 2000 の展開において、次のような新しいテクノロジおよび機能をサポートするうえで重要な役割を果たします。

IntelliMirror
Windows 2000 には、さまざまな変更および設定管理テクノロジが追加されています。IntelliMirror およびリモート OS インストール機能は、クライアントの管理とサポートに関連する作業およびコストの削減に役立ちます。これらのテクノロジの実装の詳細については、このマニュアルの「第 24 章 変更管理と設定管理」および「第 23 章 クライアントの管理標準や設定標準の決定」を参照してください。

ディレクトリの統合
Active Directory はスケーラビリティと拡張性に優れているため、個別のディレクトリを使用するネットワーク上のアプリケーションにとって、理想的なディレクトリの統合を実現できます。たとえば、次のような統合が可能です。

  • ディレクトリを完全に統合することにより、Microsoft® Exchange Server (以下 Exchange Server) などの製品がディレクトリ コンポーネントに依存せずに、Active Directory だけで管理および動作できます。

  • 管理を統合することにより、ディレクトリ情報を Active Directory で管理し、ディレクトリ同期を使用してリモート ディレクトリを最新の状態に維持できます。

  • 既存の Microsoft® Windows NT® (以下 Windows NT) のドメインを統合することにより、管理対象となるネットワーク上のオブジェクトおよびハードウェアの総数を削減できます。

アドバンスト ネッ トワーキング
Active Directory で可能になるアドバンスト ネットワーキング機能には、たとえば、インターネット プロトコル セキュリティ (IPSec)、ネットワーキングの Quality of Service 機能、新しいリモート アクセス機能などがあります。

Active Directory を計画する

全社規模の Active Directory の展開を計画する場合は、社内のネットワーク インフラストラクチャの重要な部分を定義します。この計画では、社内組織を忠実に反映した構造セットを作成します。作成する構造によって、次の項目が決まります。

  • ディレクトリの可用性および耐障害性

  • ディレクトリ クライアントおよびサーバーのネットワーク使用特性

  • ディレクトリ内容の管理効率

  • ユーザーによるディレクトリの参照およびインタラクティブ操作の方法

  • ディレクトリ構造の柔軟性 (拡大する企業規模への対応)

Active Directory のコスト効率の優れた展開を行うには、綿密な Active Directory の計画が不可欠となり、計画段階で時間を十分にかければ、既に運用中のネットワーク構造を将来、再構築する際、時間とコストを節約できます。

ディレクトリ構造計画を作成するには、この章で説明する手順に従います。計画の作成中に、次のことを行います。

  • 構造計画に影響を与える Active Directory の主な概念を習得し、自社の実情に合わせて計画手順を調整します。

  • 構造計画に関わる人員を決定します。

  • Active Directory を最も効率的に活用するためには、現在のビジネスのやり方をどう変更または発展させればよいかを理解します。

  • 作成する構造の柔軟性を理解し、将来的に変更が容易または困難な選択肢はどれかを認識します。

図 9.1 に、Active Directory の構造を設計するための基本的な手順を示します。この章では、それぞれの手順を詳しく説明します。

Dd143060.sdgch901s(ja-jp,TechNet.10).gif

図 9.1: Active Directory 構造の設計プロセス

拡大表示する

設計の一般原則

Active Directory を計画するときには、意思決定の指針として、次の設計原則を適用します。

簡潔性を追求する
構造が簡潔なほど、説明、メンテナンス、およびデバッグが簡単になります。複雑にすることで価値を付加することもできますが、追加する価値と将来発生する可能性のあるメンテナンス コストを比較、検討するひつようがあります。たとえば、照会と複製のトラフィックを最適化すると、サイト トポロジが複雑になることがあります。しかし、トポロジが複雑になるほどメンテナンスは困難になります。複雑な構造を採用する前に、付加する機能とそれにともない発生する複雑さを秤にかけ、損得を評価してください。

何かを作成すれば、そのライフタイムにおいて、必ず何らかのメンテナンスが必要になります。明確な理由がないまま構造を作成すると、付加する価値以上のコストが長期的に発生します。正当な理由があることを確認したうえで構造を作成してください。

ビジネスと企業は常に変化する
人事異動や全社レベルの組織変更、買収など、日常的な企業の変化は Active Directory の構造にも影響を及ぼします。構造を設計するときには、このような潜在的な変更が、エンド ユーザーおよび管理者とディレクトリ間のインタラクティブ操作にどのように影響するかを考慮してください。たとえば、最近実施された大きな組織変更が、現在の構造にどのような影響を与えたかを参考にするとよいでしょう。組織に新しいロケーションまたは支社が追加された場合に、どのような変更が必要か、また、その変更によって、Active Directory の構造に大きなコストがかかるかを考えてください。定期的な変更や大きな変更にも柔軟に適応できるよう、汎用的な構造を設計してください。

理想的な設計を目標に
設計の初期段階では、理想と思える構造を設計してください。それが、現在のドメインまたはディレクトリ インフラストラクチャを反映していなくてもかまいません。現時点で達成できなくても、何が理想的かを理解することは、今後の設計プロセスに役立ちます。ネットワークの最適な計画への移行に関わるコストの詳細については、このマニュアルの「第 10 章 ドメイン移行方針の決定」を参照してください。移行に伴うコストと理想的な計画による長期的な節約を比較および検討し、設計を適切に具体化してください。

複数の設計案を考える
1 つの設計に複数の案を作成してください。設計の価値は、他の設計案と比較することでさらに明確になります。計画を実施に移す場合は、その中で最適の設計を採用してください。

Active Directory の構造計画を作成する

Active Directory の構造は、フォレスト、ドメイン、組織単位、およびサイトの 4 つの基本コンポーネントで構成されます。Active Directory の構造計画では、各コンポーネントの計画書を作成し、その過程で重要な意思決定を下し、その正当性を証明します。作成する計画書は、次の計画作業である移行の出発点になります。Active Directory 構造計画は、次の 4 つの計画書で構成されます。

  • フォレスト計画

  • 各フォレストのドメイン計画

  • 各ドメインの組織単位 (OU) 計画

  • 各フォレストのサイト トポロジ計画

フォレスト計画を作成する

フォレストとは、Active Directory ドメインの集合を指します。フォレストは、主に、ユーザーとディレクトリ間のインタラクティブ操作の簡素化、および複数のドメイン管理の簡素化という 2 つの目的を果たします。フォレストには、主に次のような特性があります。

単一のスキーマ
Active Directory スキーマは、ディレクトリ内に作成できるオブジェクト クラスおよびオブジェクト クラスの属性を定義します。オブジェクト クラスは、ディレクトリ内に作成できるオブジェクトのタイプを定義します。スキーマは、フォレスト内のすべてのドメイン コントローラにレプリケートされる名前付けコンテキストとして存在します。スキーマ管理者セキュリティ グループには、スキーマに対するフル コントロールが与えられます。

単一の 設定コンテナ
Active Directory の設定コンテナは、フォレスト内のすべてのドメイン コントローラに対して複製される名前付けコンテキストです。ディレクトリ対応アプリケーションは、フォレスト全体に適用される設定コンテナに情報を格納します。たとえば、Active Directory は、物理ネットワークの情報を設定コンテナに格納し、ドメイン コントローラ間の複製経路の作成ガイドとして使用します。エンタープライズ管理者のセキュリティ グループには、設定コンテナに対するフル コントロールが与えられます。

フォレストのすべてのドメインで同一の設定を共有することで、ドメインを個々に設定する必要がなくなります。

完全な信頼関係
Active Directory は、フォレスト内のドメイン間に双方向の信頼関係を自動的に作成します。任意のドメインのユーザーおよびグループは、フォレスト内の任意のメンバー コンピュータで認識され、グループおよびアクセス制御リスト (ACL) に組み込まれます。

Windows 2000 では、完全な信頼関係により、複数のドメインの管理が簡単になっています。以前のバージョンの Windows NT では、ドメインを配置する一般的なモデルは、複数マスタ ドメイン モデルでした。このモデルでは、主にユーザー アカウントを保持するドメインをマスタ ユーザー ドメインと呼び、主にコンピュータ アカウントおよびリソースを保持するドメインをリソース ドメインと呼んでいました。一般的な展開は、少数のマスタ ユーザー ドメインで構成され、それぞれのドメインが多くのリソース ドメインに信頼されていました。この環境に新しいドメインを追加するには、信頼関係を設定する必要がありました。Windows 2000 Active Directory では、ドメインをフォレストに追加すると双方向の信頼関係が自動的に設定されるため、同じフォレスト内のドメインに信頼関係を作成する必要がありません。

単一のグローバル カタログ
各オブジェクトの選択された属性セットだけを除いたグローバル カタログには、フォレスト内の全ドメインの全オブジェクトのコピーが格納されます。このグローバル カタログによって、フォレスト全体にわたる高速で効率の良い検索が可能になりました。

グローバル カタログにより、フォレスト内のディレクトリ構造がエンド ユーザーに対して透過的になります。検索スコープとしてグローバル カタログを使用すると、ディレクトリ内のオブジェクトを簡単に検索できます。また、グローバル カタログおよび次に説明するユーザー プリンシパル名により、ログオンも簡単になります。

ユーザーによるグローバル カタログの検索 : ディレクトリ検索ユーザー インターフェイスで検索スコープとしてグローバル カタログを選択すると、グローバル カタログはディレクトリ全体として抽象化されるため、ユーザーは、フォレスト構造の知識を持っていなくても、フォレストを検索できます。単一の検索インターフェイスの採用により、ディレクトリ構造に関する特別なトレーニングをユーザーに施す必要が減り、管理者は、ユーザーとディレクトリの間のインタラクティブ操作に影響を与えずに、フォレスト内の構造を変更できます。

ユーザーによるユーザー プリンシパル名を使用したログオン : ユーザー プリンシパル名 (UPN) は、一意のユーザーを表す名前で、その書式は電子メール アドレスに似ています。UPN は、ユーザー識別部分とドメイン部分の 2 つの要素で構成されます。2 つの要素は <user>@<DNS-domain-name> というように、"@" 記号で区切ります (例 : liz@noam.reskit.com)。すべてのユーザーには、自動的に既定の UPN が割り当てられ、<user> にはユーザーのログオン名と同じ名前、<DNS-domain-name> にはユーザー アカウントが配置されている Active Directory ドメインの DNS 名が使用されます。UPN を使用してログオンすると、ユーザーは、ログオン ダイアログ ボックスのリストからドメインを選択しなくて済みます。

UPN には任意の値を設定できます。たとえば、Liz のアカウントが noam.reskit.com ドメインにある場合でも、UPN を liz@reskit.com にすることができます。ユーザーがログオンすると、検査対象のユーザー アカウントがグローバル カタログで検索され、一致する UPN 値のユーザー アカウントが検出されます。ドメイン名とは無関係の UPN 値を設定し、ユーザー アカウントをドメイン間で移動させることもできます。この際に UPN 値を変更する必要はありません。ドメイン間の移動は、ユーザーにとっては透過的に行われます。

フォレストの計画プロセス

企業のフォレスト計画を作成するための基本的な手順は、次のとおりです。

  • ネットワークのフォレスト数を決定します。

  • フォレストの変更制御ポリシーを作成します。

  • 展開後にフォレスト計画を変更した場合の影響を理解します。

フォレスト計画を作成する際は、必要に応じて、以下のスタッフに相談してください。

  • ユーザー アカウント、グループ、およびコンピュータを担当する現在のドメインの管理者

  • ネットワーク セキュリティ チーム

ネットワークのフォレスト数を決定する

フォレスト モデルを計画するときには、まず単一のフォレストから始めます。ほとんどの場合、単一のフォレストで十分です。フォレストを追加作成する場合は、技術的に正当な理由があることを確認してください。

単一フォレスト環境を作成する
単一フォレスト環境は、作成およびメンテナンスが簡単です。すべてのユーザーはグローバル カタログを通じて単一のディレクトリを参照できます。また、ディレクトリ構造を意識せずに済みます。フォレストに新しいドメインを追加するときも、信頼関係を追加、設定する必要はありません。設定の変更は 1 度適用すれば、すべてのドメインに反映されます。

複数フォレスト環境を作成する
ネットワークの管理が多数の独立部門に分散している場合、複数のフォレストを作成しなければならないことがあります。

フォレストは、スキーマなどの共有要素を持つため、フォレストへのすべての参加者が共有要素の内容および管理に同意することが必要です。提携企業や複合企業などの企業では、このプロセスを進める中心組織がないことがあります。ジョイント ベンチャーなどの短期的な企業では、各企業の管理者にフォレストの共同管理を期待するのは現実的でないかもしれません。

複数のフォレストを作成しなければならない可能性があるのは、次のような企業です。

相互の管理者を信頼しない : グローバル カタログには、フォレスト内のすべてのオブジェクトが表現されています。オブジェクトの作成権限を委任された管理者は、意図的または無意識に "サービス拒否" 状態を作ることができます。この状態は、次々にオブジェクトを作成または削除して、大容量の複製をグローバル カタログに発生させることで実現できます。複製が多過ぎると、ネットワーク帯域幅が浪費されるため、グローバル カタログ サーバーは複製の処理に時間を取られ、低速になります。

フォレスト変更ポリシーに同意できない : スキーマの変更、構成の変更、およびフォレストへの新しいドメインの追加は、フォレスト全体に影響を与えます。フォレスト内の各組織がこれらの変更プロセスおよびスキーマ管理者グループとエンタープライズ管理者グループのメンバーシップに同意していなければなりません。共通のポリシーに同意できない組織は、同じフォレストを共有できません。フォレスト変更ポリシーの作成については、後で説明します。

信頼関係のスコープを制限したい : フォレストのすべてのドメインは、そのフォレスト内のその他すべてのドメインを信頼します。また、フォレスト内のユーザーは、グループ メンバーシップに含めることも、フォレスト内の任意のコンピュータのアクセス制御リストに含めることもできます。特定のリソースに対する権限をユーザーに与えたくない場合は、それらのユーザーをリソースと別のフォレストに入れなければなりません。ドメイン内の特定のリソースへのアクセス権をユーザーに与えるであれば、必要に応じて明示的な信頼関係を使用してください。

フォレストの追加にかかるコスト
フォレストを作成するたびに、次のような一定の管理オーバーヘッドが発生します。

  • 追加するフォレストには、少なくとも 1 つのドメインが必要です。つまり、最初に計画したドメインより多くのドメインが必要になることがあります。ドメインの作成およびメンテナンスには、一定のコストが伴います。これらのコストの詳細については、後で説明します。

  • 追加するフォレストが既存のフォレストと基本的に同じでも、スキーマ、設定コンテナ要素、関連付けられている管理グループ メンバーシップなどのコンポーネントを追加したフォレストの分だけ余計に管理しなければなりません。

特定のフォレストのユーザーが別のフォレストのリソースを使用できるようにするには、次のような追加構成が必要です。

  • 特定のフォレストのユーザーが別のフォレストのリソースにアクセスできるようにするには、2 つのドメイン間に明示的な信頼関係を作成し、維持しなければなりません。異なるフォレストのドメイン間の明示的な信頼関係は単方向性のものであり、過渡的なものではありません。信頼関係が確立されていないと、ユーザーは自分のフォレストとは別のフォレストのオブジェクトにはアクセスできません。

    既定では、ユーザーは自分のフォレストのグローバル カタログにあるオブジェクトしか認識できません。別のフォレストのオブジェクトを発見するには、ユーザーのフォレスト外にあるドメインを明示的に照会する必要があります。または、管理者が、他のドメインのデータをユーザーのフォレストにインポートすることもできます。しかし、これには次の理由でコストがかかります。

    • ユーザーは、グローバル カタログの照会に失敗したときに照会先を特定できるよう、ディレクトリ構造を理解していなければなりません。そのためのトレーニングが必要です。

    • 別のフォレストのドメインからデータをインポートした場合、ソース ドメインのデータへの変更に応じてインポート先のデータを同期化しなければなりません。

ユーザーが自分のフォレストとは別のフォレストで公開されているリソースにアクセスする必要がある場合のフォレスト間の設定例を 図 9.2 に示します。単方向の信頼関係が明示的に作成されているため、リソースに対するアクセス権をユーザーに与えることができます。ディレクトリ内のリソース表現はユーザーのフォレストにインポートされ、グローバル カタログに組み込まれます。

sdgch902

図 9.2: 別フォレストのリソースへのアクセスに必要な追加設定

次の機能は、1 つのフォレスト内では使用できても、複数のフォレスト間では使用できません。

  • ユーザー アカウントが、ログインに使用されるコンピュータと異なるフォレストにある場合、使用できるのは既定の UPN だけです。既定の UPN が必要なのは、コンピュータのフォレストにあるドメイン コントローラが、一致した UPN のユーザー アカウントをグローバル カタログで見つけられないためです。このユーザー アカウントは、別のフォレストのグローバル カタログに現れます。そのため、ログオンを処理するドメイン コントローラは、UPN の <DNS-domain-name> 部分を使用して、ユーザーの ID の確認のためにドメイン コントローラを見つけようとします。

  • スマート カードを使用したログオンは、ユーザー プリンシパル名に依存します。スマート カードを使用したフォレスト間のログオン プロセスを機能させるには、既定の UPN を使用しなければなりません。

  • 同じフォレスト内であれば、ドメイン間でセキュリティ プリンシパルを移動できますが、フォレストが異なるドメイン間では、クローンを作成しなければなりません。クローンの作成は、ユーザーをドメイン間で移動する場合ほど、エンド ユーザーに対して透過的ではありません。クローンの作成の詳細については、このマニュアルの「第 10 章 ドメイン移行方針の決定」を参照してください。

必要なフォレスト数を決定するときには、ユーザーにとって重要なことと、管理者にとって重要なことが、必ずしも一致しないことを忘れないでください。ただし、フォレストを複数作成すると、ユーザーにとって重要なことがほとんど失われてしまう可能性があります。たとえば、企業が、ネットワーク管理を異なる複数の請負業者にアウトソーシングした場合について考えてみます。請負業者は、一般にネットワーク パフォーマンスに基づいて料金を受け取り、安定したネットワークの維持に最大の責任が置かれます。ある請負業者が、自社が受け持つコンピュータに別の請負業者の影響が及ばないようにするには、別のフォレストを作成すれば解決できます。この場合、ユーザーが単一の一貫したビューでディレクトリを見られなくなるという欠点があります。このため、このような状況では、別のフォレストを作成することで、管理側の問題を解決しようとしないでください。

どのユーザーにも一貫したビューでディレクトリを見ることが重要でない場合には、複数のフォレストを使用するのが適切なことがあります。たとえば、複数の会社に代わって Active Directory を運用するインターネット サービス プロバイダ (ISP) などの会社について考えてみます。異なる顧客会社のユーザーが一貫したディレクトリ ビューを共有しなければならない理由はありません。また、会社間で信頼関係を過渡的に作成する必要もありません。この場合は、別々のフォレストを維持するのが好都合で適切です。

フォレスト変更制御ポリシーを作成する

作成するフォレストごとに、フォレスト計画書の一部としてフォレスト変更制御ポリシーを作成する必要があります。このポリシーは、フォレスト全体に影響する変更のガイドとして使用します。先に進む前に、個々のプロセスを決定する必要はありませんが、その所有権を理解しておくことが重要です。ポリシーには、フォレスト内の個々の共有要素に関する情報を定義してください。

スキーマ変更ポリシー
スキーマ管理者グループは、フォレストのスキーマに対するフル コントロールを保持します。スキーマ変更ポリシーには、次の内容が必要です。

  • スキーマ管理者グループを監督する社内のチーム名

  • スキーマ管理者グループの最初のメンバーシップ

  • スキーマの変更を要求および評価するガイドラインとプロセス

Active Directory スキーマの詳細については、『Microsoft® Windows® 2000 Server Resource Kit』の分冊の『Distributed Systems Guide』を参照してください。

設定変更ポリシー
エンタープライズ管理者グループは、フォレスト全体に複製される設定コンテナに対するフル コントロールを保持します。設定変更ポリシーには、次の内容が必要です。

  • エンタープライズ管理者グループを監督する社内のチーム名

  • エンタープライズ管理者グループの最初のメンバーシップ

  • フォレストに新しいドメインを作成するためのガイドラインとプロセス

  • フォレスト サイト トポロジを修正するためのガイドラインとトポロジ (サイト トポロジについては、後出の「サイト トポロジ計画を作成する」で説明)

展開後にフォレスト計画を変更する

作成したドメインは、既存のフォレストに加えることができます。ドメインは、Windows 2000 ベースのサーバーを Active Directory のドメイン コントローラに昇格させるか、Microsoft® Windows NT® version 3.51 (以下 Windows NT 3.51) または Microsoft® Windows NT® version 4.0 (以下 Windows NT 4.0) のプライマリ ドメイン コントローラを Windows 2000 にアップグレードすることにより作成できます。

 

sdgch903

意思決定の重要ポイント : 2 つのフォレストをマージするのも、ドメインをフォレスト間で移動するのも簡単なことではありません。組織の規模が拡大しても最小限の再構成で済むよう、フォレスト計画を設計することが重要です。

個々のオブジェクトは、フォレスト間で移動できます。移動するオブジェクトのタイプによって、移動に使用するツールが決まります。バルク インポートおよびエクスポートのほとんどは、LDAP データ交換フォーマット (LDIFDE.EXE) コマンドライン ツールで実行でき、セキュリティ プリンシパルのクローン作成は、ClonePrincipal ツールで実行できます。これらのツールの詳細については、『Windows 2000 Resource Kit』の付属 CD の『Tools Help』を参照してください。

ドメイン計画を作成する

ドメイン構造計画の作成を始めるときには、次の Windows 2000 ドメインの主な特性について考慮してください。

フォレストのパーティション
Active Directory のフォレストは分散データベースで、データベースのパーティションはドメインで定義されます。分散データベースとは、単一のコンピュータにある単一のデータベースではなく、多数のコンピュータに分散された部分的なデータベースから構成されるデータベースです。データベースを細分化し、それぞれをもっとも関連の深い場所に展開することで、大規模なデータベースを大規模ネットワークに効率的に分散できます。

ドメイン コントローラ サーバーのサービス
Windows NT 4.0 の場合と同様、Windows 2000 を実行し、ドメインのデータベースを処理するサーバーをドメイン コントローラと呼びます。ドメイン コントローラが処理できるドメインは 1 つだけです。ドメイン内のオブジェクトは、そのドメイン内のドメイン コントローラ上であれば変更できます。特定のフォレスト内のすべてのドメイン コントローラは、フォレストの設定コンテナおよびスキーマ コンテナのコピーも処理します。

認証の単位
個々のドメイン データベースには、ユーザー、グループ、およびコンピュータなどのセキュリティ プリンシパル オブジェクトが保持されます。セキュリティ プリンシパル オブジェクトは、ネットワーク上のリソースへのアクセス権を付与または拒否できる点で特殊です。セキュリティ プリンシパル オブジェクトは、これが存在するドメインのドメイン コントローラから認証を受けなければなりません。認証は、リソースへのアクセス前に、オブジェクトの ID を証明するために行われます。

管理およびグループ ポリシーのゾーン
個々のドメインには、ドメイン管理者グループがあります。ドメイン管理者は、そのドメイン内のすべてのオブジェクトに対するフル コントロールを保持します。これらの管理権限は、そのドメイン内でのみ有効で、他のドメインには波及しません。

特定のドメインに関連付けられているグループ ポリシーは、フォレストの他のドメインに自動的に波及することはありません。特定のドメインのグループ ポリシーを他のドメインに関連付けるには、明示的にリンクする必要があります。。

固有なドメイン ユーザー アカウントのセキュリティ ポリシー
ドメイン ユーザー アカウントに適用される小規模なセキュリティ ポリシー セットは、ドメイン単位でのみ設定できます。

  • パスワード ポリシー。パスワードの長さなど、ユーザーがパスワードを設定するときに満たさなければならない規則を決めます。

  • アカウント ロックアウト ポリシー。不正侵入者の検出およびアカウントの失効のための規則を定義します。

  • Kerberos チケット ポリシー。Kerberos チケットの有効期間を決めます。Kerberos チケットは、ログイン プロセスで取得され、ネットワーク認証に使用されます。チケットは、ポリシーに指定された有効期間中だけ有効です。チケットの有効期限が切れると、システムは自動的に新しいチケットを取得しようとします。

ドメイン ユーザー アカウントのセキュリティ ポリシーの詳細については、『Microsoft® Windows 2000 Server Resource Kit』の分冊の『Distributed Systems Guide』の「Authentication」を参照してください。

DNS ドメイン名
ドメインは、DNS 名で識別されます。DNS は、ドメイン コントローラ サーバーで特定のドメインを検索するときに使用します。DNS 名は階層型で、Active Directory ドメインの DNS 名は、フォレスト階層での位置を表します。たとえば、reskit.com というドメイン名がある場合、eu.reskit.com というドメインは、フォレスト階層で reskit.com の子ドメインになります。

ドメインの計画プロセス

ドメイン計画では、ネットワーク上のディレクトリの可用性、クライアントの照会トラフィックの特性、およびドメイン コントローラの複製トラフィックの特性を判断します。

作成する個々のフォレストには、1 つ以上のドメインが保持されます。フォレストのドメイン計画の作成手順は、次のとおりです。

  • 各フォレストのドメイン数を決定します。

  • フォレスト ルート ドメインを選択します。

  • 各ドメインに DNS 名を割り当て、ドメイン階層を作成します。

  • DNS サーバーの展開を計画します。

  • ショートカット信頼関係で認証を最適化します。

  • 展開後にドメイン計画が変更された場合の影響を理解します。

各フォレストのドメイン計画を作成するときには、おそらく次のグループに相談する必要があるでしょう。

  • ユーザー アカウント、グループ、およびコンピュータを担当する現在のドメイン管理者

  • 物理ネットワークを管理および監視するチーム

  • ネットワークの DNS サービスを管理するチーム

  • セキュリティ チーム

各フォレストのドメイン数を決定する

各フォレストに作成するドメイン数を決定するには、現在 Windows NT 4.0 ドメインが複数ある場合でも、まず単一のドメインから考えます。次に、追加するドメインごとに、正当な必要性があるかを評価します。ドメインを作成するたびに、管理オーバーヘッドというコストが余計に発生します。そのため、フォレストに追加するドメインが有益な目的を果たすものであるかどうかを確認してください。

ドメインの作成理由の変更点
以前のバージョンの Microsoft® Windows NT® Server (以下 Windows NT Server) で複数のドメイン環境を作成する要因には、Active Directory および Windows 2000 には当てはまらないものがあります。そうした要因には次のものがあります。

セキュリ ティ アカウント マネージャ (SAM) のサイズ制限 : 以前のバージョンの Windows NT Server の SAM データベースには、ドメインあたりオブジェクト 40,000 個という実質的な制限がありました。Active Directory は、ドメインあたり数百万個のオブジェクトへと容易に拡大できます。そのため、処理するオブジェクトが増えても、ドメインを追加作成する必要はまずありません。

プライマリ ドメイン コントローラ (PDC) の可用性要件 : 以前のバージョンの Windows NT Server では、ドメイン データベースへの更新を受け入れることができるのは、単一のドメイン コントローラ、つまり PDC だけでした。この制限により、大規模ネットワークを持つ企業は、ネットワークに障害が発生すると一部の管理者がドメインを更新できなくなるため、可用性の高い PDC を確保することが困難でした。このような可用性の要件を満たすため、PDC サーバーをネットワーク全体に分散できるようドメインを追加作成していました。Windows 2000 では、Active Directory のすべてのドメイン コントローラが更新を受け入れられるため、その必要がありません。

ドメイン内での管理権限委任の制限 : 以前のバージョンの Windows NT Server では、Account Operators グループなど組み込みのローカル グループを使用するか、複数のドメインを作成して別々のドメイン管理者セットを作成し、管理権限を委任していました。たとえば、ユーザー セットの管理権限を委任するには、新しいユーザー ドメインを作成し、ファイルまたはプリント サーバーなどのリソース サーバーの管理権限を委任するには、リソース ドメインを作成していました。Windows 2000 では、組織単位 (OU) を使用して、ドメイン内で管理権限を委任できます。OU は、ドメイン内のオブジェクトを論理的な管理サブグループに体系化するときに使用するコンテナです。OU は、ドメインより作成、削除、移動、および修正が簡単で、権限の委任に適しています。

OU を使用した管理権限の委任の詳細については、この章の後の「組織単位計画を作成する」を参照してください。

複数のドメインを作成する場合
ドメインを追加作成する理由として、次の 3 つが考えられます。

  • 既存の Windows NT ドメインを維持するため

  • 管理を分割するため

  • 物理的にパーティション化するため

既存の Windows NT ドメインの維持
既に Windows NT ドメインを使用している場合、これを少数の Active Directory ドメインに統合せずに、そのまま維持した方が都合がいいことがあります。ドメインを維持するか統合するかは、ドメインを統合するためにかかるコストと、ドメインの統合により得られる長期的な利点を秤に掛けて決定してください。ドメインの統合に伴うコストについては、このマニュアルの「第 10 章 ドメイン移行方針の決定」で説明します。初めてドメインを設計する場合は、できる限りドメイン数を少なくし、「第 10 章 ドメイン移行方針の決定」を読んでから、自分の立てた計画を再評価することをお勧めします。

管理の分割
次に説明する管理およびポリシーの要件によっては、さらに多くのドメインが必要になる場合があります。

固有なドメイン ユーザー セキュリティ ポリシーの要件 : ネットワーク上の特定のユーザー セットに、その他のユーザー コミュニティとは異なるドメイン ユーザー セキュリティ ポリシーを適用したい場合があります。たとえば、管理者に、パスワード変更間隔の短縮など、ネットワーク上の一般ユーザーより強力なパスワード ポリシーを持たせたい場合があります。これを行うには、これらのユーザーを別のドメインに配置する必要があります。

部門にドメインの自律管理が必要 : 特定のドメインのドメイン管理者グループのメンバーは、そのドメインの全オブジェクトに対するすべての権限を保持します。外部管理者にオブジェクト制御権限を与えたくないサブ部門が社内にある場合は、これらのオブジェクトを別のドメインに配置してください。たとえば、法律上の理由から、機密プロジェクトで作業するサブ部門が、上層の IT グループの監督を受けることが賢明でない場合があります。フォレスト内のすべてのドメインは、設定コンテナおよびスキーマ コンテナを共有するので、このような場合には注意が必要です。

物理的なパーティション化
物理的なパーティション化には、フォレスト内のドメインを複数の小規模なドメインに分割する作業が含まれます。ドメインを分割すると、オブジェクトを最も関連性の深い位置に複製するだけで済むため、複製トラフィックを最適化できます。たとえば単一のドメインを保持するフォレストでは、フォレスト内のすべてのオブジェクトはフォレスト内のすべてのドメイン コントローラに複製されます。この場合、ほとんど使用されない場所にもオブジェクトが複製される可能性があるため、帯域幅の使用効率が悪くなります。常に本社からログインするユーザーは、ユーザー アカウントが支社オフィスに複製されなくても困りません。この場合、ドメインを支社オフィスに複製せずに、本社のロケーションに別のドメインを作成することで、複製トラフィックを回避できます。

メモ : 既に Windows NT 4.0 ドメインを展開している場合、現在の物理的なパーティションに満足していることがありますが、白紙の状態からパーティション化を見直すと、ドメインの統合が可能な領域を特定できます。既存の Windows NT 4.0 ドメインを統合せずにアップグレードする場合には、パーティション化の説明を飛ばしてもかまいません。

フォレストをパーティション化するかどうか、またその方法を判断するには、次の手順に従います。

  • ネットワーク トポロジを作成します。

  • 可用性の要件に従って、ネットワークにドメイン コントローラを展開します。

  • ドメイン コントローラ間の複製トラフィックに基づいて、フォレストをパーティション化します。

ネットワーク トポロジを作成する
まず、基本的なネットワーク トポロジ図を描きます。後の計画プロセスでサイト トポロジを計画するときに、細部を決定します。トポロジ図を作成手順は次のとおりです。

  • サイトの集合を描きます。

    サイトとは、高速で信頼性の高い接続のネットワークです。高速バックボーンで接続されたローカル エリア ネットワーク (LAN) または LAN のセットは、サイトと見なすことができます。ネットワーク図に各サイトを描き、サイトのユーザーの概数を明記します。

  • サイトをサイト リンクで接続します。

    サイト リンクとは、2 つのサイトを接続する低速で信頼性の低いリンクです。2 つの高速ネットワークを接続するワイド エリア ネットワーク (WAN) は、サイト リンクの 1 つです。LAN 速度より低速なリンクは、低速リンクとして扱うことをお勧めします。トポロジ図に、各サイトと他のサイトをサイト リンクでどのように接続するかを示します。

    サイト リンクごとに、次の内容を記録します。

    • リンク速度および現在の使用レベル

    • リンクが従量制かどうか

    • リンクの信頼性が今まで低かったかどうか

    • 必要な場合のみリンクを使用できればよいか

  • SMTP 接続だけを持つサイトに印を付けます。

    ネットワークのその他の部分に物理的に接続されておらず、簡易メール転送プロトコル (SMTP) メールを通じてのみアクセスできるサイトがある場合、このサイトにメールベースの接続のみの印を付けます。

図 9.3 に、架空の Reskit 社のネットワーク トポロジを示します。

sdgch904

図 9.3: Reskit 社のネットワーク トポロジ

ドメイン コントローラを展開する
Active Directory の可用性は、ドメイン コントローラの可用性で決まります。ドメイン コントローラは、ユーザーが認証を受けられるように、使用可能でなければなりません。ここでは、ネットワークに障害が発生した場合に可用性を維持するため、どこにドメイン コントローラを配置するかを決めます。

ドメイン コントローラを配置する手順は次のとおりです。

  • "ホーム" サイトを選択し、トポロジ図にホーム サイトとしての印を付け、ドメイン コントローラを配置します。

    ホーム サイトは、任意に選択できます。たとえば、本社のロケーション、ユーザー数が最大のサイト、またはネットワークのその他の部分にもっとも包括的に接続しているサイトを選択します。ホーム サイトのすべてのユーザーは、このドメイン コントローラで認証されます。この時点では、どのドメインがこのドメイン コントローラのサービスを受けるかどうか、またこのサイトでドメインのレプリカがいくつ必要かについては、考える必要はありません。

  • ホーム サイトに直接接続するサイトごとに、ドメイン コントローラを配置すべきかどうかを判断します。

    または、サイトにドメイン コントローラを配置せずに、そのサイトのユーザーがサイト リンクを通じてホーム サイトのドメイン コントローラに接続し、認証を受けるようにするかどうかを判断します。サイト リンクが切断されている場合に認証が失敗してもかまわないのであれば、サイトにドメイン コントローラを配置する必要はありません。

    サーバーがなく、クライアント コンピュータだけの小規模な支社オフィスには、ドメイン コントローラは必要ありません。中央サイトへのリンクが切断されている場合でも、このオフィスのユーザーは、キャッシュされている資格情報を使用して、各自のコンピュータにログインできます。このオフィスには、それ以外にアクセスするサーバーベースのリソースがないため、これ以上の認証は必要ありません。すべてのリソースは、中央サイトで管理されています。

    次のような場合は、サイトにドメイン コントローラを配置します。

    • サイトのユーザーが多数で、サイト リンクが低速かまたは最大容量にほぼ達しているため、Active Directory クライアントのトラフィックにより、リンクの容量が消費されるのを回避したい。ネットワークの容量計画および Active Directory クライアントにより生成されるトラフィックの詳細については、Web Resources ページ http://technet.microsoft.com/windowsserver/bb633748.aspx (英語) の「Microsoft Windows 2000 Server」のリンクを参照してください。

    • 今までにリンクの信頼が低く、リンクが切断された場合に認証が失敗するのを回避したい。

    • リンクを断続的にのみ使用でき、特定時間帯の認証の失敗または要求ベースのダイアル リンクへの依存を回避したい。

    • サイトに SMTP メールでのみアクセスできるため、ユーザーが認証のためにローカルのドメイン コントローラを必要とする。

  • 前の手順を繰り返して、ドメイン コントローラを配置すべき場所を決めます。

    すべてのサイトについて同じ手順を繰り返し、ローカル ドメイン コントローラが必要かどうかを決定します。

メモ : ドメイン コントローラには、ドメイン認証に使用されるユーザーの秘密キーのコピーなど、セキュリティが重視される情報が保持されます。この情報のコピー数を少なくすれば、未認証アクセスの危険性を減少させることができます。また、ドメイン コントローラは、未認証アクセスに対して物理的に安全でなければなりません。たとえば、入室者が限定されている鍵の掛けられた部屋にドメイン コントローラを設置することをお勧めします。物理的に接触できれば、侵入者は、暗号化されたパスワードのコピーを入手し、これをオフラインでのパスワード攻撃に使用できます。Syskey ツールを使用すると、さらに強力なセキュリティ オプションを使用できます。Syskey の詳細については、『Distributed Systems Guide』の「Encrypting File System」を参照してください。

ユーザーがログオンしたときに、認証要求を処理するドメイン コントローラは、グローバル カタログ サーバーと通信できなければなりません。サイトにドメイン コントローラを配置するかを決定する際は、ドメイン コントローラをグローバル カタログ サーバーとして考える必要があります。グローバル カタログ サーバーが、通常のドメイン コントローラ以上の複製トラフィックを生成することを理解した上で、計画を作成してください。グローバル カタログ サーバーには、特定のドメインのすべてのコピーと、フォレスト内のその他すべてのドメインの読み取り専用の部分的なコピーが格納されます。

図 9.4 に、Reskit 社のドメイン コントローラの配置を示します。

  • 最初のドメイン コントローラは、本社のホーム ロケーションに配置されています。

  • 海外に向かう WAN リンクが最大容量にほぼ達しているため、ヨーロッパ オペレーション センターにドメイン コントローラが配置されています。

  • 地方オフィスには、WAN を通じて認証トラフィックを送信するユーザーが多数いるため、ドメイン コントローラが配置されています。

  • 支社オフィスにはローカル サーバーがないため、ドメイン コントローラが配置されていません。

  • 製造工場は SMTP メールでのみアクセスできるため、ドメイン コントローラが配置されています。

sdgch905

図 9.4: Reskit 社のドメイン コントローラの配置

フォレストをパーティション 化する
ここでは、ドメインを各ドメイン コントローラに割り当て、ネットワークが複製トラフィックを処理できるかどうかを判断し、必要に応じてフォレストを小規模なドメインにパーティション化します。パーティション化するときには、パーティション化の本来の目的は、ディレクトリ オブジェクトの物理的なコピーを、必要とするユーザーの近くに配置することであることを忘れないでください。たとえば、ユーザーのユーザー アカウント オブジェクトは、そのユーザーと同じサイトのドメイン コントローラに配置する必要があります。

フォレストをパーティション化するには、現在のドメイン計画に含まれているドメインごとに、次の手順に従います。

  • ドメイン コントローラを保持するサイトごとに、そのドメインがサイト内のユーザーと関連性が深いかどうかを判断します。適切な場合には、サイトにこのドメインのドメイン コントローラを配置します。

  • ドメインのドメイン コントローラ間の複製パスを追跡します。このとき、各ドメイン コントローラは、複製パートナーと同じドメインで次に最短のドメイン コントローラを選択するものとします。"最短" は、ネットワークを通じたもっともコスト効率の良いパスで決まります。

  • ドメインの 2 つのドメイン コントローラ間の複製トラフィックの容量は、ドメイン内のオブジェクトの変更頻度、変更されるオブジェクト数、オブジェクトが追加および削除される頻度に左右されます。ドメインを複数の小規模なドメインに分割すると、特定のリンクを通じて伝送される複製トラフィックの容量を軽減できます。複製パスの両端を検証して、複製トラフィックをそのまま許容できるか、ドメインを分割するかを判断します。

サイト間でドメインを複製するかどうか、複数の小規模なドメインに分割するかどうかを決めるときには、次の要因を考慮します。

  • 複製パスのサイト リンクが予期される複製トラフィックを許容できない場合には、ドメインを分割することを考慮します。

    サイト リンクの実際の容量によって、リンク速度、日常的な使用の特性、信頼性、および可用性が決まります。ドメインを作成するかどうかを決めるときには、リンクに関する次の情報を考慮してください。

    • 最大容量にほぼ達した状態で機能しているリンクは、複製を受け入れられない可能性があります。しかし、リンクがアイドル状態になる時間帯を見計らって Active Directory の複製をスケジュールすれば、複製に十分な帯域幅を確保できる場合もあります。

    • リンクを使用できる時間が特定の時間帯に限られる場合、実際の帯域幅は少なくなります。リンクの使用可能な時間にのみ、Active Directory を複製するようスケジュールできますが、実際の帯域幅に複製を受け入れるだけの容量が必要です。

    ネットワークの容量計画および Active Directory の複製トラフィックの詳細については、Web Resources ページ http://technet.microsoft.com/windowsserver/bb633748.aspx (英語) の「Microsoft Windows 2000 Server」のリンクを参照してください。

  • 複製トラフィックと、リンクのより重要なトラフィックとの競合を回避するには、ドメインを分割することを考慮します。

    基幹業務のトラフィックが中断まはた遅延すると高く付きます。ドメインを追加した方が結果的にコストを節約できることもあります。

  • 複製トラフィックが従量制のリンクを渡る場合には、ドメインを分割することを考慮します。

    リンクが従量制の場合、使用を抑えるほどコストは少なくなります。

  • SMTP メールでのみ接続されているサイトには、ドメインを作成します。

    Active Directory のメールベースの複製は、ドメイン間でのみ実行でき、同じドメインのドメイン コントローラ間には使用できません。

大規模なドメインを複数の小規模なドメインに分割するよう決めた場合、地理的な境界に基づいて小規模なドメインを作成するのが適切です。たとえば、国または大陸に基づいてドメインを作成します。ネットワーク トポロジは地理的な場所から作成されることが多く、地理はその他の分割基準よりも変更が少ない傾向にあるため、地理に基づいてドメインを作成することをお勧めします。

ネットワークの複製トラフィックを最適化するためだけに、多数の小規模なドメインを作成するのは考えものです。最適化には、次のような他の要因に対するトレードオフがあることを忘れないでください。

  • 複雑さ

    前に説明したとおり、ドメインを追加するごとに、一定の管理オーバーヘッドが発生します。

  • 照会トラフィックと複製トラフィック

    ドメイン内のオブジェクト数が少ないほど、ドメイン内のユーザーが他のドメインのオブジェクトにアクセスする可能性が高くなります。他のドメインのローカル ドメイン コントローラがない場合、照会によりトラフィックがこのサイトを離れます。

メモ : すべてのユーザー アカウントは、ドメイン コントローラのあるすべてのサイトで使用できるため、移動ユーザーが多数いる場合は、単一の大規模ドメインのモデルが最適です。この場合、ユーザーの現在のロケーションとホーム ロケーション間でネットワークが切断されても、移動ユーザーはログオン能力を失うことはありません。

図 9.5 に、Reskit 社の物理的なパーティション化を示します。Reskit 社では、次のようにドメインが割り当てられています。

  • 北米ユーザー用の Noam ドメインがホーム サイトのドメイン コントローラに割り当てられています。

  • 本社に Avionics ユーザーがいるため、管理上の理由で作成した Avionics ドメインがホーム サイトのドメイン コントローラに割り当てられています。

  • 海外への WAN リンクは最大容量にほぼ達しているため、新しいドメイン Eu がヨーロッパ オペレーション センターのドメイン コントローラに割り当てられています。このリンクでは、北米ドメインおよびヨーロッパ ドメインの両方の複製トラフィックは処理できません。

  • ヨーロッパには Avionics ユーザーがいるため、Avionics ドメインもヨーロッパ オペレーション センターに割り当てられています。

  • ヨーロッパ オペレーション センターまでの WAN リンクでは、基幹業務のトラフィックが伝送されるため、新しいドメイン Seville がセビリアの地方オフィスのドメイン コントローラに割り当てられています。

  • 新しいドメイン Mfg は、SMTP メールでのみアクセスできるため、製造工場のドメイン コントローラに割り当てられています。

sdgch906

図 9.5: Reskit 社のドメインの割り当て

ドメインの追加に伴うコスト
フォレスト内の各ドメインには、何らかの管理オーバーヘッドが発生します。ドメインを追加するかどうかを検討するときには、この章の前で決定した利点と次のコストを秤に掛けてください。

ドメイン管理者の増員 : ドメイン管理者は、ドメイン全体に対するフル コントロールを保持するため、ドメインのドメイン管理者グループのメンバーシップは厳密に監視されなければなりません。このため、フォレストに追加されるドメインごとに、この管理オーバーヘッドが発生します。

ドメイン コントローラ用ハードウェアの追加 : Windows 2000 では、ドメイン コントローラが処理できるのは単一のドメインだけです。作成する新しいドメインごとに、少なくとも 1 台のコンピュータが必要になり、多くの場合は信頼性と可用性の要件を満たすために 2 台のコンピュータが必要です。Windows 2000 のすべてのドメイン コントローラは、変更の受け入れおよび作成が可能なため、読み取り専用の Windows NT 4.0 のバックアップ ドメイン コントローラ (BDC) よりも物理的に保護されなければなりません。Active Directory ドメイン内で管理権限を委任すると、リソース ドメインの必要性が少なくなることに注意してください。現在 2 つのドメイン コントローラ (マスタ ユーザー ドメインおよびローカル リソース ドメイン) を処理しているリモート ロケーションでも、少数の Active Directory ドメインに統合すれば、ドメイン コントローラは 1 つだけで済むようになります。

信頼できるリンクの増設 : 特定のドメイン内のドメイン コントローラで別のドメインのユーザーを認証するには、2 番目のドメインのドメイン コントローラに問い合わせできなければなりません。この通信は、たとえばその時点で 2 つのドメイン コントローラ間のネットワークが機能していない場合に故障点となる可能性が高くなることを意味します。単一のドメインに配置されるユーザーおよびリソースが多いほど、他のドメイン コントローラとの通信に依存せずにサービスを維持できます。

ドメイン間でセキュリティ プリンシパルを移動する必要性の増加 : ドメインが多くなるほど、ユーザーおよびグループなどのセキュリティ プリンシパルを 2 つのドメイン間で移動しなければならない可能性が高くなります。たとえば、組織変更およびユーザーの業務変更があった場合、ドメイン間でユーザーの移動が必要になることがあります。ドメイン内の OU 間でのセキュリティ プリンシパルの移動は、エンド ユーザーおよび管理者にとって日常的で透過的な操作です。ただし、ドメイン間でのセキュリティ プリンシパルの移動は、かなり複雑であり、エンド ユーザーに影響を与える可能性があります。

ドメイン間でのセキュリティ プリンシパルの移動の詳細については、このマニュアルの「第 10 章 ドメイン移行方針の決定」を参照してください。

グループ ポリシーおよびアクセス制御がドメイン間で引き継がれない : 特定のドメインに適用されているグループ ポリシーおよびアクセス制御は、他のドメインに自動的に引き継がれることはありません。ポリシーがある場合、または多数のドメインに渡って統一されたアクセス制御で管理権限を委任している場合でも、ドメインごとに適用しなければなりません。

フォレスト ルート ドメインを選択する

フォレスト内に配置するドメイン数を決定したら、どのドメインをフォレスト ルート ドメインにするかを決める必要があります。フォレスト ルート ドメインとは、フォレストに最初に作成するドメインです。フォレスト全体のエンタープライズ管理者およびスキーマ管理者の 2 つのグループは、このドメインに存在します。

メモ : 破壊的な事故により、フォレスト ルート ドメインのすべてのドメイン コントローラが失われ、1 つ以上のドメイン コントローラをバックアップからリストアできない場合、エンタープライズ管理者グループおよびスキーマ管理者グループは完全に失われます。フォレストのフォレスト ルート ドメインを再インストールする方法はありません。

フォレストにドメインが 1 つだけある場合は、そのドメインがフォレスト ルートになります。フォレストに 2 つ以上のドメインがある場合には、次の 2 とおりの方法でフォレスト ルート ドメインを選択することを考慮してください。

既存のドメインを使用する
現在のドメインのリストから企業の運営に重要なドメインを選択し、これをフォレスト ルートにします。このドメインを失うことは許されないため、フォレスト ルートに必要な何らかの耐障害性および回復能力が必要になります。

専用ドメインを使用する
フォレスト ルートとしてのみ機能する専用のドメインを追加作成すると、ドメインを追加する場合と同じコストが発生しますが、次のような企業にとってはそれに見合う利点が得られることがあります。

  • フォレスト ルート ドメインのドメイン管理者は、エンタープライズ管理者およびスキーマ管理者グループのメンバーシップを操作できます。業務上、ドメイン管理者権限を必要とする管理者に、フォレスト全体の管理者グループを操作させたくない場合があります。別のドメインを作成すれば、このような管理者をフォレスト ルート ドメインのドメイン管理者グループに配置せずに済みます。

  • ドメインは小規模なため、ネットワークの任意の場所に容易に複製して、地理的に集中して発生する破壊的な事故から保護できます。

  • フォレスト ルートとして機能することがこのドメインの唯一の役割であるため、古くなる危険性がありません。フォレスト ルートとして使用する予定のドメインのリストからドメインを選択する場合には、企業の変更などによって、常に特定のドメインが古くなる可能性があります。ただし、このドメインはフォレスト ルートとしての役割を果たさなければならないため、完全に廃止することはできません。

DNS 名を割り当て、ドメイン階層を作成する

Active Directory のドメインは、DNS 名で名前付けされます。DNS は、インターネットに普及しているネーム システムであるため、DNS 名はグローバルに認識され、広く知られた登録機関もあります。ネットワークへのログインを要求する Active Directory クライアントは、DNS を照会してドメイン コントローラを検索します。

Windows NT 4.0 では、ドメイン ロケータは、ネットワーク基本入出力システム (NetBIOS) ネーム システム (NBNS) に基づいていたため、ドメインは NetBIOS 名で識別されていました。NBNS のサーバーベースのコンポーネントは、Windows インターネット ネーム サービス (WINS) サーバーと呼ばれます。NetBIOS 名は、単純で単一部分から構成されるため、NetBIOS のネームスペースを分割することはできません。これに対し、DNS 名は階層型のため、DNS のネームスペースは階層の経路に従って分割できます。その結果、DNS は NBNS よりスケーラブルで、大規模ネットワークに分散された大規模データベースにも適応できます。インターネット メールでも、Active Directory と同様の方法で DNS が利用されていますが、これは、ロケータ メカニズムとしての DNS がインターネットのような大規模なネットワークにも対応できることを表しています。

メモ : 以前のバージョンの Windows を実行するコンピュータとの相互運用性を保つため、Active Directory のドメインでは、NetBIOS 名および Active Directory ドメイン コントローラが NBNS で登録されるので、必要に応じて NBNS を照会できます。これにより、以前のバージョンの Windows を実行するクライアントでも、Active Directory のドメイン コントローラを検索でき、Active Directory のドメイン コントローラ、Windows NT 3.51 および Windows NT 4.0 のドメイン コントローラが相互に検索できます。

ドメインをツリーに構成する
ツリーとは、連続した名前を持つ 1 つ以上の Windows 2000 ドメインのセットです。図 9.6 に、連続したネームスペースを持つ単一のツリーを示します。reskit.com には親ドメインがないため、ツリー ルート ドメインと見なされます。reskit.com の子ドメインには、eu.reskit.com および noam.reskit.com があります。また、reskit.com の孫ドメインには、mfg.noam.reskit.com があります。各ドメイン名は、ドメイン階層の上位ドメイン名と異なるラベルを 1 つだけ持つため、これらのドメイン名は連続しています。

sdgch907

図 9.6: 単一ツリーの例 (4 つのドメインを持つ)

フォレストは、複数のツリーを保持できます。複数のツリーで構成されるフォレストでは、図 9.7 に示すように、ツリー ルート ドメイン同士の名前は連続していません。社内の部門がそれぞれ独自の DNS 名を登録し、独自の DNS サーバーを実行している場合には、フォレストに複数のツリーを保持できます。

sdgch908

図 9.7: 複数のツリーを保持するフォレスト

フォレスト内のドメイン階層によって、各ドメインを接続する過渡的な信頼関係のリンクが決まります。各ドメインは、親ドメインおよび子ドメインと直接的な信頼関係を結びます。フォレストにツリーが複数ある場合、信頼関係の視点から見て、フォレスト ルート ドメインが信頼関係ツリーの最上位に位置し、その他すべてのツリー ルートは子になります。図 9.8 に、2 つのツリー間の変遷的な信頼関係を示します。

sdgch909

図 9.8: ツリー間の変遷的な信頼関係

親子関係が適用されるのは、名前付けおよび信頼関係だけです。親ドメインの管理者が自動的に子ドメインの管理者にはなるわけではありません。また、親ドメインに設定されたポリシーが自動的に子ドメインに適用されることもありません。

ドメインの名前付けに関する推奨
フォレスト内にドメイン階層を作成するには、最初のドメインに DNS 名を割り当て、以降ドメインごとに既存ドメインの子または新しいツリー ルートのどちらにするかを決定します。この評価に基づいて、名前を割り当てます。ドメインには、次のように名前付けすることをお勧めします。

登録済みのインターネット DNS 名に関連した名前を使用する
インターネットに登録されている名前は、グローバルに固有です。インターネットに登録されている名前を Active Directory のドメイン名のサフィックスとして使用してください。

インターネット標準文字を使用する
DNS ホスト名のインターネット標準文字は、Request for Comments (RFC) 1123 で A ~ Z、a ~ z、0 ~ 9、およびハイフン (–) と定義されています。インターネット標準文字だけを使用すると、Active Directory が確実に標準ベースのソフトウェアに準拠します。以前の Windows ベースのドメインから標準以外の名前を使用する Windows 2000 ドメインへのアップグレードをサポートするため、Microsoft クライアントおよび Windows 2000 の DNS サービスでは、名前のほとんどの Unicode 文字がサポートされています。

同じ名前を 2 回使用しない
DNS ネームスペースが異なる接続されていないネットワークに 2 つのドメインがある場合でも、同じ名前を付けないでください。たとえば、Reskit 社がイントラネットのドメイン名を reskit.com にした場合、インターネットにも reskit.com というドメインを作成することはできません。reskit.com クライアントがイントラネットとインターネットの両方に同時に接続すると、ロケータ検索で最初に応答があったドメインが選択されます。クライアント側から見ると、この選択は不特定で、クライアントが必ずしも "正しい" ドメインを選択するとは限りません。このような構成例として、インターネットを介してイントラネットに仮想プライベート ネットワーク接続を確立するクライアントがあります。

異なる名前を使用する
Microsoft® Internet Explorer (以下 Internet Explorer) の組み込みのプロキシ クライアントおよび Winsock プロキシ クライアントなど一部のプロキシ クライアント ソフトウェアでは、ホスト名に基づいて、ホストがインターネット上にあるかどうかを判断します。このタイプのソフトウェアの多くは、少なくとも、特定のサフィックスを持つ名前をインターネット上にあるものと想定せずに、ローカル名として除外する手段を提供しています。

Reskit 社がイントラネットの Active Directory ドメインに reskit.com という名前を付ける場合、プロキシ クライアント ソフトウェアの除外リストに reskit.com を含める必要があります。しかし、これでは、Reskit イントラネット上のクライアントから www.reskit.com というインターネットのホストを見ることができません。イントラネットに同一のサイトを公開するのも無駄な話です。

この問題を回避するため、Reskit 社は、インターネットに公開されていない reskit-int01.com などの登録名を使用するか、たとえば corp.reskit.com のように reskit.com という特定のサフィックスで終わる名前がインターネットに公開されないよう企業ポリシーを確立することができます。どちらの場合も、プロキシ クライアントの除外リストを簡単に設定でき、イントラネットに使用する名前とインターネットに使用する名前を自在に区別できます。

イントラネットからインターネットへのアクセスには、さまざまな方法があります。名前を使用する前に、特定のインターネット アクセス方針において、イントラネット上のクライアントがその名前を適切に処理できるかを確認してください。

できる限りツリー数を少なくする
フォレスト内のツリー数を最小限に抑えると、いくつかの利点が得られます。環境により得られる利点を次に示します。

  • 特定の DNS 名に対する制御を与えられると、その名前の下位にあるすべての名前を所有します。ツリーの数が少ないほど、企業内で所有権を持たなければならない DNS 名が少なくなります。

  • プロキシ クライアントの除外サフィックス リストに入力する名前が少なくなります。

  • Microsoft クライアント以外の LDAP クライアント コンピュータは、ディレクトリの検索にグローバル カタログを使用しない可能性があります。この場合、クライアントは、深い検索を実行してディレクトリ全体を検索するため、特定のサブツリー内のすべてのオブジェクトが対象になります。フォレスト内のツリーの数が少ないほど、より浅い検索でフォレスト全体をカバーできます。

DNS 名の最初の部分を NetBIOS 名と同じにする
1 つのドメインに、まったく関連性のない DNS 名と NetBIOS 名を割り当てることができます。たとえば、特定ドメインの DNS 名を sales.reskit.com に、NetBIOS 名を "Marketing" にしたとします。Windows 2000 以前のコンピュータおよび Active Directory に対応していないソフトウェアは、NetBIOS 名を表示して受け入れるのに対し、Windows 2000 コンピュータおよび Active Directory 対応のソフトウェアは、DNS 名を表示して受け入れます。このようにコンピュータおよびソフトウェアによって、同じドメインでも別の名前が表示されるのでは、エンド ユーザーおよび管理者に混乱を引き起こす可能性があります。

一致しない NetBIOS 名と DNS 名は、次のような場合にのみ使用します。

  • ネットワークの新しい名前付け規則に移行する。

  • 標準以外の文字が含まれる NetBIOS 名をアップグレードする一方、DNS 名に標準文字だけを使用する。

国際的な視点で名前を検討する
ある言語ではわかりやすくて便利な意味を持つ名前が、別の言語では中傷的または攻撃的な意味を持つことがあります。DNS はグローバルなネームスペースです。名前を企業内でグローバルな視点から見直してください。

メモ : ネットワークで複数の言語バージョンの Windows を実行している場合には、Windows 2000 Professional および全バージョンの Windows 2000 Server を含むすべてのコンピュータは、DNS 名および NetBIOS 名の両方にインターネット標準文字だけを使用しなければなりません。これ以外の文字を使用した場合、相互に通信できるのは、同じ地域設定のコンピュータに限られます。

覚えやすい短い名前を使用する
名前を選択するときに、長さは重要な決定要素にはなりません。通常、ユーザーはグローバル カタログとやり取りするため、ドメイン名を意識しません。一般に、ドメイン名に触れるのは管理者だけです。管理ツールでは、多くの場合ドメインのリストから選択することになるので、管理者が完全な名前を入力しなければならないことは、まずありません。もし、あなたが名前のコンポーネントをすべて覚えているなら、名前が長くなることはありません。

ドメイン名とコンピュータ名
ドメインに所属している Windows 2000 コンピュータは、既定で、そのコンピュータのホスト名と、所属しているドメインの DNS 名を使用して、そのコンピュータの名前として DNS 名を構成し割り当てます。たとえば、図 9.9 でサーバー 1 のコンピュータ アカウントが eu.reskit.com 内にある場合、コンピュータは既定でそれ自体の名前を server1.eu.reskit.com とします。また、Active Directory ドメイン名ではなく、任意の DNS サフィックスを使用することも可能です。社内の DNS 構造に合わせて、Active Directory ドメインに名前をつける必要はありません。Active Directory ドメインには任意の名前を使用でき、コンピュータは既存の名前をそのまま使用できます。

sdgch910

図 9.9: 既定および既定以外の名前を持つメンバー コンピュータ

コンピュータの名前付けの詳細については、『TCP/IP Core Networking Guide』の「Windows 2000 DNS」を参照してください。

DNS サーバーの展開を計画する

Active Directory ドメインをサポートする DNS サーバーの導入を計画するには、ドメイン名に対する権限を持つ DNS サーバーを特定し、ドメイン コントローラ ロケータ システムの要件を満たさなければなりません。

DNS の権限と委任
ドメイン ネーム システムは、階層型の分散システムです。データベース自体は、リソース レコードで構成され、リソース レコードは、主に DNS 名、レコード タイプ、およびレコード タイプに関連付けられているデータ値から構成されます。たとえば、DNS データベースの一般的なレコードに、アドレス (A) レコードがあります。アドレス レコード名はコンピュータ名で、このレコード内のデータはコンピュータの TCP/IP アドレスです。

Active Directory と同様に、DNS データベースはパーティションに分割されており、これによってデータベースを大規模なネットワークにも効果的にスケーリングできます。DNS データベースのパーティションを "ゾーン" と呼びます。ゾーンには、連続した DNS 名セットのレコードが格納されます。ゾーンをロードする DNS サーバーは、そのゾーン内の名前に対する権限を保持します。

ゾーンは、指定された名前から始まり、権限の委任ポイントで終わります。委任ポイントは、1 つのゾーンが終わり、別のゾーンが始まる場所です。たとえば、"com" というゾーンを担当するインターネットの登録機関がありますが、このゾーン内には、reskit.com など、他のゾーンへの何千もの委任ポイントがあります。委任ポイントにあるデータは、どのサーバーが委任されるゾーンに対する権限を持つか示します。図 9.10 に、DNS サーバー、ゾーン、および委任の関係を示します。

sdgch911

図 9.10: DNS 内のサーバー、ゾーン、委任

ドメイン コントローラ ロケータ システム
ドメイン コントローラは、レコード セットを DNS で登録します。これらのレコードを総称的にロケータ レコードと呼びます。クライアントはドメインの特定のサービスを要求する場合、特定の名前とタイプのレコードの照会を最短の DNS サーバーに送信します。この応答として、要求を満たすことのできるドメイン コントローラのリストが返されます。

各ドメインのロケータ レコードの名前は、<DNS-domain-name> および <DNS-forest-name> で終わります。各 <DNS-domain-name> に対する権限を持つ DNS サーバーは、このロケータ レコードに対する権限も持ちます。

: Windows 2000 には、逆引き参照ゾーンを設定する必要はありません。その他のアプリケーションや管理の便宜上、逆引き参照ゾーンが必要とされることはあります。

DNS サーバーの要件
ネットワークで DNS サーバーを使用していない場合、Windows 2000 Server の DNS サービスを配置することをお勧めします。既に DNS サーバーを使用しているネットワークで Active Directory をサポートするには、ロケータ レコードに対する権限を持つサーバーが次の要件を満たしている必要があります。

  • サービス ロケーション リソース レコードをサポートしている。

    ロケータ レコードに対する権限を持つ DNS サーバーは、サービス ロケーション (SRV) のリソース レコード タイプをサポートしていなければなりません。SRV レコードの詳細については、『TCP/IP Core Networking Guide』の「Introduction to DNS」を参照してください。

  • DNS 動的更新プロトコルをサポートしている。

    ロケータ レコードに対する権限を持ち、これらのゾーンのプライマリ マスタ サーバーである DNS サーバーは、RFC 2136 で定義される DNS 動的更新プロトコルをサポートしていなければなりません。

Windows 2000 Server の DNS サービスは、この両方の条件を満たしています。また、次の 2 つの重要な追加機能も備えています。

  • Active Directory の統合

    この機能を使用すると、Windows 2000 の DNS サービスによってゾーン データがディレクトリに格納されます。これにより、DNS の複製で複数のマスタが作成され、任意の DNS サーバーがディレクトリ サービスに統合されているゾーンの更新を受け入れることができます。また、Active Directory の統合機能を使用すると、別の DNS ゾーン転送複製トポロジを維持する必要性が軽減されます。

  • 安全な動的更新

    安全な動的更新機能は、Windows セキュリティに組み込まれています。この機能により、管理者は、どのコンピュータがどの名前を更新できるかを厳密に制御でき、未認証のコンピュータが DNS から既存の名前を取得するのを防ぐことができます。

ロケータ レコードに対する権限を持たないネットワーク上のその他の DNS サーバーは、これらの要件を満たす必要がありません。一般に、権限を持たないサーバーは、明示的にレコード タイプをサポートしていなくても、SRV レコードの照会に応答できます。

権限を持つサーバーを検索する
選択する DNS 名ごとに DNS 管理チームに問い合わせて、DNS サーバーが前に挙げた条件をサポートしているかどうかを調べます。サポートしていないことがわかった場合、次の 3 つの基本アクションを実行できます。

条件を満たすバージョンにサーバーをアップグレードする
権限を持つサーバーで Windows NT 4.0 の DNS サービスが実行されている場合、単純にサーバーを Windows 2000 にアップグレードします。これ以外の DNS サーバーが導入されている場合には、各ベンダのマニュアルを参照し、Active Directory のサポートに必要な機能をサポートしているバージョンを調べまてください。

権限を持つ DNS サーバーが制御下になく、アップグレードするようサーバーの所有者を説得できない場合には、次のいずれかを実行できます。

ゾーンを Windows 2000 DNS に移行する
Active Directory の条件を満たすバージョンに、権限を持つサーバーをアップグレードする代わりに、これらサーバーのゾーンを Windows 2000 の DNS に移行できます。ゾーンを Windows 2000 の DNS に移行するのは簡単です。つまり、1 台以上の Windows 2000 の DNS サーバーをゾーンのセカンダリ サーバーとして導入します。これらのサーバーのパフォーマンスと管理性に満足できたら、いずれかのサーバーのゾーンをプライマリ コピーに変更し、必要に応じて DNS ゾーンの転送トポロジを再構成します。

要件を満たす DNS サーバーに名前を委任する
権限を持つサーバーのアップグレードも移行も適切でない場合、ドメイン名を Windows 2000 の DNS サーバーに委任して、権限を持つサーバーを変更できます。権限を持つサーバーの変更方法は、既存のゾーン構造とドメイン名との関係によって異なります。

  • ドメイン名がゾーンのルート名と同じでない場合、名前を直接 Windows 2000 の DNS サーバーに委任できます。たとえば、ドメイン名が noam.reskit.com で、この名前を保持するゾーンが reskit.com の場合、noam.reskit.com を Windows 2000 の DNS サーバーに委任します。

  • ドメイン名がゾーンのルート名と同じ場合、名前を直接 Windows 2000 の DNS サーバーに委任できないため、ロケータ レコードで使用される各サブドメインを Windows 2000 の DNS サーバーに委任します。これらのサブドメインには、_msdcs.<DNS-domain-name>、_sites.<DNS-domain-name>、_tcp.<DNS-domain-name>、および _udp.<DNS-domain-name> があります。これを行う場合には、<DNS-domain-name> アドレス (A) レコードを手作業で登録する必要があります。詳細については、『TCP/IP Core Networking Guide』の「Windows 2000 DNS」を参照してください。

ショートカット信頼関係で認証を最適化する

ユーザーがネットワーク リソースへのアクセスを要求した場合、ユーザーのドメインのドメイン コントローラは、リソースのあるドメインのドメイン コントローラと通信しなければなりません。2 つのドメインが親子関係にない場合、ユーザーのドメイン コントローラは、ユーザーのドメインとリソースのあるドメイン間の信頼関係ツリーに従って各ドメインのドメイン コントローラとも通信しなければなりません。各ドメインのドメイン コントローラのネットワーク位置によって、2 つのドメイン間で認証段階が増えるたびに、障害の可能性が高くなったり、認証トラフィックが低速リンクを渡らなければならない可能性が高くなったりします。このようなやり取りに必要な通信量を軽減するため、任意の 2 つのドメインをショートカット信頼関係でつなぐことができます。

たとえば、フォレスト内に複数のツリーがある場合、ツリー ルートのグループを完全な信頼関係で網目状に結び付けたいことがあります。既定の構成では、信頼関係の視点から見て、すべてのツリー ルートがフォレスト ルートの子と見なされます。つまり、ツリーが異なる任意の 2 つのドメイン間の認証トラフィックは、フォレスト ルートを経由しなければなりません。網目状の完全な信頼関係を作成すると、任意の 2 つのツリー ルート ドメインが直接相互に通信できます。

図 9.11 に、4 つのツリー ルート ドメイン間に作成された網目状の完全な信頼関係を示します。

sdgch912

図 9.11: 4 つのドメイン間の網目状の完全な信頼関係

展開後にドメイン計画を変更する

いったん作成したドメイン階層は、簡単には変更できません。そのため、一時的または短期的な組織構成に基づいてドメインを作成するのは不適切です。たとえば、社内の特定のビジネス単位に基づいてドメインを作成すると、組織変更によってビジネス単位が分割、解散、または別の単位に統合された場合に、ネットワーク管理者の作業が増えることになります。

ただし、組織ベースのパーティション化が適切な場合もあります。地理的な境界は、組織が頻繁にこの境界を越えて移動しない限り、比較的安定したパーティション化のテンプレートとして使用できます。たとえば、さまざまな部隊が各地の基地に分散している陸軍のドメイン計画について考えてみます。部隊が基地間を移動するのは日常茶飯事です。フォレストを地理的な場所に基づいてパーティション化すると、部隊が基地を移動したときに、管理者は、多数のユーザー アカウントをドメイン間で移動しなければなりません。フォレストを部隊に基づいてパーティション化すれば、管理者は、ドメイン コントローラを基地間で移動するだけで済みます。この場合は、地理的なパーティション化よりも組織ベースのパーティション化の方が適切です。

新しいドメインを追加する、既存のドメイ ンを削除する
フォレストに新しいドメインを追加するのは簡単ですが、既存の Windows 2000 Active Directory ドメインをフォレスト間で移動することはできません。

 

sdgch903

意思決定の重要ポイント : ツリー ルート ドメインを確立した後に、より高レベルな名前を持つドメインをフォレストに追加することはできません。つまり、作成できるのは子ドメインだけで、既存ドメインの親を作成することはできません。たとえば、ツリーの最初のドメインが eu.reskit.com の場合、後で reskit.com という親ドメインを追加することはできません。

ドメインのすべてのドメイン コントローラをメンバ サーバーまたはスタンドアロンに降格すると、そのドメインはフォレストから削除され、ドメインに格納されていた情報がすべて失われます。ドメインをフォレストから削除できるのは、ドメインに子ドメインがない場合だけです。

ドメインをマージおよび分割する
Windows 2000 では、単一の操作でドメインを 2 つのドメインに分割、または 2 つのドメインをマージすることはできません。

 

sdgch903

意思決定の重要ポイント : 会社の規模が拡大しても、パーティションの変更が最小限で済むように、ドメイン計画を設計することが重要です。

フォレストに空のドメインを追加して、他のドメインからこのドメインにオブジェクトを移動すると、ドメインを分割できます。同様に、ソース ドメインのすべてのオブジェクトをターゲット ドメインに移動すると、ドメインと別のドメインをマージできます。前に説明したように、ドメイン間でセキュリティ プリンシパルを移動すると、エンド ユーザーに影響を与える可能性があります。ドメイン間でのオブジェクトの移動の詳細については、このマニュアルの「第 10 章 ドメイン移行方針の決定」を参照してください。

ドメイン名を変更する
Windows 2000 には、使用中のドメインの名前を変更する機能はありません。ドメインの名前はツリー階層での位置を表すため、ドメインをフォレスト内で移動することもできません。

 

sdgch903

意思決定の重要ポイン : ドメインには、会社の規模が拡大しても、引き続き通用する名前を選択してください。

使用中のドメイン名を変更する代わりに、フォレスト内に希望の新しい名前を持つ新規ドメインを作成し、古いドメインのすべてのオブジェクトを新しいドメインに移動することができます。

組織単位計画を作成する

組織単位 (OU) は、ドメイン内に構造を作成するときに使用するコンテナです。ドメイン内に構造を作成するときには、次の OU の特性を考慮することが重要です。

OU は入れ子にできま **す。**OU には子 OU を保持できるため、ドメイン内に階層型ツリー構造を作成できます。

OU は、管理権限の委任およびディレクトリ **オブジェクトへのアクセス制御に使用できます。**OU のネスティングとアクセス制御リストを組み合わせて使用すると、ディレクトリ内のオブジェクトの管理権限を細かく分散できます。たとえば、ヘルプ デスク技術者のグループに、特定のユーザー セットのパスワードはリセットできるが、ユーザーの作成およびユーザー オブジェクトのその他の属性は修正できない権限を与えることができます。

OU は、セキュリティ **プリンシパルではありません。**セキュリティ グループは特定の OU に存在するため、OU をセキュリティ グループのメンバーにすることも、リソースに対する許可をユーザーに与えることもできません。OU は、管理権限の委任に使用するため、ユーザー オブジェクトの親 OU は、だれがユーザー オブジェクトを管理できるかを表しますが、ユーザーがアクセスできるリソースを示すものではありません。

グループ ポリシーを OU **に関連付けることができます。**グループ ポリシーを使用すると、ユーザーおよびコンピュータのデスクトップ構成を定義できます。グループ ポリシーは、サイト、ドメイン、および OU に関連付けることができます。OU ごとにグループ ポリシーを定義すると、同じドメイン内に異なるポリシーを適用できます。グループ ポリシーの詳細については、このマニュアルの「第 24 章 変更管理と設定管理」および「第 23 章 クライアントの管理標準や設定標準の決定」を参照してください。

ユーザーが OU **構造をナビゲートすることはありません。**OU 構造を設計するときには、エンド ユーザーの便宜を考慮する必要はありません。ユーザーがドメインの OU 構造をナビゲートすることも可能ですが、これによってリソースを効率的に発見できるわけではありません。ディレクトリ内のリソースを見つけるもっとも効率的な方法は、グローバル カタログを照会することです。

OU 構造とビジネス構造

まず "組織単位構造" という言葉から、企業、およびそのさまざまな部門、部署、プロジェクトを反映した構造の作成を連想する方もいるでしょう。このような構造を作成することもできますが、管理が複雑でコストがかかる可能性があります。OU は、管理権限を委任するためにあります。そのため、多くの場合、作成する構造は、管理モデルを反映したものになります。企業の管理モデルには、業務組織が正確に表されているわけではありません。

たとえば、図 9.12 に示す業務指向の構造を考えてみましょう。OU が Home Electronics 部門 (Electronics OU)、Medical Systems 部門 (Medical OU)、および Automotive 部門 (Automotive OU) に作成されています。Automotive チームのユーザーは Automotive OU に所属し、同様に各部門のユーザーはそれぞれの OU に所属します。

sdgch913

図 9.12: ビジネス構造を基にした OU 構造

同じ会社が集中管理モデルを採用した場合を想定してみましょう。1 つの管理者グループが、部門に関係なく、社内のすべてのユーザーを管理しています。この会社には、日々さまざまなことが起こり得ます。ある社員が Home Electronics 部門から Automotive 部門に異動した場合、管理者は、この社員のユーザー アカウントを Electronics OU から Automotive OU に移動しなければなりません。異動する社員数が多いと、管理者グループに大変な作業が発生するだけで、事実上の成果は何もないのではないでしょうか。

今度は、すべてのユーザー アカウントを保持する単一の OU で構成される OU 構造を考えます。この場合、ユーザーが部門を異動しても、管理者にオブジェクトを移動する追加作業が発生しません。構造を作成するときには、常に意味のある目的を果たす構造にします。正当な理由付けなく構造を作成すると、必ず不要な作業が発生します。

OU 構造に業務構造を反映させると、業務単位に基づいてユーザー リストを作成することが簡単にできます。OU は、これを実践する方法の 1 つに過ぎません。ユーザーに対するリソース アクセス権の付与を、業務構造に忠実に反映させることもあります。たとえば、特定プロジェクトのユーザーに、特定のファイル サーバー セットへのアクセス権を与え、特定部門のユーザーに特定の Web サイトへのアクセス権を与えることができます。リソース アクセス権は、セキュリティ グループに基づいて与えられるため、会社の組織構造は OU でなく、セキュリティ グループ構造でもっともよく表現できる場合があります。

OU の計画プロセス

ドメインの OU 構造計画を作成する手順は、次のとおりです。

  • 管理権限を委任するための OU を作成します。

  • オブジェクトを隠すための OU を作成します。

  • グループ ポリシー用の OU を作成します。

  • 展開後に OU 構造を変更した場合の影響を理解します。

上記の手順を順番どおりに実行することが重要です。管理権限の委任だけを考慮して設計した OU 構造と、グループ ポリシーだけを考慮して設計した OU 構造は異なります。グループ ポリシーを適用する方法は何とおりもありますが、管理権限を委任する方法は 1 とおりだけです。そのため、まず管理権限を委任するための OU を作成します。

OU 構造は、複雑なものになりがちなので注意が必要です。計画に OU を追加するときには、必ずその正当な理由を書き留めてください。これによって、すべての OU に目的があることを確認でき、計画書の読者が構造の背景にある事情を理解できます。

各ドメインの OU 計画を作成するときには、管理者組織の次のグループに相談してください。

  • ユーザー アカウント、セキュリティ グループ およびコンピュータ アカウントを担当する現在のドメイン管理者

  • 現在のリソース ドメインの所有者および管理者

管理権限を委任するための OU を作成する

Windows 2000 以前のバージョンの Windows NT では、ドメイン内の管理権限の委任は、アカウント管理者グループなどの組み込みのローカル グループを使用するよう限定されていました。これらのグループは、事前に定義された権限を持ち、ときには、この権限が特定の状況の必要性に適合しないことがありました。その結果、管理者が、ドメイン管理者権限などさらに高レベルな管理アクセス権を必要とする場合がありました。

Windows 2000 の管理権限の委任は、強力で柔軟になっています。この柔軟性は、組織単位、属性単位でのアクセス制御、およびアクセス制御の継承により実現されています。管理権限を委任するには、特定クラスのオブジェクトを作成する権限、または特定クラスのオブジェクトの属性を修正する権限をユーザーのセットに与えます。

たとえば、人事部門に、特定の OU 内だけにユーザー オブジェクトを作成する権限を与えることができます。また、ヘルプデスク技術者に、その OU 内のユーザーのパスワードをリセットする権限を与え、ユーザーを作成する権限を与えないようにできます。さらに、その他のディレクトリ管理者に、ユーザー オブジェクトのアドレス帳属性を修正する権限を与え、ユーザーの作成およびパスワードの変更を許可しないようにできます。

管理権限を委任すると、いくつかの利点が得られます。特定の権限を委任すると、高レベルなアクセス権を必要とするユーザー数を最小限に抑えることができ、限定された権限を持つ管理者による事故や間違いの影響を、その管理者が担当する領域にのみ留めることができます。従来、組織内では、IT 以外のグループが高レベルな管理者に変更要求を送信し、管理者が代わって変更することが必要な状況がありました。管理権限を委任すれば、ネットワーク管理者の任務を企業内の個々のグループに分担できるため、要求をハイレベルの管理者グループに送信するオーバーヘッドを排除できます。

アク セス制御リストを修正する
管理権限を委任するには、OU を通じてグループに特定の権限を与えます。このとき、OU のアクセス制御リスト (ACL) を修正する必要があります。オブジェクトの ACL 内のアクセス制御エントリ (ACE) によって、オブジェクトにアクセスできるユーザーとアクセスの種類が決まります。ディレクトリ内に作成したオブジェクトには、既定の ACL が適用されます。既定の ACL は、オブジェクト クラスのスキーマ定義に記述されています。

ACE は、コンテナ オブジェクトの子オブジェクトに継承できます。子オブジェクトにコンテナがある場合、ACE は、そのコンテナの子にも適用されます。継承によって、委任された権限を単一の OU ではなく、OU のサブツリー全体に適用できます。また、オブジェクトで ACE の継承をブロックして、親コンテナの ACE がオブジェクトまたは子オブジェクトに適用されないようにするのも可能です。継承可能な ACE が適用されるのはドメイン内だけで、子ドメインにまでは引き継がれません。

特定のオブジェクト セットに対する制御を OU サブツリーに委任するには、OU の ACL を編集します。OU サブツリーに委任するには、Active Directory ユーザーおよびグループ用の Microsoft Management Control (MMC) スナップインの Delegation of Control ウィザードを使用するのが最も簡単です。オブジェクトの ACL を表示または ACL のアドバンスト編集を実行するには、オブジェクトのプロパティ ページの [セキュリティ] タブを使用します。

個々のユーザーではなく、必ず ACL 内のグループを参照してください。グループのメンバーシップの管理は、OU の ACL の管理より簡単です。ユーザーが役割を変更した場合には、すべての OU の ACL を調べるより、グループ メンバーシップを検索して変更する方がはるかに簡単です。可能であれば、グローバル グループまたはユニバーサル グループではなく、ローカル グループに委任します。グローバル グループとは異なり、ローカル グループは、信頼する任意のドメインのメンバーを保持できるため、リソースへの権限の付与に適しています。また、ユニバーサル グループとは異なり、ローカル グループ メンバーシップはグローバル カタログに複製されないため、リソースに左右されません。

作成する OU を決定する
作成する OU 構造は、社内で管理権限がどのように委任されるかだけで決まります。管理権限を委任する方法には、次の 3 とおりがあります。

  • 物理的な場所ごと。たとえば、ヨーロッパにあるオブジェクトの管理は、独立した管理者セットで処理できます。

  • ビジネス単位ごと。たとえば、Avionics 部門に属するオブジェクトの管理は、独立した管理者セットで処理できます。

  • 役割または作業ごと。この分類は、管理対象となるオブジェクトのタイプに従います。たとえば、特定の管理者がコンピュータ アカウント オブジェクトだけを担当できます。

この 3 とおりの方法は、多くの場合、組み合わせて使用します。たとえば、図 9.13 に示すように、Automotive 業務単位のアトランタにあるコンピュータ アカウント オブジェクトを担当する管理グループを作成できます。

sdgch914

図 9.13: 二層の委任

Atlanta OU が Automotive OU の子かどうかは、Automotive の管理者が権限をアトランタの管理者に委任しているか、またはその逆かによって異なります。また、アトランタの管理者が Automotive の管理者から完全に独立することも可能で、この場合、2 つの OU は対等になります。

メモ : 24 時間体制のサポートを実施するため、地理的に管理グループを分散し、すべての管理グループの通常勤務時間を組み合わせて組織全体で 24 時間をカバーする組織もあります。この場合、管理者は世界中のユーザーを援助しなければならないため、各管理グループの管理範囲は地域固有ではありません。このため、この例では各地に管理者が分散していますが、地域ベースの委任ではありません。

委任手順
ドメイン内の既定構造から始め、次の基本的な手順で OU 構造を作成します。

  • フル コントロールを分散して、OU の最上層を作成します。

  • オブジェクト単位のクラス制御を委任するため、OU の最下層を作成します。

フル コントロールを委任する
まず、ドメイン管理者だけが全オブジェクトに対するフル コントロールを保持します。ドメイン管理者は、次の操作だけを担当するのが理想的です。

  • 最初の OU 構造の作成

  • 間違いの修復

    ドメイン管理者は、既定でフル コントロールを保持するほか、ドメイン内の任意のオブジェクトの所有権をも保持できます。この権限を使用すると、ドメイン管理者は、オブジェクトに設定されている権限にかかわらず、ドメイン内の任意のオブジェクトに対するフル コントロールを得ることができます。

  • ドメイン コントローラの追加作成

    ドメインにドメイン コントローラを追加作成できるのは、ドメイン管理者グループのメンバーだけです。

ドメイン管理者の責務を限られたものにする場合は、管理者グループのメンバーシップを小規模にとどめ、制御します。

独自の OU 構造および管理モデルを決定する権限が必要な場合、次の手順に従います。

  • 単位ごとに OU を作成します。

  • 単位ごとに、その単位で最高レベルの管理者を表すローカル グループを作成します。

  • 該当するグループに OU に対するフル コントロールを割り当てます。

  • 単位に独自のメンバーシップを作成することが許可されている場合、この単位の管理者グループを OU に配置します。単位に独自の管理者メンバーシップの設定が許可されていない場合には、グループを OU 外に配置したままにします。

フル コントロールの委任例
Reskit 社の Automotive 単位は、2 社の合併によりできた単位で、Automotive 単位は完全に独立した IT グループを維持していました。この状況では、Automotive 単位は、ドメインのルートから独自の OU を取得しています。また、単位自体の管理者グループのメンバーシップを定義することが許可されているため、このグループが Automotive OU に配置されています。Automotive 単位自体がアトランタおよびトロントで完全に独立して運営する場合、Automotive 管理者は、再度 OU を作成してフル コントロールを委任することになります。図 9.14 に示すように、Automotive 管理者は、アトランタおよびトロントの管理者グループのメンバーシップに対する設定権限を維持しています。

sdgch915

図 9.14: フル コントロールの委任

組織内にフル コントロールが必要な単位がまったくない場合、ドメイン管理者が残りの OU 構造を決定します。

オブジェクト クラス単位で制御を委任する
フル コントロールを保持するグループは、さらに限定された制御を委任するために、追加 OU が必要かどうか判断できます。この判断を簡素化するには、ディレクトリ内に作成される各オブジェクト クラスを考慮し、そのオブジェクト クラスの管理をさらに企業内に委任するかどうかを判断します。スキーマでは、さまざまな種類のオブジェクト クラスが定義されていますが、ここで考慮する必要があるのは、管理者が Active Directory に作成するオブジェクト クラスだけです。少なくとも、次のオブジェクトについて考慮します。

  • ユーザー アカウント オブジェクト

  • コンピュータ アカウント オブジェクト

  • グループ オブジェクト

  • 組織単位オブジェクト

各オブジェクト クラスを検証するときに、次の内容も考慮します。

  • 特定クラスのオブジェクトに対するフル コントロールを与えるグループ。フル コントロールを保持するグループは、指定されたクラスのオブジェクトを作成および削除でき、指定されたクラスのオブジェクトの任意の属性を修正できます。

  • 特定クラスのオブジェクトの作成を許可するグループ。既定では、ユーザーは、各自が作成したオブジェクトに対するフル コントロールを保持します。

  • 特定クラスの既存オブジェクトの特定属性の修正だけを許可するグループ。

制御を委任することを決定した個々のケースについて、次の操作を行います。

  • 特定機能の実行を許可するローカル グループを作成します。

  • このグループに、できる限り上位の OU の特定権利を与えます。

メモ : オブジェクトを 2 つの OU 間で移動するには、移動する管理者に、移動先コンテナにオブジェクトを作成し、移動元コンテナからオブジェクトを削除する権限が必要です。この理由から、オブジェクトを移動できる管理者用の別グループを作成し、この管理者に共通の親 OU で必要な権限を与えたい場合があります。

考慮するオブジェクトのリストは、展開する Active Directory 対応アプリケーションが多いほど大きくなります。ただし、一部のアプリケーションは、手作業による管理が必要ないオブジェクトをディレクトリ内に作成します。たとえば、Windows 2000 を実行するプリント サーバーは、自動的にプリント キューをディレクトリに発行します。プリント サーバーは、プリント キュー オブジェクトを管理するため、管理権限を特別な管理者グループに委任する必要がありません。

コンピュータ コンテナの既定の ACL を修正すると、コンピュータ アカウント オブジェクトを作成する権限をすべてのユーザーに委任でき、管理上の注意を払う必要がありません。コンピュータ アカウントは、ユーザーが既定のコンピュータ コンテナのドメインにコンピュータを追加すると作成されます。

オブジェクト クラス単位の制御の委任例
Reskit 社の Automotive 単位のアトランタ ロケーションは、Powertrain および Chassis という 2 つの Windows NT 4.0 リソース ドメインのホームです。Windows 2000 の移行の過程には、この 2 つのドメインを noam.reskit.com ドメインに集約する作業が含まれます。

現在、Powertrain および Chassis 管理者は、ドメインを次の目的に使用しています。

  • チーム メンバーのコンピュータ アカウントを作成する。

  • Windows NT 4.0 バックアップ ドメイン コントローラ (BDC) のファイル システム スペースを共有し、ファイル システムへのアクセスおよび共有をローカル グループ メンバーシップで制御する。

管理権限を委任すると、簡単にリソース ドメインを OU に置き換えることができます。この場合、各種類のオブジェクトを管理するためのグループが作成され、このグループにプロジェクト特有の OU 内のフル コントロールが与えられます。プロジェクト特有の OU は、Powertrain と Chassis のそれぞれの管理者が他のオブジェクトを操作できないようにするために必要です。図 9.15 に、この概念を表します。

Dd143060.sdgch916s(ja-jp,TechNet.10).gif

図 9.15: リソース ドメインの置き換え

拡大表示する

オブジェクトを隠すための OU を作成する

ユーザーがオブジェクトの属性の読み取り権限を持たない場合でも、オブジェクトの親コンテナの内容を列挙することにより、そのオブジェクトの存在を認識できます。オブジェクトまたはオブジェクト セットを隠すもっとも簡単で効率の良い方法は、これらのオブジェクト用に OU を作成し、その OU に対する内容の一覧表示権限を持つユーザーを限定することです。

オブジェクトを隠すための OU を作成するには、次の手順に従います。

  1. オブジェクトを隠す場所に OU を作成します。

  2. OU のプロパティ シートの [セキュリティ] タブをクリックします。

  3. OU から既存の許可をすべて消去します。

  4. [Advanced] ダイアログ ボックスの [継承可能なアクセス許可を親からこのオブジェクトに継承できるようにする] チェック ボックスをオフにします。

  5. OU のフル コントロールを保持させるグループを指定します。プロパティ シートの [セキュリティ] タブを使用して、これらのグループにフル コントロールを与えます。

  6. OU およびその内容の汎用の読み取りアクセス権を保持させるグループを指定します。プロパティ シートの [セキュリティ] タブを使用して、これらのグループに読み取りアクセス権を与えます。

  7. 特定クラスのオブジェクトを作成または削除する権限など、OU で特定のアクセス権を必要とする可能性のあるその他のグループを指定します。プロパティ シートの [セキュリティ] タブを使用して、これらのグループに特定のアクセス権を与えます。

  8. 隠すオブジェクトを OU に移動します。

この方法でオブジェクトを隠せるのは、OU の ACL を修正できるユーザーだけです。

グループ ポリシー用の OU を作成する

Windows NT 4.0 では、システム ポリシー エディタを使用して、ドメイン内のすべてのユーザーおよびコンピュータの構成を定義できました。Windows 2000 では、グループ ポリシーを使用して、ユーザーおよびコンピュータの構成を定義し、これらのポリシーをサイト、ドメイン、または OU に関連付けます。グループ ポリシーの適用をサポートするために OU を追加作成する必要があるかどうかは、作成するポリシーと選択する実装オプションによります。グループ ポリシーの詳細については、このマニュアルの「第 24 章 変更管理と設定管理」および「第 23 章 クライアントの管理標準や設定標準の決定」を参照してください。

展開後に OU 計画を変更する

新しい OU の作成、ドメイン内での OU サブツリーの移動、同じドメインの OU 間でのオブジェクトの移動、および OU の削除は、簡単な作業です。

オブジェクトまたはオブジェクトのサブツリーを移動すると、それらのオブジェクトの親コンテナが変わります。古い親から継承した ACE は適用されなくなり、新しい親から新しい ACE を継承することがあります。アクセスの予測外の変化を防ぐには、前もってどのような変化が起こるかを評価し、この変化が現在そのオブジェクトにアクセスおよび管理しているユーザーに影響を与えるかどうかを判断します。

ユーザー オブジェクト、コンピュータ オブジェクト、またはユーザーやコンピュータ オブジェクトを保持するサブツリーを移動すると、それらのオブジェクトに適用されているグループ ポリシーが変化します。クライアント構成の予測外の変化を防ぐには、グループ ポリシーの変化を評価し、エンド ユーザーの許容範囲内に留めます。

サイト トポロジ計画を作成する

Active Directory のサイト トポロジは、物理ネットワークの論理的表現です。サイト トポロジは、フォレストごとに定義されます。Active Directory クライアントおよびサーバーは、フォレストのサイト トポロジを使用して、照会および複製トラフィックを効率的にルーティングします。また、サイト トポロジは、ネットワークのどこにドメイン コントローラを配置するかを決定するときにも役立ちます。サイト トポロジを設計する際は、次の主な概念に留意してください。

サイトは、高速で信頼できる接続を持つネットワークのセットである。
高速で信頼できる接続で接続された IP サブネットのセットとして定義されています。通常、LAN 速度以上のネットワークは、高速ネットワークと見なされます。

サイト リンクは、 2 つ以上のサイトを接続する帯域幅の小さい、または信頼性の低いネットワークである。
サイト リンクは、2 つのサイト間で使用可能な帯域幅の容量をモデル化するときに使用します。一般に、LAN 速度より低速なリンクで接続された任意の 2 つのネットワークは、サイト リンクで接続されているものと見なされます。また、ほとんど容量に達している高速リンクも有効な帯域幅が少ないため、サイト リンクと見なすことができます。サイト リンクには、次の 4 つのパラメータがあります。

  • コスト

    サイト リンクのコスト値は、複製システムが他のリンクと比較してこのリンクをいつ使用するかを判断するときに役立ちます。コスト値によって、複製が経由するネットワーク パスが決まります。

  • 複製スケジュール

    サイト リンクには、リンクを複製トラフィックの伝送に使用できる時間帯を指定するスケジュールが関連付けられています。

  • 複製間隔

    複製間隔により、サイト リンクの反対側サイトのドメイン コントローラで複製の変更をポーリングする頻度が指定されます。

  • 転送

    複製に使用される転送。

クライアント コンピュータは、まずクライアントと同じサイトに配置されているサーバーとの通信を試みる。
ユーザーがクライアント コンピュータの電源を入れると、コンピュータは、クライアントがメンバーになっているドメインのランダムに選択したドメイン コントローラにメッセージを送信します。ドメイン コントローラは、クライアントの IP アドレスからクライアントが配置されているサイトを判断し、サイト名をクライアントに返します。クライアントは、この情報をキャッシュし、次回、サイト内に複製されたサーバーを検索するときに使用します。

Active Directory の複製は、サイト トポロジを使用して複製経路を生成する。
Knowledge Consistency Checker (KCC) は、ドメイン コントローラ間に複製経路を作成および維持する組み込みプロセスです。サイト トポロジ情報は、これらの経路の作成ガイドとして使用されます。サイト内の複製は、複製の待ち時間を最短にするように調整され、サイト間の複製は、帯域幅の使用を最小化するように調整されます。表 9.1 に、サイト内複製とサイト間複製の違いを示します。

9.1 サイト内複製とサイト間複製

サイト内複製

サイト間複製

プロセッサ時間を節約するため、複製トラフィックが圧縮されません。

帯域幅を節約するため、複製トラフィックが圧縮されます。

複製パートナーは、変更を複製する必要のあるときに相互に通知し、複製の待ち時間を短縮します。

複製パートナーは、変更を複製する必要のあるときでも相互に通知せず、帯域幅を節約します。

複製パートナーは、定期的に相互の変更をポーリングします。

複製パートナーは、スケジュールされた期間のみ、指定されたポーリング間隔で相互の変更をポーリングします。

複製には、リモート プロシージャ コール (RPC) 転送が使用されます。

複製には、TCP/IP または SMTP 転送が使用されます。

複製経路は、同じサイト内の任意の 2 つのドメイン コントローラ間に作成できます。
KCC は、複数のドメイン コントローラとの接続を確立し、複製の待ち時間を短縮します。

複製経路は、ブリッジヘッド サーバー間でのみ確立されます。
KCC により、サイト内の各ドメインの 1 つのドメイン コントローラがブリッジヘッド サーバーに指定されます。ブリッジヘッド サーバーは、そのドメインのすべてのサイト間複製を処理します。
KCC は、サイト リンク コストに従って、最もコストの低いルートでブリッジヘッド サーバー間に接続を確立します。コストの低いルートのどのドメイン コントローラにも到達できない場合にのみ、KCC はコストの高いルートで接続を確立します。

サイト トポロジ情報は、設定コンテナに格納される。
サイト、サイト リンク、およびサブネットは、すべて設定コンテナに格納され、このコンテナはフォレスト内のすべてのドメイン コントローラに複製されます。そのため、フォレスト内のすべてのドメイン コントローラは、サイト トポロジをすべて認識しています。サイト トポロジの変更は、フォレスト内のすべてのドメイン コントローラに複製されます。

メモ : サイト トポロジは、ドメイン階層とは別のもので無関係です。サイトには、多数のドメインを保持できるため、1 つのドメインが多数のサイトに現れることがあります。

サイト トポロジの計画プロセス

フォレストのサイト トポロジを作成するには、次の手順に従います。

  • 出発点として物理ネットワーク トポロジを使用して、サイトおよびサイト リンクを定義します。

  • サーバーをサイトに展開します。

  • 展開後にサイト トポロジを変更した場合のエンド ユーザーへの影響を理解します。

サイト トポロジ計画を作成するときには、ほとんどの場合、次の担当者に相談する必要があります。

  • ネットワークの TCP/IP の実装を管理および監視するチーム

  • フォレスト内の各ドメインのドメイン管理者

サイトおよびここで説明した内容の詳細については、『Distributed Systems Guide』を参照してください。

サイトおよびサイト リンクを定義する

フォレストのサイト トポロジを作成するには、ネットワークの物理トポロジを使用し、使用可能な帯域幅およびネットワークの信頼性に基づいて、さらに一般的なトポロジを作成します。

ドメイン計画を作成したときに物理的なパーティション化の実習を行っている場合には、サイト トポロジの出発点として作成したサイト トポロジおよびドメイン コントローラの展開計画を使用できます。この章の前に説明した物理パーティション化の実習を行っていない場合は、「各フォレストのドメイン数を決定する」を参照して、ここで基本的なサイト トポロジを作成することをお勧めします。

サイト トポロジを作成するときに、ネットワークの物理トポロジの完全なマップがあると便利です。このマップには、ネットワークの物理サブネットのリスト、各ネットワークのメディア タイプと速度、および各ネットワーク間の相互接続が含まれています。

サイトを作成する
まず、ネットワークのサイトのリストを作成します。

  • 高速なバックボーンで接続されている各 LAN または LAN のセットのサイトを作成し、名前を割り当てます。サイト内の接続は、信頼性が高く、常に使用可能でなければなりません。

  • ネットワークのその他の部分に直接接続されておらず、SMTP メールでのみアクセスできる場所ごとにサイトを作成します。

  • ローカル ドメイン コントローラを保持しないサイトを決め、これらのサイトを他の近隣のサイトにマージします。サイトは、クライアントからドメイン コントローラへのトラフィックおよびドメイン コントローラからドメイン コントローラへのトラフィックを効果的にルーティングするために役立ちます。サイトにドメイン コントローラがないと、このサイトに向かう複製トラフィックは制御されません。

計画に追加するサイトごとに、サイトを構成する IP サブネットのセットを記録します。この情報は、後でディレクトリ内にサイトを作成するときに必要になります。

メモ : サイト名は、ドメイン ロケータにより DNSに登録されるレコード内で使用されるため、基準に準拠した DNS 名でなければなりません。サイト名には、標準文字 A ~ Z、a ~ z、0 ~ 9、およびハイフン (–) だけを使用することをお勧めします。

クライアントは、他のサイトのドメイン コントローラとの通信を試みる前に、クライアントと同じサイトのドメイン コントローラと通信しようとします。ネットワーク間の帯域幅が常に大きく、特定のネットワーク上のクライアントが別のネットワークのサーバーと通信しても構わない場合には、これらのネットワークをすべて 1 つのサイトにすることを考慮してください。

クライアントがディレクトリで定義されていないサブネット上にある場合、サイトの一部とは見なされていないため、すべてのドメイン コントローラからランダムに特定ドメインを選択することになります。新しいサブネットがネットワークに追加されるなど、ディレクトリに定義されていないサブネットがある場合があります。これらのクライアントをサイトに関連付けるには、表 9.2 に示す 2 つの既定のサブネットを作成し、これをサイトに関連付けます。

9.2 既定のサブネット

サブネット ID

マスク

説明

128.0.0.0

192.0.0.0

ディレクトリに定義されていないクラス B ネットワーク上のクライアントをすべてキャプチャします。

192.0.0.0

224.0.0.0

ディレクトリに定義されていないクラス C ネットワーク上のクライアントをすべてキャプチャします。

クラス A ネットワーク上のクライアントには、既定のサブネットがありません。

特定の時間帯に負荷が大きくなり、それ以外の時間にアイドル状態になるリンクが 2 つのネットワークを分割する場合には、これらのネットワークを別々のサイトに展開します。サイト間の複製スケジュール機能を使用すると、負荷の大きい時間帯に複製トラフィックが他のトラフィックと競合するのを回避できます。

ネットワーク全体が高速で信頼できる接続で構成されている場合、ネットワーク全体を単一のサイトと見なすことができます。

サイトをサイト リンクで接続する
次に、ネットワークの物理接続を反映させて、サイトをサイト リンクで接続し、各サイト リンクに名前を割り当てます。

サイト リンクは変遷的なため、サイト A がサイト B に接続され、サイト B がサイト C に接続されている場合、KCC は、サイト A のドメイン コントローラがサイト C のドメイン コントローラと通信できるものと見なします。サイト A とサイト C 間に実際に異なるネットワーク接続がある場合、これらのサイト間にサイト リンクを作成するだけで済みます。

サイト リンクを作成するごとに、次の情報を作成して記録します。

  • 複製スケジュール

    複製のポーリングは、スケジュールされた期間または 7 日間おきの期間にのみ実行されます。既定のリンク スケジュールを使用すると、複製は 7 日間おきにポーリングされます。

  • 複製間隔

    複製のポーリングは、スケジュールにより複製が可能なると、指定された間隔で行われます。既定のポーリング 間隔は、3 時間です。

  • 複製の転送

    サイトに SMTP を介してのみ到達できる場合、SMTP 転送を選択します。それ以外の場合は、TCP/IP 転送を選択します。

  • リンク コスト

    使用可能な帯域幅または他のサイト リンクと比較した帯域幅のコストを反映させて、各リンク サイトにコスト値を割り当てます。

多数のサイトを接続するバックボーン ネットワークは、サイト間で網目状のリンクを作成しなくても、多数のサイトを接続する単一のサイト リンクで表現できます。多数のリンクが同じ特性を持つ場合に、作成および管理が必要なサイト リンクの数を減らすには、この方法が便利です。図 9.16 に、4 つのオフィスを接続するフレーム リレー ネットワークを、6 つの個々の網目状のリンクではなく、単一のリンクでどのように表現できるか示します。

sdgch917

図 9.16: 単一リンクと網目状のリンク

メモ : 複製スケジュールによって、ドメイン コントローラが複製パートナーの変更をポーリングするタイミングが決まります。複製サイクルの進行中にスケジュール済みのウィンドウを閉じた場合、複製は現在のサイクルが完了するまで継続されます。

図 9.17 に、Reskit 社のサイト トポロジを示します。サイトの名前付け規則では、地域コード、最短の空港コード、および識別番号が使用されています。サイト リンク名には、接続されているサイト名が含まれます。

sdgch918

図 9.17: Reskit 社のサイト トポロジ

表 9.3 に、Reskit のサイト トポロジの各サイト リンクのパラメータを示します。

9.3 Reskit 社のサイト トポロジのリンク パラメータ

サイト リンク

転送

コスト

ポーリング間隔

スケジュール

SEA01-YYZ14

SMTP

100

30 分

毎日 0500 ~ 0900 UTC

SEA01-CAI10

IP

100

30 分

毎日 2000 ~ 0400 UTC

SEA01-LHR03

IP

25

1 時間

(常時)

LHR03-CAI10

IP

50

15 分

毎日 2000 ~ 0400 UTC

製造工場と本社間のリンクでは、閑散時にのみ複製が行われるようにスケジュールされています。また、地方オフィスとその他のサイト間でも、閑散時にのみ複製が行われるようにスケジュールされています。地方オフィスとオペレーション センター間のリンク コストは、地方オフィスと本社間のコストよりも低いため、KCC は、本社のブリッジヘッドとの接続を確立する前に、オペレーション センターのブリッジヘッドとの接続を確立しようとします。本社とオペレーション センター間のリンクのスケジュールは、大きく開いていますが、トラフィックを軽減するため長いポーリング間隔が使用されています。

サーバーをサイトに展開する

サイト トポロジのサーバーの位置は、Active Directory の可用性に直接影響します。ドメイン計画の物理的なパーティション化の実習で、ドメイン コントローラの配置の基本計画を作成しました。サーバーをサイト トポロジに配置すると、この計画のディテールを完成できます。

追加ドメイン コントローラを展開する
パーティション化の実習で、各ドメインのドメイン コントローラをどのサイトに保持させるかを決めましたが、各ドメインの各サイトに配置するドメイン コントローラの数は決めませんでした。特定のドメイン用に作成するドメイン コントローラの数は、耐障害性の要件および負荷分散の要件の 2 つの要因から導き出されます。

ドメインごとに次のガイドラインに従って、ドメイン コントローラを追加する必要があるかどうかを判断します。

少なくとも 2 つのドメイン **コントローラを用意する。**ユーザー数の少ない小規模なドメインでも、1 か所の障害でドメインが故障しないように、少なくとも 2 つのドメイン コントローラを用意します。

ドメイン コントローラを 1 つだけ保持するサイトごとに、フェイルオーバーの実行に WAN **リンクを信頼するかどうかを判断する。**1 つのドメイン コントローラが故障しても、サイト内のクライアントは、他のサイトに配置されているそのドメインの他のドメイン コントローラからサービスを受けることができます。ネットワークの接続を信頼できないか、断続的にしか使用できない場合には、フェイルオーバーの処理にネットワークを信頼したくない場合があります。この場合、サイト内にそのドメインの 2 つ目のドメイン コントローラを配置します。

ドメインの追加ドメイン **コントローラは、クライアントの作業負荷を処理するサイトに配置する。**特定のサーバーが処理できるクライアント数は、作業負荷の特性およびサーバーのハードウェア構成によって異なります。クライアントは、サイト内の使用可能なドメイン コントローラからランダムに選択して、クライアントの負荷を均等に分散します。

グローバル カタログ サーバーを展開する
グローバル カタログ サーバーの可用性は、ディレクトリの運用に不可欠です。たとえば、ネイティブモード ドメインへのユーザーのログオン要求を処理する場合、またはユーザーがプリンシパル名でログオンする場合には、グローバル カタログが使用できる状態になければなりません。

メモ : ドメイン コントローラは、ネイティブモード ドメインのユーザーのログオン要求を処理するときに、グローバル カタログ サーバーに照会を送信して、ユーザーのユニバーサル グループ メンバーシップを判断します。グループによるリソースへのアクセスは明示的に拒否できるため、アクセスを正しく制御できるように、ユーザーのグループ メンバーシップをすべて認識していることが必要になります。ユーザーがログオンしようとしたときに、ネイティブモード ドメインのドメイン コントローラがグローバル カタログ サーバーに問い合わせできないと、ドメイン コントローラはログオン要求を拒否します。

一般に、各サイトの少なくとも 1 つのドメイン コントローラをグローバル カタログ サーバーに指定します。

個々のドメイン コントローラに使用したものと同じフェイルオーバーおよび負荷分散規則を使用して、各サイトにグローバル カタログ サーバーを追加する必要があるかどうかを判断します。

メモ : 単一ドメイン環境では、ユーザーのログオン要求の処理にグローバル カタログ サーバーは必要ありませんが、提示したプロセスを使用して、グローバル カタログ サーバーを指定してください。このような環境でも、クライアントは検索操作のためにグローバル カタログ サーバーを探します。また、既に運用しているグローバル カタログ サーバーがある場合には、後でドメインを追加しても、システムはスムーズに適応します。

DNS サーバーを展開する
DNS の可用性は、Active Directory の可用性に直接影響します。クライアントはドメイン コントローラを検索するときに DNS に依存し、ドメイン コントローラは他のドメイン コントローラを検索するときに DNS に依存します。既にネットワークに配置されている DNS サーバーがある場合でも、Active Directory クライアントおよびドメイン コントローラの必要性に応じて、サーバー数および配置の調整が必要なことがあります。

一般に、各サイトに少なくとも 1 台の DNS サーバーを配置します。サイト内の DNS サーバーは、クライアントがサイト内のドメイン コントローラを検索するときに、サイト外の DNS サーバーを照会せずに済むように、サイト内のドメインのロケータ レコードに対する権限を保持していなければなりません。また、ドメイン コントローラは、各ロケータ レコードのプライマリ マスタ サーバーのエントリが正しいかどうかを定期的に確認します。

すべての条件を満たす簡単な構成方法は、Active Directory に統合されている DNS を使用し、ドメインのロケータ レコードをドメイン自体に格納し、これらのドメイン コントローラが現れる各サイトの 1 つ以上のドメイン コントローラで Windows 2000 の DNS サービスを実行することです。

フォレスト全体のロケータ レコードを分散する
フォレスト内の各ドメイン コントローラは、<DNS-domain-name> で終わるドメイン特有のレコード セットおよび_msdcs.<DNS-forest-name>で終わるフォレスト全体のレコード セットの 2 つのロケータ レコードを登録します。フォレスト全体のレコードは、フォレストのあらゆる部分のクライアントおよびドメイン コントローラに重要です。たとえば、グローバル カタログのロケータ レコード、および複製システムが複製パートナーの検索に使用するレコードは、フォレスト全体のレコードに含まれます。

任意の 2 つのドメイン コントローラが、同じドメインの 2 つのドメイン コントローラを含み相互に複製する場合、フォレスト全体のロケータ レコードを参照できなければなりません。また、新しく作成されたドメイン コントローラが複製に参加するには、そのフォレスト全体のレコードを DNS で登録できなければならず、その他のドメイン コントローラがこれらのレコードを参照できなければなりません。そのため、すべてのサイトのすべての DNS サーバーでフォレスト全体のロケータ レコードを使用できるようにすることが重要です。

これを行うには、_msdcs.<DNS-forest-name> という別のゾーンを作成して、このゾーンをすべての DNS サーバーに複製します。Active Directory に統合されている単純な構成を使用する場合、このゾーンのプライマリ コピーを <DNS-forest-name> ゾーンと一緒にフォレスト ルート ドメインに配置できます。こうすることにより、標準の DNS の複製を使用して、ゾーンをこのドメイン外の DNS サーバーに複製できます。

一般に、サイトあたり 1 台の DNS サーバーにゾーンを複製するだけでは十分ではありません。DNS サーバーに _msdcs.<DNS-forest-name> ゾーンのローカル コピーがない場合、DNS 再帰を使用してそのゾーン内の名前を参照しなければなりません。DNS サーバーが再帰を実行するには、ネームスペース (DNS ルート サーバー) のルートに対する権限を保持する DNS サーバーに問い合わせ、問題のレコードを見つけるまで DNS 内の委任を下っていきます。サイトに DNS ルート サーバーがなく、このサイトと他のサイト間のリンクがダウンしている場合には、DNS サーバーは再帰を実行できません。つまり、DNS サーバーが同じサイト内にあっても、_msdcs.<DNS-forest-name> に対する権限を保持する DNS サーバーを見つけることができません。

DNS クライアントの構成
クライアントおよびドメイン コントローラは、適切なローカル サーバーおよび代替サーバーの少なくとも 2 台の DNS サーバーの IP アドレスで構成されていなければなりません。代替サーバーは、ローカル サイトにあっても、フェイルオーバーの処理にネットワークを信頼している場合にはリモートにあってもかまいません。

展開後にサイト トポロジを変更する

フォレストのサイト トポロジは柔軟で、配置後でも簡単に変更できます。物理ネットワークが発展したときには、サイト トポロジを評価して、調整してください。ネットワークを変更したため、帯域幅や信頼性が向上または低下した場合は、サイトおよびサイト リンクを作成または削除して、複製の待ち時間と帯域幅の使用のバランスが取れるようにサイト リンク パラメータを調整してください。

サイト トポロジを変更する前に、変更による可用性、複製の待ち時間、および複製帯域幅への影響と、エンド ユーザーへの影響を認識しておきます。サイト トポロジは、設定コンテナに格納されるため、変更は、フォレスト内のすべてのドメイン コントローラに複製されます。サイト トポロジを頻繁に変更すると、大量の複製トラフィックが発生します。このため、サイト トポロジを変更する場合は、小さい変更を何回も行うのではなく、大きい変更を数回だけ行ってください。複製トポロジおよびスケジュールによって、サイト トポロジの変更がフォレスト内のすべてのドメイン コントローラに到達するまで時間がかかることがあります。

Active Directory 構造を設計するための作業リストを計画する

表 9.4 をチェックリストとして使用して、Active Directory 構造の設計に必要な基本的作業をすべて実行します。

9.4 Active Directory の計画作業リスト

作業

この章の参照場所

フォレスト数を判断する。

「フォレスト計画を作成する」

各フォレストの変更制御ポリシーを作成する。

「フォレスト計画を作成する」

各フォレストのドメイン数を判断する。

「ドメイン計画を作成する」

フォレスト ルート ドメインを選択する。

「ドメイン計画を作成する」

各ドメインに DNS 名を割り当てる。

「ドメイン計画を作成する」

DNS サーバーの展開を計画する。

「ドメイン計画を作成する」

ショートカット信頼関係で認証を最適化する。

「ドメイン計画を作成する」

管理権限を委任するための OU を作成する。

「組織単位計画を作成する」

オブジェクトを隠すための OU を作成する。

「組織単位計画を作成する」

グループ ポリシー用の OU を作成する。

「組織単位計画を作成する」

サイトおよびサイト リンクを定義する。

「サイト トポロジ計画を作成する」

サーバーをサイトに展開する。

「サイト トポロジ計画を作成する」