第2回 グループ・ポリシーとは何か：グループ・ポリシーのしくみ（1/5 ページ）
Active Directoryによる集中管理を可能にするGP。NTのシステム・ポリシーとの違いを明らかにし、GPオブジェクトの内部を探ってみよう。
前回は、「グループ・ポリシー」を理解する準備として、その前身である「システム・ポリシー」について解説した。システム・ポリシーとは、簡単にいえば、コンピュータのレジストリ設定を統一管理するためのメカニズムであり、例えばユーザーのデスクトップ環境を変更／統一したり、Webブラウザの設定を変更したりできる。だが、システム・ポリシーではレジストリの設定しか操作することができないし、階層的な管理ができない、デフォルト設定に戻すのが困難、用意されているテンプレート機能が不足など、機能的に不十分な点も少なくない。特に、大規模な組織では、システム・ポリシーでは十分に管理することが困難である。
このような問題を解決するため、Active Directoryでは新たにグループ・ポリシーというメカニズムが導入された。今回はこのグループ・ポリシーの概要について解説する。
グループ・ポリシーにおける改良点
Windows 2000のActive Directoryでは、システム・ポリシーに代わって新たにグループ・ポリシーが導入された。名前は似ているが、内容は大幅に拡充されている。まずは、グループ・ポリシーがシステム・ポリシーの欠点をどのように解消しているのか、その概要を見てみよう。
レジストリ以外の複雑な設定も可能
システム・ポリシーではレジストリの設定しかできなかったことは前回述べたとおりである。これに対してグループ・ポリシーでは、より拡張性を重視した設計になっている。必要に応じて拡張用DLLを組み込み、ポリシーの設定と適用を拡張できるようになった。Windows OSには、標準で拡張用DLLが複数提供されているが、マイクロソフト以外のベンダが独自のポリシーを提供することもできる。
これによって、レジストリ以外の複雑な設定もできるようになった。例えば、ソフトウェアの配布、レジストリやファイルのアクセス権設定などがグループ・ポリシーで行えるようになっている。
レジストリに対するポリシーはグループ・ポリシーでも依然として重要な柱だが、それはグループ・ポリシーという枠組みの中の拡張の1つにすぎない。グループ・ポリシーを利用すれば、例えば次のような項目を設定することができる。これらは単純なレジストリ設定だけでは実現できない機能である。
| 設定項目 | 設定内容 |
|---|---|
| セキュリティ設定 | ファイルやレジストリのアクセス権を設定する |
| ソフトウェアの配布 | Windowsインストーラを利用して、ソフトウェアを自動的にかつ一律にインストールする。また、ユーザーが初めてアプリケーションを起動しようとすると、それに先立って、まずアプリケーションを自動的にインストールする |
| スタートアップなどのスクリプト | コンピュータの起動時、終了時などにスクリプトを実行する |
| Internet Explorerの設定 | セキュリティ・ゾーンとドメインのマッピングの定義や「お気に入り」へのリンクの追加／削除を行う |
| フォルダのリダイレクト | マイ・ドキュメントなどのフォルダを、各コンピュータのローカルからファイル・サーバへリダイレクトする |
| 単純なレジストリ設定にとどまらない設定項目の例 | |
ポリシーの定義と適用の階層化
システム・ポリシーでは、ポリシーの割り当ての対象はコンピュータ、グループ、ユーザーだけだった。そのため、それぞれの所属に応じて適用されるポリシーを変化させるような階層化は困難だった。階層化にかろうじて利用できるのは、グループに対するポリシーとそれらの間の優先度があったにすぎない。
グループ・ポリシーでは、各コンピュータのローカル、そしてActive Directoryのサイト、ドメイン、組織単位（OU）のそれぞれにポリシーを割り当てることができる。これによって、コンピュータに対する設定、ユーザーに対する設定が階層化できるようになった。親階層に割り当てたポリシーは、子階層へも継承して適用される。同一階層内でもさらに複数のポリシーを優先度を付けて割り当てることができる。
階層化された割り当て
グループ・ポリシーでは、各コンピュータのローカル、Active Directoryのサイト、ドメイン、組織単位（OU） のそれぞれにポリシーを割り当てることができる（この図はポリシー適用の優先度を加味して表しているため、厳密な階層構造とはやや異なる）。
| 項目 | 対象 | 意味 |
|---|---|---|
| （1） | ローカル・コンピュータのポリシー | ローカル・コンピュータに割り当てたポリシー |
| （2） | サイトのポリシー | Active Directoryのサイトに割り当てたポリシー |
| （3） | ドメインのポリシー | Active Directoryのドメインに割り当てたポリシー |
| （4） | 親OUのポリシー | Active Directoryの親OUに割り当てたポリシー |
| （5） | 子OUのポリシー | Active Directoryの子OUに割り当てたポリシー |
| （6） 子OU中のコンピュータ | 各コンピュータ | 各コンピュータには、（1） 〜（5） のすべてのポリシーが適用される |
| （7） グループ・ポリシーの処理優先度 | ポリシーの優先度（適用順序） | ポリシーは（1） →（5） の順序で適用される。その結果、優先度は（1） が低く（後のもので上書きされてしまうため）、（5） が高くなる |
階層化したときの結果
システム・ポリシーでは、管理者が自分自身で綿密に立案／シミュレートするか、実際に適用させてみなければ、ポリシーが適用された結果が最終的にどうなるか分からなかった。階層化が不十分だったため単純な適用しかできず、結果の確認を支援するような機能があまり必要とされなかったともいえる。
グループ・ポリシーでは、「ポリシーの結果セット（RSoP：Result Set of Policy）」や「グループ・ポリシー管理コンソール（GPMC：Group Policy Management Console）」といった支援機能／ツールが提供されており、ポリシーの適用対象のどの階層においてどのような結果を得られるのか、確認することができる。
グループ・ポリシーの「ポリシーの結果セット（RSoP）」ウィザード
グループ・ポリシーでは複数のポリシーがさまざまな条件に応じて各コンピュータへ適用される。複数の条件とポリシーが影響し合った結果どのような設定がもたらされるのかを確認するためには、いくつかのツールを利用することができる。RSoPもその1つである。この画面では、ドメインの特定のOUに所属しているユーザーと、ドメインの通常のコンピュータにどのようなポリシーが適用される結果になるのかをシミュレートしようとしている。
（1）シミュレート対象のユーザー。
（2）Active DirectoryのTestOUという組織単位に所属しているユーザーを指定している。
（3）シミュレート対象のコンピュータ。
（4）Active Directoryの通常のコンピュータを指定している。
ポリシーの一貫性
システム・ポリシーでは、どのレジストリ・キーに値を設定するかが必ずしも統一されていなかった。このため、特にユーザーのレジストリ（HKEY_CURRENT_USER）の場合は、（通常）ユーザー本人に書き込みアクセス権があるため、ポリシーが適用された後に各ユーザーが再びレジストリ値を変更してしまう可能性もあった。
グループ・ポリシーでは、レジストリに対するポリシー設定は、Policiesキーに集中させている（HKEY_CURRENT_USERおよびHKEY_LOCAL_MACHINEの、Software\PoliciesキーとMicrosoft\Windows\CurrentVersion\Policiesキー）。Policiesキーへはデフォルトでアクセス権が厳しくなっている。従って、たとえユーザーのレジストリ（HKEY_CURRENT_USER）以下のPoliciesキーであっても、各ユーザーが勝手に改変することはできない。
また、各コンピュータ上でレジストリに対してどのようなポリシーが適用されたかを記録するようになった。これにより、システム・ポリシーにあったような「tattoo effect」は基本的になくなった（tattoo effectとは、1度設定した効果がずっと残り続けること。前回の記事参照）。レジストリに対するポリシーを「未構成」にすれば、それまでポリシーが設定していた値はレジストリから削除され、ポリシーの対象システム／コンポーネントはデフォルトの動作に戻る。また、コンピュータやユーザーにポリシーがいったん適用された後、そのコンピュータやユーザーがポリシーの適用対象から外れた場合も、同様に、ポリシーで設定されていたレジストリが自動的に削除される。
| 設定 | 動作 |
|---|---|
| （1） 「有効」にする | グループ・ポリシーでレジストリのポリシーを「有効」にすると、レジストリに値が設定される。この点はシステム・ポリシーと同じ |
| （2） 「未構成」に戻す | 「有効」にしたレジストリのポリシーを「未構成」に戻すと、設定されていたレジストリの値は削除される。その結果、ポリシーによって制御されていたシステム／コンポーネントはデフォルトの動作に戻る |
多くのシステム・コンポーネントが対応
システム・ポリシーでは、シェルやデスクトップに対する設定が中心で、しかも、あまり多くのポリシーが標準で提供されているとはいえなかった。
グループ・ポリシーでは、サーバ機能を含めて多くのコンポーネントがポリシーに対応している。また、レジストリに対するポリシーは、システム・ポリシーと同様に管理者が必要に応じてカスタマイズしたテンプレートで拡充することもできる。
グループ・ポリシーがカバーする多くのコンポーネント（一部）
グループ・ポリシーでは多くのシステム・コンポーネントが標準でポリシーに対応している。その範囲はシステム・ポリシーのようなシェルやデスクトップ中心の設定にとどまらず、サーバ機能を含め多くのコンポーネントに及ぶ。これは、グループ・ポリシーで設定できるさまざまなポリシーのカテゴリーを、ポリシーの編集ツールで見た様子。
ツール類の拡充
システム・ポリシーでは、基本的なGUI編集ツールである「システム・ポリシー・エディタ（PolEdit.exe）」こそあるものの、それ以外の支援ツールが広く提供されることはなかった。
グループ・ポリシーでは、基本的なGUI編集ツール以外に、より体系的、包括的なGUIの「グループ・ポリシー管理コンソール（GPMC）」をはじめして、各種コマンドライン・ツールも提供されている。なおこのツールについては、今後の連載で詳しく取り上げる予定である。
グループ・ポリシー管理コンソール（GPMC）
グループ・ポリシーを使用した管理を支援するためのツールは、コマンドライン・ツールを含め、いくつか提供されている。画面は、グループ・ポリシーを体系的、包括的に管理するための「グループ・ポリシー管理コンソール（GPMC）」の例。
（1）ドメインやOUなどに応じて階層化されたポリシーを、視覚的に管理することができる。
（2）グループ・ポリシーでは機能の強化に応じて設定できる項目も増えた。ここではそれらの設定項目がタブで分類され、一覧と設定を行うことができる。
Copyright© Digital Advantage Corp. All Rights Reserved.