システム・ポリシー・エディタでの設定が終わったら、それをポリシー・ファイルに保存する。ポリシー・ファイルは適当なファイル・サーバ上の共有に置く。多くの場合、ポリシー・ファイルはドメイン・コントローラのNETLOGON共有に置き、各ドメイン・コントローラに複製する(複製には、Windows NTではDirectory Replicatorサービス、Windows 2000以降ではファイル・レプリケーション・サービス(FRS)が使われる)。このようにドメイン・コントローラ間で複製することによって、ドメイン内のどのコンピュータからもアクセスが容易になる。
ドメインの各コンピュータは、そのファイル共有からポリシー・ファイルを取得し、コンピュータやユーザーに対して、ポリシーで指定されたレジストリ設定を適用する。つまり、ポリシーの適用は、管理者が「いますぐ一斉適用」のような指令を出して一斉に適用されるのではなく、各コンピュータがそれぞれのタイミングで自主的に(だが各ユーザーから見れば自動的/強制的に)適用する仕組みになっている。
システム・ポリシーがレジストリに対する設定であることはこれまでに述べたとおりだが、ポリシー・ファイルそれ自体の実体も、レジストリ・ハイブ形式になっている。システム・ポリシー・エディタはポリシー・ファイルをHKEY_LOCAL_MACHINE\PolicyDataキーとして一時的にロードし、読み書きを行う。ユーザーのログオン時にはHKEY_USERS\AdminConfigDataキーとしてポリシー・ファイルが一時的にロードされる(システム・ポリシー・エディタを、ポリシーを適用するOSと同じレベルのOSで実行しなければならないのはこのためである)。従って、ポリシー・ファイルはメモ帳などでは正しく見ることができないが、レジストリ・エディタにロードすれば通常のレジストリと同様に中身を確認することができる。先のポリシー・ファイルの内容を見てみると、次のようになっている。
ポリシー・ファイルの実体は比較的素朴な作りになっていることが分かる。
設定対象のユーザー(user1というユーザー。上記画面の(6)で指定)やコンピュータ(上記画面の(2)以下)の下に、実際のレジストリと同じツリー構造がある。キーには、ポリシーの適用時に実際にレジストリに設定される値が書き込まれている(上記画面の(8)、(10))。値を削除する場合は「**del.[値]」と書かれている(上記画面の(10)の部分)。ポリシー・ファイルをファイル・サーバから読み取った各コンピュータはこれに従って、コンピュータ自身もしくはログオン中のユーザーがポリシーの対象となるコンピュータやユーザーかどうかを判別し、対象となっている場合は、ポリシー・ファイルと同じツリーに対応するHKEY_LOCAL_MACHINE/HKEY_CURRENT_USERのキーに値を設定/削除する。基本的にはこれだけの仕組みで動作している。
こうして見ると、システム・ポリシーと同様の処理(レジストリの設定や削除など)は、スクリプトなどによるカスタム・ソリューションでも十分可能であることが分かるだろう。しかし、システム・ポリシーには大きな利点がある。例えばWindows NTの場合で考えてみると、次のような利点がある。
システム・ポリシーの利点としては次のようなものが挙げられる。
■コスト
■強制力
■セキュリティ
■メンテナンス性
しかし、欠点もまだ多く残されている。
■設定できるのはレジストリのみ
システム・ポリシーはレジストリを設定するだけであり、それ以外の例えばファイルのアクセス権のような設定を行うことはできなかった。ポリシー・ファイルの適用はDLLでいちおう拡張できるようにもなっており、ベンダが拡張することも可能だった。だが、枠組みが貧弱であり、この拡張性はまったくといっていいほど利用されなかった。
■階層化が不十分
これは当時のNTドメインの性質とも関連することであるが、グループに対するポリシー以外では、システム・ポリシーの適用を階層化できない。
■階層化したときの結果が分かりづらい
複数のポリシーが同じユーザーに適用される場合、各ポリシーを見ながら管理者が考えるか、実際にテスト・コンピュータやユーザーなどを作成・ログオンしてみないと、複数のポリシーが最終的にどのような結果をもたらすのかは分からない。
■デフォルトの設定に戻すのが困難
システム・ポリシー・エディタでポリシーのチェック・ボックスをグレーにすればデフォルトの設定に戻るかのようにも思えるが、実際は「今後は何もしない」だけである。以前設定したポリシーをデフォルトに戻してくれるわけではない。従って多くの場合、デフォルトに戻すには、有効だったポリシーは無効に、無効だったポリシーは有効にする必要がある。そのため、同じポリシーの変更を繰り返すと、現状の把握が難しくなる。
■ポリシーの対象からの除外が困難
上記とも関連するが、いったんポリシーの適用をすると、そのポリシーの対象から外すのは難しい――例えば、あるグループに対してポリシーを適用していて、そのグループに所属するあるユーザーがグループから外れたとする。しかしポリシーの「巻き戻し(ロールバック)」のような処理は行われず、グループに対するポリシーによってすでに設定されたレジストリは、何らかの手段で変更しない限り、残り続ける(このような効果はtattoo effectとも呼ばれる)。
■ユーザーによる設定変更を禁止できない
各ユーザーは通常HKEY_CURRENT_USER以下のキーに書き込み権を持っているため、特別なアクセス権の設定されているPoliciesキー以外のキーにポリシーを設定する場合、各ユーザーがログオン後に自分で変更できてしまう。
■テンプレートが不十分
標準のポリシー・テンプレートが充実しているとはいえない。ポリシーの多くはシェルやデスクトップ中心の設定にとどまり、サーバ機能などの多くのコンポーネントがシステム・ポリシーに対応していなかった。ポリシー・テンプレートの自作が比較的容易であるとはいえ、テンプレートの不足は利便性を損なう。
■ツールの不足
上記の欠点をカバーするようなツール類が不足している。利用できるものはシステム・ポリシー・エディタぐらいしかなかった。
以上のような問題/欠点があるため、システム・ポリシーだけでシステムを管理するには限界がある。そこで新たにActive Directoryとともに導入されたのが、「グループ・ポリシー」というメカニズムである。次回は、このグループ・ポリシーについて見ていく。
Copyright© Digital Advantage Corp. All Rights Reserved.