完成度を増したActive Directory(第2回) 続き


△ 図をクリックすると拡大されます
図8●スキーマ・マネージャによるスキーマ設定の変更

Active Directoryデータベースの管理データである
スキーマの変更が可能に

 「スキーマ」は,Active Directoryデータベースに作成するオブジェクトの属性情報などを収めるテンプレートである。ADではスキーマの拡張を許しており,いくつかのアプリケーションで活用されている。例えば,Exchange 2000 Serverはスキーマを拡張して,メールボックスの位置を管理する。

 Windows 2000では,いったん追加したスキーマは,無効化はできるものの,変更や削除が一切できなかったため,AD対応アプリケーションの開発効率が悪かった。

 Windows Server 2003でも,スキーマを削除する機能は持たないが,変更や無効化ができるので,実質的にスキーマの再追加ができる(図8 )。実際にスキーマ変更を行うケースは,何らかのアプリケーションが必要としている場合に限られ,管理者はスキーマの無効化さえできればよいケースが多い。


△ 図をクリックすると拡大されます
図9●Windows 2000 Serverにおけるフォレスト間の信頼関係

Kerberosチケットの適用範囲をフルに使って  フォレスト間の信頼関係を結ぶ
 Windows 2000でフォレストの境界とは,Kerberosチケットの境界のことである。異なるフォレストのドメインと信頼関係を結ぼうとすると,Windows NT互換の信頼関係しか結べなかった。つまり,ドメイン対ドメインの一方通行の信頼関係である( 図9)。


△ 図をクリックすると拡大されます
図10●Windows Server 2003におけるフォレスト間の信頼関係

 しかし,本来Kerberosはチケットの有効範囲(Realm,レルムと呼ぶ)を超えた認証が可能である。Windows Server 2003ではKerberosの機能を使い,異なるフォレストでの信頼関係を構成できるようになった。信頼関係は片方向,双方向のいずれかを選択できる。

 フォレスト間信頼を構成しているドメイン間は自動的に信頼関係が設定される。ただし,フォレスト間信頼は別のフォレストには推移しないので注意してほしい( 図10)。

 フォレスト間信頼は,何らかの事情で,複数のフォレストを統合管理したい場合に便利だ。同一フォレスト内では,Enterprise Adminsというフォレスト全体の管理グループが存在するため,完全に管理機能を分離するのは困難である。実際,筆者は,顧客からしばしば「Kerberosを使いながら,一方向の信頼関係を結べないか」「双方向の信頼関係を結びながら,Enterprise Adminsグループの管理下にないドメインを作る方法はないか」といった質問をしばしば受ける。確かに,独立性が極めて高い組織が緩やかに連携しているような場合は,シングル・フォレストでは不適切な可能性もある。

 ただし,フォレスト間信頼を実現するには,フォレストの機能レベルが「Windows .NET」モードである必要がある。

DCの複製パス・アルゴリズムの変更で
サイト数200以上でも正常動作

 サイトは,物理的なネットワークを定義したActive Directoryオブジェクトである。サイトは1つ以上のサブネットの集合体であり,ドメインの構造とは無関係に設定できる。

 通常は,信頼できる高速なネットワークを単一サイトとして定義する。最も分かりやすいのはLAN単位でサイトを定義する方法だ。通常LANの速度は遅くても10Mビット/秒,通常は100Mビット/秒であり,安定した通信が可能である。

 しかし,実際にWindows 2000で大量のサイトが存在する場合,複製に時間がかかり,正しく動作しない場合があった。原因は,ADデータベース複製パスの計算アルゴリズムの問題である。複製にかかる時間が,サイト数の2乗に比例して増えていた。正常に動作しない場合,管理者は手動でサイト間接続パスを構成しなければならない。あるいは,サイト数を抑えるため,高速のWANを単一サイトとして設計するといった工夫を凝らす場合もあった。

 Windows Server 2003では,アルゴリズムが改善され,200を超えるサイトでも正常に自動構成できるようになった。これにより,単純にサイト数に比例して複製時間がかかるだけで済む。ただし,アルゴリズムが異なるため,Windows 2000とWindows Server 2003が混在していると,複製パスの生成情報が競合する可能性がある。そこで,Windows 2000のDCが存在しない場合,つまり,フォレストの機能レベルが「Windows .NET」モード,または「Windows .NET中間」モードの場合に限って,新しいアルゴリズムを使用する。


「サポートツール」はコマンド・ツール集
Windows Server2003の拡張機能には必須

 本文中でも触れているように,Windows Server 2003では,サポート・ツールのコマンドの利用が前提となっている機能拡張がいくつか含まれている。また,実際に,マイクロソフトがベータ・テスター向けに提供している機能ガイドにもサポート・ツールの機能が数多く紹介されている。


△ 図をクリックすると拡大されます
図A●ヘルプのサポート・ツールのコマンド一覧を表示している画面。Windowsの「ヘルプとサポート」に統合されている。

 サポート・ツールは,Windows Server 2003のCD-ROMから「\Support\Tools\Suptools.msi」を実行すればインストールできる。サポート・ツールは,数多くのツールの集合体で,ほとんどがコマンド・ライン・ツールなので,インストールしてもプログラム・メニューにプログラムのアイコンが追加されることはない。ただ,ヘルプとリリース・ノートが追加で登録されるだけである( 図A)。

 サポート・ツール自体はWindows 2000 Serverでもおなじみであったが,無保証という建前であった。しかし,Windows Server 2003のベータ・テストでは,標準機能と同様に重視されているため,製品版で正式な追加機能となる可能性もある。

 ただし,正式な機能にならない場合でも,サポート・ツールやリソース・キットのコマンドは,将来のバージョンで正式な機能として組み込まれることが多い。早いうちに学習しておいて損はないだろう。