第6回 Active Directoryの導入準備(後編)管理者のためのActive Directory入門(1/2 ページ)

Active Directoryの導入を成功させるため、今回はフォレストの構造やサイトの設計について解説する。

» 2002年12月26日 00時00分 公開
[伊藤将人(株)コメット]
運用
Windows Server Insider

 

「運用」のインデックス

連載目次

本稿は、Windows 2000 Serverを対象とした連載です。Windows Server 2003向けの連載は以下のリンクから参照できます。


 「フォレスト」はActive Directoryにおける最大の管理単位となるため、慎重に検討して設計する必要がある。まず組織の中で、複数のフォレストが必要かどうかを検討する。できれば1つの組織では1つのフォレストにとどめておくことが望ましい。その理由は、「グローバル・カタログ(GC)」が利用できる範囲がフォレスト内に限定されることと(GCにはドメイン内のオブジェクトから頻繁に利用されるものが抽出され、複製・保持されている。Active Directoryにおける検索は、このGCを対象に行われる)、後で複数のフォレストを1つのフォレストにまとめるということが簡単にはできないからだ。

シングル・フォレストとマルチ・フォレストの比較
フォレストはActive Directoryにおける最大の管理単位であり、フォレスト内には複数のドメインが含まれる。フォレストの構成には、すべてのドメインを1つのフォレストにするシングル・フォレストと、複数のフォレストに分けるマルチ・フォレストの2種類がある。

 このようにフォレストの構成としては、すべてのドメインを1つのフォレストにする「シングル・フォレスト」と、複数のフォレストに分ける「マルチ・フォレスト」の2種類がある。同一フォレスト内のドメインはすべて「推移する信頼関係*1」が結ばれるが、複数フォレストの場合は、管理者が手動で信頼関係を結ぶ必要がある。ただしこの場合は、一方向だけで、推移しない信頼関係となる。どちらにするかはActive Directoryの計画立案時に慎重に決定しておく必要があるが、特別な理由がない限り、1つの組織ではシングル・フォレストにするのが望ましい。

*1 「推移する信頼関係(transitive trust relationship)とは、例えば、ドメインAとドメインBが信頼関係を結び、ドメインBとドメインCが信頼関係を結んでいると、自動的にAとCの間にも信頼関係が成立する、ということを意味している。フォレスト内のドメイン間には自動的に双方向の推移する信頼関係が結ばれ、ドメインの資源をお互いに利用することができる。異なるフォレストではこのような自動的な信頼関係は結ばれない。


 では、どのような場合にフォレストを分ける必要があるのだろうか。

 第1に、連載第1回の「Active Directoryの概要(1)」や連載第3回の「フォレスト」で解説した、「同一フォレストに参加するドメインはすべて推移する信頼関係が結ばれる」という特徴を思い出していただきたい。NTドメインでは、管理者が信頼関係を結びたいドメインだけを指定して、それらの間に信頼関係を設定することができたが、Active Directoryのフォレスト内のドメイン間では自動的に信頼関係が結ばれ、かつ、その信頼関係は削除することはできない。このため信頼関係を結びたくないドメインが存在する場合、フォレストを分けてそれぞれのドメインを構築する。複数フォレストを後から結合することはできないため、別フォレストの資源を利用したい場合には、ドメイン間で管理者が手動で信頼関係を設定する必要がある。このとき設定できる信頼関係は「NTレベルの信頼関係(推移しない、一方向のみの信頼関係)」となる。

 第2に、同一フォレストでは共通の「スキーマ」を使うことを理解してほしい。スキーマ構造を分けたい場合には、フォレストを分ける必要がある。Active Directoryと統合して使うようなアプリケーション(例えばExchange 2000 ServerやISA Server 2000など)の中には、アプリケーションのインストール時にスキーマを拡張するものがある。また組織によっては、独自にスキーマを拡張して利用することもあるだろう。スキーマの拡張はフォレスト全体に複製されるため、それらの影響を受けたくないドメインがある場合には、別フォレストとして構成しておくべきである。このように、フォレスト構造を設計する場合にはActive Directory統合アプリケーション(スキーマを拡張するアプリケーション)を使うかどうかも重要な要素となる。

 最後に、グローバル・カタログ(GC)の有効範囲が同一フォレストに限られることを覚えておいてほしい。GCを使えば、複数ドメインの情報を簡単に検索できるが、異なるフォレストまで検索することはできない。つまり、検索ポイントが複数になってしまうのだ。

 以上のような点を考慮して、シングル・フォレストにするか、マルチ・フォレストにするかを決定していただきたい。

ドメインの検討

 フォレスト構造が決定したら、次にドメインの構成やその数を決める。ドメインを分ける要因としては、次のようなものがある。

■パスワード・ポリシーなどのセキュリティ設定を適用する範囲を分けたい
 アカウント・ポリシーやパスワード・ポリシーはドメイン単位で適用される。同一ドメイン内で、これらを分けることはできないため、ドメインを分けてそれぞれのドメインに適切なポリシーを割り当てることができる。

 例えば、組織内に新製品を開発する部門があり、その部門で扱う情報はセキュリティ保護の強度を高め、パスワードの長さを10文字以上に設定させる。しかし、ほかの部門のユーザーまで長いパスワードを必須にしてしまうと、パスワードを忘れてしまうなどのトラブルが生じるため、6文字程度の制限にとどめたいとする。このような場合には、開発部門(高いセキュリティが必要な部門)のドメインは独立させ、セキュリティの強度を分けると良いだろう。

■ドメイン・コントローラ間の複製処理でドメイン・パーティションを複製したくない範囲がある
 ディレクトリに格納されている情報には「スキーマ」「構成」「ドメイン」という3つのパーティション(カテゴリ、分類)がある。ドメイン・パーティションとは、ドメイン内のオブジェクト情報すべてを含む、Active Directoryデータベース内のパーティションのことである。

 ドメイン・パーティションのデータは、ドメイン内のすべてのドメイン・コントローラに複製されるため、たとえサイトを分けて構成していたとしても、ドメイン・コントローラ間でのデータの複製がなくなるわけではない。低速なWAN回線を介する複製データの全体量を軽減したい場合には、ドメインも分けるのがよい。

■NTドメインの構造(管理モデル)をそのままActive Directoryに移行したい
 すでにNTドメインが構築されていて、ドメイン単位の管理者が効率的な管理モデルを構成している場合や、Active Directoryの導入によって管理モデルを変更する手間をかけたくないなら、ドメインを分ける価値がある。

 Active Directoryに移行するからといって、無理に既存の管理部門を統合したり、管理モデルを変更したりする必要はない。変更することによって、かえって余分な管理業務が発生し、コストがかさんでしまうこともある。現段階で複数のNTドメイン環境をスムーズな運用ができているのであれば、そのままの管理モデルでActive Directoryの運用をしていくのがよいだろう。

■ドメイン単位の管理者を分散したい
 ドメインの範囲はセキュリティの境界でもある。ドメインの管理は明示的なアクセス許可を割り当てない限り、ドメインの境界を越えてほかのドメインを管理することはできない。

 ただし、フォレスト・ルート・ドメインの管理者はEnterprise Adminsという特別なグループのメンバーとなり、自動的に全ドメインの管理権限を持つ。そのため、完全に管理権限を分離したい場合は、別フォレストにしなければならない。

マルチ・ドメイン環境を構成する要素
ディレクトリに格納されている情報には「スキーマ」「構成」「ドメイン」という3つのパーティション(分類)がある。ドメイン・パーティションはドメイン内でのみ複製されるが、「スキーマ・パーティション」と「構成パーティション」はフォレスト内の全ドメインに複製される。そのため、WAN回線を介する複製データの全体量を軽減したい場合には、ドメインも分けて、ドメイン・パーティションの複製を抑えるのがよい。またドメインを分けると、ポリシーの適用範囲を限定したり、管理単位を分散・委任したりすることができる。

 上記のほかにも、海外に拠点がある場合には、国によっては導入できない暗号化レベルなどがあるため(強度の高い暗号化技術を輸出できないなど)、その国の法的な問題にも注意する必要がある。

関連リンク:


       1|2 次のページへ

Copyright© Digital Advantage Corp. All Rights Reserved.

スポンサーからのお知らせPR

注目のテーマ

Microsoft & Windows最前線2025
AI for エンジニアリング
ローコード/ノーコード セントラル by @IT - ITエンジニアがビジネスの中心で活躍する組織へ
Cloud Native Central by @IT - スケーラブルな能力を組織に
システム開発ノウハウ 【発注ナビ】PR
あなたにおすすめの記事PR

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。