第6回 Active Directoryの導入準備（後編）：改訂 管理者のためのActive Directory入門 （Windows Server 2003対応改訂版）（1/2 ページ）
AD導入準備の後編。今回は、フォレスト構造やサイト設計を中心に解説。何をフォレストにし、何をドメインにすべきか。
本稿は、Windows 2000 Serverを対象として、2002年9月より連載を開始した「管理者のためのActive Directory入門」を元に、Windows Server 2003向けの情報を追加し、改訂したものです。以前の連載は、以下のリンクから参照できます。
今回は前回に引き続き、Active Directoryを実際に導入するに当たっての準備について、フォレスト構造やサイト設計を中心に解説する。
フォレスト構造の検討
フォレストはActive Directoryにおける最大の管理単位となるため、慎重に検討して設計する必要がある。まず、組織の中で複数のフォレストが必要かどうかを検討する。できれば、1つの組織では1つのフォレストにとどめておくことが望ましい。その理由は、グローバル・カタログ（GC）が利用できる範囲がフォレスト内に限定されることと（GCにはドメイン内のオブジェクトから頻繁に利用されるものが抽出され、複製・保持されている。Active Directoryにおける検索は、このGCを対象に行われる）、後で複数のフォレストを1つのフォレストにまとめるということが簡単にはできないからだ。
シングル・フォレストとマルチ・フォレストの比較フォレストはActive Directoryにおける最大の管理単位であり、フォレスト内には複数のドメインが含まれる。フォレストの構成には、すべてのドメインを1つのフォレストにするシングル・フォレストと、複数のフォレストに分けるマルチ・フォレストの2種類がある。
このようにフォレストの構成としては、すべてのドメインを1つのフォレストにするシングル・フォレストと、複数のフォレストに分けるマルチ・フォレストの2種類がある。同一フォレスト内のドメインはすべて推移する信頼関係が結ばれるが、複数フォレストの場合は、管理者が手動で信頼関係を結ぶ必要がある。ただしこの場合は、一方向だけで、推移しない信頼関係となる。どちらにするかはActive Directoryの計画立案時に慎重に決定しておく必要があるが、特別な理由がない限り、1つの組織ではシングル・フォレストにするのが望ましい。
では、どのような場合にフォレストを分ける必要があるのだろうか。
第1に、「第3回 Active Directory関連用語集（前編）」で解説した、「同一フォレストに参加するドメインはすべて推移する信頼関係が結ばれる」という特徴を思い出していただきたい。NTドメインでは、管理者が信頼関係を結びたいドメインだけを指定して、それらの間に信頼関係を設定することができたが、Active Directoryのフォレスト内のドメイン間では自動的に信頼関係が結ばれ、かつ、その信頼関係は削除することはできない。このため信頼関係を結びたくないドメインが存在する場合、フォレストを分けてそれぞれのドメインを構築する。複数のフォレストを後から結合することはできないため、別フォレストの資源を利用したい場合には、ドメイン間で管理者が手動で信頼関係を設定する必要がある。このとき設定できる信頼関係は「NTレベルの信頼関係（推移しない、一方向のみの信頼関係）」となる。
第2に、同一フォレストでは共通のスキーマ（詳細は第3回を参照）を使うことを理解してほしい。スキーマの構造を分けたい場合には、フォレストを分ける必要がある。Active Directoryと統合して使うようなアプリケーション（例えばExchange ServerやISA Server、Live Communication Serverなど）は、アプリケーションのインストール時にスキーマを拡張するものが多い。スキーマの拡張はフォレスト全体に複製されるため、それらの影響を受けたくないドメインがある場合には、別フォレストとして構成しておくべきである。このように、フォレスト構造を設計する場合にはActive Directory統合アプリケーション（スキーマを拡張するアプリケーション）を使うかどうかも重要な要素となる。
最後に、GCの有効範囲が同一フォレストに限られることを覚えておいてほしい。GCを使えば、複数のドメインの情報を簡単に検索できるが、異なるフォレストまで検索することはできない。つまり、検索ポイントが複数になってしまうことになる。
以上のような点を考慮して、シングル・フォレストにするか、マルチ・フォレストにするかを決定していただきたい。
ドメインの検討
フォレスト構造が決定したら、次にドメインの構成やその数を決める。ドメインを分ける要因としては、次のようなものがある。
■パスワード・ポリシーなどのセキュリティ設定を適用する範囲を分けたい
アカウント・ポリシーやパスワード・ポリシーはドメイン単位で適用される。同一ドメイン内でこれらを分けることはできない。ドメインを分ければ、それぞれのドメインに適切なポリシーを割り当てることができる。
例えば、組織内に新製品を開発する部門があり、その部門で扱う情報はセキュリティ保護の強度を高め、パスワードの長さを10文字以上に設定させる。しかし、ほかの部門のユーザーまで長いパスワードを必須にしてしまうと、パスワードを忘れてしまうなどのトラブルが生じるため、6文字程度の制限にとどめたいとする。このような場合には、開発部門（高いセキュリティが必要な部門）のドメインは独立させ、セキュリティの強度を分けるとよいだろう。
■DC間の複製処理でドメイン・パーティションを複製したくない範囲がある
ディレクトリ・データベースに格納されている情報には「スキーマ」「構成」「ドメイン」という3つのパーティション（分類）がある（ほかに「アプリケーション」パーティションもあるが、Active Directory用のパーティションではないのでここでは省略する）。ドメイン・パーティションとは、ドメイン内のオブジェクト情報すべてを含む、Active Directoryデータベース内のパーティション（カテゴリ）のことである。
ドメイン・パーティションのデータは、ドメイン内のすべてのドメイン・コントローラ（DC）に複製されるため、たとえサイトを分けて構成していたとしても、DC間でのデータの複製がなくなるわけではない。低速なWAN回線を介する複製データの全体量を軽減したい場合には、ドメインも分けるのがよい。
■NTドメインの構造（管理モデル）をそのままActive Directoryに移行したい
すでにNTドメインが構築されていて、ドメイン単位の管理者が効率的な管理モデルを構成している場合や、Active Directoryの導入によって管理モデルを変更する手間をかけたくないなら、ドメインを分ける価値がある。
Active Directoryに移行するからといって、無理に既存の管理部門を統合したり、管理モデルを変更したりする必要はない。変更することによって、かえって余分な管理業務が発生し、コストがかさんでしまうこともある。現段階で複数のNTドメイン環境でスムーズな運用ができているのであれば、そのままの管理モデルでActive Directoryの運用をしていくのがよいだろう。
■ドメイン単位の管理者を分散したい
ドメインの範囲はセキュリティの境界でもある。ドメインの管理は明示的なアクセス許可を割り当てない限り、ドメインの境界を越えてほかのドメインを管理することはできない。
ただし、フォレスト・ルート・ドメインの管理者はEnterprise Adminsという特別なグループのメンバーとなり、自動的に全ドメインの管理権限を持つ。そのため、完全に管理権限を分離したい場合は、別フォレストにしなければならない。
マルチ・ドメイン環境を構成する要素ディレクトリ・データベースに格納されている情報には「スキーマ」「構成」「ドメイン」という3つのパーティション（分類）がある。ドメイン・パーティションはドメイン内でのみ複製されるが、スキーマ・パーティションと構成パーティションはフォレスト内の全ドメインに複製される。そのため、WAN回線を介する複製データの全体量を軽減したい場合には、ドメインも分けて、ドメイン・パーティションの複製を抑えるのがよい。またドメインを分けると、ポリシーの適用範囲を限定したり、管理単位を分散・委任したりすることができる。
上記のほかにも、海外に拠点がある場合には、国によっては導入できない暗号化レベルなどがあるため（強度の高い暗号化技術を輸出できないなど）、その国の法的な問題にも注意する必要がある。
サイトの検討
NTドメインでは、「サイト」という地理的な要因（WAN回線で接続された離れた場所なのでトラフィックを抑えたい、などの要求）を管理することはできなかった。一部レジストリを修正することによって、複製周期などを変更することはできたが、そのような設定はDC単位で行う必要があり、面倒な作業であった。Active Directoryのサイトは、既存のNTドメインとは関係なく、独立して設計できる。
サイトを定義する場合には、高速で安定した通信が行える範囲を1つのサイトとして定義する必要がある。簡単にいえば、1つのLAN（拠点）として構築されたネットワークをサイトとして定義すればよいだろう。サイトにはIPサブネットを割り当てる。複数のIPサブネットを同一サイトに割り当てることもできるため、同一拠点が複数のサブネットに分かれていてもよい。これとは逆に、1つのサブネットを複数のサイトに分けることはできない。
サイト構造サイトとは、組織内の物理的なネットワーク接続を示すためのオブジェクトである。ドメインの論理的な構造とは関係なくサイトを定義することができる。一般的には、高速で安定した通信が行える範囲、つまり1つのLANとか、1つのIPサブネットを単位としてサイトを定義する。
関連リンク
Copyright© Digital Advantage Corp. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。