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