|
今回はActive Directoryに出てくる様々な論理構造について勉強しよう。Active Directoryというと，様々な概念が階層構造を成して，なにやら複雑な印象を受ける。元々，複雑な管理対象を，スッキリ管理するために階層構造を導入しているのだが，逆に高度な機能を無理に使おうとして，現実のシステムを複雑に考えてしまうのだ。 Active Directoryの運用は，2段階のステップに分けて考えるといいだろう。最初のステップは，Windows NTドメインと同じような単なるユーザー認証機能だけの運用形態であり，2番目のステップがActive Directory固有の階層構造を利用した運用形態である。 Active Directoryの登場当初は，Active Directoryの優位性を強調するあまり，最初のステップであるWindows NTと同様の（単純な）管理形態については語られることが少なかったように思う。しかし，実際には，Windows NTと同様，ドメイン全体をひとまとめにして，階層を作らないという選択肢もある。今回は，Active Directory固有の論理構造を紹介するが，必ずしも作らなくてもよい構造も含まれる。あくまで，惑わされないための勉強である。Active Directoryの機能を十分に知るためにも，階層構造の概要だけはぜひ理解しておいてほしい。
Active Directoryの管理単位はドメインだけでない このような大規模なドメインをサポートできるようになった結果，単一の組織で複数ドメインを構築する必然性はなくなった。さらに，管理権限を部門に委任するために，ドメイン内部をより細かな単位「組織単位（OU：Organizational Unit）」に分割し，階層管理できるようになった。OUは使っても使わなくても構わないが，大規模なドメインを管理するには必須の機能である。 さらに（ユーザー数の問題ではなく，その他の管理上の問題で），ドメインを分割したい場合に備え，「ツリー」や「フォレスト」といった，ドメイン間階層を作成できる。 このように，Active Directoryでは，ドメイン内とドメイン間の両方に階層管理の概念を導入した。大規模な情報を管理する基本は，階層構造なのである。
ドメイン間の階層を形成するドメイン・ツリーとフォレスト
ドメイン同士がお互いに関係して“木”や“森”を形作るというのは，どういう関係なのかというと，まず，ドメイン・ツリーを構成するドメインは，前回解説したDNS名前空間が連続していなければならない。一方，フォレストを構成するドメイン・ツリー同士には，DNS名前空間の制限はない。その結果，一般にフォレストは（ 図1のような構成になる。フォレストは，Active Directoryの管理権限が及ぶ最も大きな範囲である。 フォレストは1つ以上のドメイン・ツリーで構成される。つまり，複数のドメイン・ツリーで構成されることもあれば，1つのドメイン・ツリーでも1つのフォレストになり得るということだ。さらに，ドメイン・ツリー内には1つ以上の「ドメイン」が含まれる。つまりこれもまた，1つのドメインだけで1つのドメイン・ツリーになる。ということは，1つのドメインだけしかなければ，それは1つのドメイン・ツリー，1つのフォレストとみなせる。既に述べた通り，単一ドメインでもツリーを構成するとみなすが，実際には親ドメインと子ドメインが存在する場合を「ドメイン・ツリー」と呼ぶことが多い。 実際には，最初のドメイン・コントローラ（Active Directoryデータベースを保持するコンピュータ）が構成したドメインは，最初のフォレストを構成するとともに，最初のドメイン・ツリーでもある。このドメインを「フォレスト・ルート・ドメイン」と呼ぶ。 ドメイン・ツリーを大きく（枝を伸ばす）場合は，子ドメインを追加する。また，ドメイン・ツリー自体を追加する場合は，2つ目のドメイン・ツリーのもととなる（ドメイン・ツリーの最上位の）ドメインを追加する。こうして管理範囲であるフォレストの領域を広げていくわけだ。 ただし，既に構築されたドメインは，どのような形でも，既存のフォレストの一員にすることはできない。最初の方で「ドメインがまとまりドメイン・ツリーを構成し，ドメイン・ツリーがまとまりフォレストを構成する」と述べたが，これは概念を示しただけであり，実際の構築手順を示したものではないので注意してほしい。 フォレスト内の全ドメインは，同じスキーマ（ディレクトリ・データベースに格納できる情報の種類などを定義した情報）を持つ。また，フォレスト・ルート・ドメインには，「Enterprise Admins」という特別なユーザー・グループがあり，フォレスト内の全ドメインに対する管理権限を持つ。このように，同一フォレストかどうかはActive Directoryの構造を設計する上で非常に重要な意味を持つ。一方，同一ドメイン・ツリーにあるかどうかには，大きな意味はない。特にフォレスト・ルート・ドメインは，いったん構築すると，ドメイン構造の変更は一切できないので慎重に作業してほしい。
ドメイン階層を導入する理由を考える
「単一ツリーでの子ドメインの導入」 （1）の「複製トラフィックを抑制したい場合」というのは，たくさんのドメイン・コントローラ間の通信量を減らすのが目的の場合だ。Active Directoryデータベースは，同一ドメインの全ドメイン・コントローラで情報が共有されている。Windows NTと異なり，Active Directoryではどのドメイン・コントローラ上で修正を加えても構わない。これを「マルチマスター複製」と呼ぶ。加えた修正は他のドメイン・コントローラに順次転送される（図2）。手近なドメイン・コントローラで修正ができることと，1つがダウンしても他のドメイン・コントローラが引き継いでくれるという利点がある。 しかし，ドメイン・コントローラがたくさんあって，あちこちで修正があると，Active Directoryデータベースを複製するためのトラフィックが増え過ぎてしまう。例えば，子会社と親会社で組織同士の独立性が高いならば，全情報を複製するのは効率が悪く，ユーザー登録情報を常に同期する必要はあまりないだろう。このような場合に子会社を子ドメインとすれば，複製量を大幅に削減できる（図3 ）。ただし，この場合でもスキーマの変更など，一部の情報は親子ドメイン間で複製される。
（2）の「異なるセキュリティ・ポリシーを実装したい場合」は，特にパスワード・ポリシーなどを組織ごとに変えたいケースである。Active Directoryは，ユーザー認証にKerberosという認証方式が使える。Kerberosでは，ユーザー管理を「レルム（Realm）」という単位で行う。レルムはKerberosの用語であるが，この場合Active Directoryのドメインと同じと考えていい。Active Directoryには，レルム単位だけで許可されている設定項目の1つに，パスワード・ポリシーがある。そのため，パスワード・ポリシーを変更したければ，別ドメインにしておく必要がある。例えば，研究所に勤務する研究員は一般社員よりも厳しいパスワード・ポリシーを実装したいこともあるだろう。このような場合は，研究所を別ドメインにしなければならない。 （3）の「管理権限を分離したい場合」は，管理者を事業所ごとに配置して，他の事業所には触らせないといったケースである。通常，あるドメイン管理者は，フォレスト内の別ドメインの管理権限を持たない。そのため，子ドメインを複数追加したとして，その子ドメインの管理者は，他の子ドメイン（兄弟ドメイン）の管理権限を持たない。こうして，異なる組織に合わせて，子ドメインの管理権限を分離できる。ただし，フォレスト・ルート・ドメインのEnterprise Adminsグループのメンバーは，フォレスト内の全ドメインを管理する権限を持つ。全社を管理するシステム部がEnterprise Adminsグループの権限を持ち，事業所のシステム担当者がドメイン管理者といった使い分けになる。 「追加ツリーによる複数ツリーの構築」 フォレスト内に複数のツリーを導入するのは，複数のDNSドメインを扱いたい場合に限られる。例えば，名前が異なっていても，関連会社として単一のフォレストで管理したい場合などである。追加ツリーは，最初に構成したツリーと何ら変わるところはない。ただ，最初に構成したツリーのルート・ドメインがフォレスト・ルート・ドメインになる点が違うだけである。複数ツリーを構成した場合，フォレスト・ルート・ドメインが見分けにくくなるなどの弊害があるため，特別な事情がない限りは使用しない方がよい。 |
