Directoryの導入を成功させるため、今回はフォレストの構造やサイトの設計について解説する。Serverを対象とした連載です。2003向けの連載は以下のリンクから参照できます。Directoryにおける最大の管理単位となるため、慎重に検討して設計する必要がある。組織の中で、複数のフォレストが必要かどうかを検討する。できれば1つの組織では1つのフォレストにとどめておくことが望ましい。その理由は、「グローバル・カタログ(GC)」が利用できる範囲がフォレスト内に限定されることと(GCにはドメイン内のオブジェクトから頻繁に利用されるものが抽出され、複製・保持されている。Directoryにおける検索は、このGCを対象に行われる)、後で複数のフォレストを1つのフォレストにまとめるということが簡単にはできないからだ。Directoryにおける最大の管理単位であり、フォレスト内には複数のドメインが含まれる。フォレストの構成には、すべてのドメインを1つのフォレストにするシングル・フォレストと、複数のフォレストに分けるマルチ・フォレストの2種類がある。このようにフォレストの構成としては、すべてのドメインを1つのフォレストにする「シングル・フォレスト」と、複数のフォレストに分ける「マルチ・フォレスト」の2種類がある。同一フォレスト内のドメインはすべて「推移する信頼関係*1」が結ばれるが、複数フォレストの場合は、管理者が手動で信頼関係を結ぶ必要がある。この場合は、一方向だけで、推移しない信頼関係となる。Directoryの計画立案時に慎重に決定しておく必要があるが、特別な理由がない限り、1つの組織ではシングル・フォレストにするのが望ましい。relationship)とは、例えば、ドメインAとドメインBが信頼関係を結び、ドメインBとドメインCが信頼関係を結んでいると、自動的にAとCの間にも信頼関係が成立する、ということを意味している。フォレスト内のドメイン間には自動的に双方向の推移する信頼関係が結ばれ、ドメインの資源をお互いに利用することができる。異なるフォレストではこのような自動的な信頼関係は結ばれない。どのような場合にフォレストを分ける必要があるのだろうか。Directoryの概要(1)」や連載第3回の「フォレスト」で解説した、「同一フォレストに参加するドメインはすべて推移する信頼関係が結ばれる」という特徴を思い出していただきたい。Directoryのフォレスト内のドメイン間では自動的に信頼関係が結ばれ、かつ、その信頼関係は削除することはできない。このため信頼関係を結びたくないドメインが存在する場合、フォレストを分けてそれぞれのドメインを構築する。複数フォレストを後から結合することはできないため、別フォレストの資源を利用したい場合には、ドメイン間で管理者が手動で信頼関係を設定する必要がある。このとき設定できる信頼関係は「NTレベルの信頼関係(推移しない、一方向のみの信頼関係)」となる。第2に、同一フォレストでは共通の「スキーマ」を使うことを理解してほしい。スキーマ構造を分けたい場合には、フォレストを分ける必要がある。2000など)の中には、アプリケーションのインストール時にスキーマを拡張するものがある。組織によっては、独自にスキーマを拡張して利用することもあるだろう。スキーマの拡張はフォレスト全体に複製されるため、それらの影響を受けたくないドメインがある場合には、別フォレストとして構成しておくべきである。Directory統合アプリケーション(スキーマを拡張するアプリケーション)を使うかどうかも重要な要素となる。最後に、グローバル・カタログ(GC)の有効範囲が同一フォレストに限られることを覚えておいてほしい。GCを使えば、複数ドメインの情報を簡単に検索できるが、異なるフォレストまで検索することはできない。検索ポイントが複数になってしまうのだ。以上のような点を考慮して、シングル・フォレストにするか、マルチ・フォレストにするかを決定していただきたい。ドメインの検討フォレスト構造が決定したら、次にドメインの構成やその数を決める。ドメインを分ける要因としては、次のようなものがある。■パスワード・ポリシーなどのセキュリティ設定を適用する範囲を分けたいアカウント・ポリシーやパスワード・ポリシーはドメイン単位で適用される。同一ドメイン内で、これらを分けることはできないため、ドメインを分けてそれぞれのドメインに適切なポリシーを割り当てることができる。組織内に新製品を開発する部門があり、その部門で扱う情報はセキュリティ保護の強度を高め、パスワードの長さを10文字以上に設定させる。ほかの部門のユーザーまで長いパスワードを必須にしてしまうと、パスワードを忘れてしまうなどのトラブルが生じるため、6文字程度の制限にとどめたいとする。このような場合には、開発部門(高いセキュリティが必要な部門)のドメインは独立させ、セキュリティの強度を分けると良いだろう。■ドメイン・コントローラ間の複製処理でドメイン・パーティションを複製したくない範囲があるディレクトリに格納されている情報には「スキーマ」「構成」「ドメイン」という3つのパーティション(カテゴリ、分類)がある。Directoryデータベース内のパーティションのことである。ドメイン・パーティションのデータは、ドメイン内のすべてのドメイン・コントローラに複製されるため、たとえサイトを分けて構成していたとしても、ドメイン・コントローラ間でのデータの複製がなくなるわけではない。低速なWAN回線を介する複製データの全体量を軽減したい場合には、ドメインも分けるのがよい。Directoryの導入によって管理モデルを変更する手間をかけたくないなら、ドメインを分ける価値がある。Directoryに移行するからといって、無理に既存の管理部門を統合したり、管理モデルを変更したりする必要はない。変更することによって、かえって余分な管理業務が発生し、コストがかさんでしまうこともある。Directoryの運用をしていくのがよいだろう。■ドメイン単位の管理者を分散したいドメインの範囲はセキュリティの境界でもある。ドメインの管理は明示的なアクセス許可を割り当てない限り、ドメインの境界を越えてほかのドメインを管理することはできない。Adminsという特別なグループのメンバーとなり、自動的に全ドメインの管理権限を持つ。そのため、完全に管理権限を分離したい場合は、別フォレストにしなければならない。マルチ・ドメイン環境を構成する要素ディレクトリに格納されている情報には「スキーマ」「構成」「ドメイン」という3つのパーティション(分類)がある。ドメイン・パーティションはドメイン内でのみ複製されるが、「スキーマ・パーティション」と「構成パーティション」はフォレスト内の全ドメインに複製される。そのため、WAN回線を介する複製データの全体量を軽減したい場合には、ドメインも分けて、ドメイン・パーティションの複製を抑えるのがよい。ドメインを分けると、ポリシーの適用範囲を限定したり、管理単位を分散・委任したりすることができる。上記のほかにも、海外に拠点がある場合には、国によっては導入できない暗号化レベルなどがあるため(強度の高い暗号化技術を輸出できないなど)、その国の法的な問題にも注意する必要がある。メールマガジンをご購読ください。申し込みページへITmediaはアイティメディア株式会社の登録商標です。