はじめに
LinuxエンジニアがWindows管理で最も驚く（あるいは戸惑う）のが、「個々のサーバーにログインして設定ファイルを書き換える」という文化が極めて薄いことです。
Linuxで数千台のサーバー設定を管理する場合、AnsibleやPuppet、Chefといった構成管理ツールを使うのが一般的です。Windowsの世界では、それらが普及する遥か前から「GPO」という強力な一元管理メカニズムがOS標準で組み込まれていました。
「パスワードポリシーを変えたい」「全端末のファイアウォールを有効にしたい」「特定のレジストリを配布したい」——これらすべては、ドメインコントローラー（DC）上で作成したGPOを各マシンに「降らせる」ことで完結します。
1. GPOとは何か？（Linuxとの比較）
GPOを端的に言えば、**「AD上のコンピューターやユーザーに対して、OSの設定（主にレジストリ）を強制適用する仕組み」**です。
| 比較項目 | Linux (Ansible等) | Windows (GPO) |
|---|---|---|
| プッシュ/プル | 基本はプッシュ（SSH経由） | プル型（クライアントがDCに取りに行く） |
| 設定の実体 |
.yml や .conf
|
ADデータベース（GPC）+ SYSVOL内のファイル（GPT） |
| 適用タイミング | 実行時のみ | 起動時・ログイン時、および定期的（約90分間隔） |
| ドリフト防止 | 定期実行が必要（cronやCIで工夫） | OSが自動で再適用し、ユーザーによる変更を上書きする |
2. 設定の「在処」：GPC と GPT
Linuxエンジニアが気になるのは「その設定の実体はどこか？」でしょう。GPOは実は2つの部品で構成されています。
GPC（Group Policy Container）— ADデータベース側
GPOの「メタ情報」（名前、GUIDなど）がADのデータベースに格納されます。dsa.msc（ADユーザーとコンピューター）で確認できる部分です。
GPT（Group Policy Template）— ファイルシステム側
設定の実体ファイルが C:\Windows\SYSVOL\sysvol\<ドメイン名>\Policies\ 配下に格納されます。
SYSVOL\
└─ Policies\
└─ {GPO-GUID}\
├─ Machine\ ← コンピューター設定
│ └─ Registry.pol
└─ User\ ← ユーザー設定
└─ Registry.pol
テンプレート定義（ADMX/ADML）： どのレジストリキーを書き換えるかはXML形式の .admx ファイルに記述されており、C:\Windows\PolicyDefinitions\ に格納されています。独自アプリのポリシーを作成する際はこのファイルを自作します。
適用の流れ：
- クライアントがDCの
SYSVOL共有を参照し、自分に関係するGPTをダウンロード - OS内の「クライアントサイド拡張機能（CSE）」が指示に従いレジストリ等を書き換え
DCの適用間隔は5分
一般のクライアントPCは約90分（±30分のランダムオフセット）ごとにGPOを更新しますが、DCは5分ごとに更新します。パスワードポリシーなど重要な設定を変更した際は gpupdate /force で即時反映させましょう。
3. コンピューター設定 vs ユーザー設定
GPO内の設定は2つのノードに分かれています。この区別はLinuxに直接対応する概念がなく、最初に混乱しやすいポイントです。
| ノード | いつ適用されるか | 適用対象 | 例 |
|---|---|---|---|
| コンピューターの構成 | マシン起動時 | そのPCを使う全ユーザー | BitLockerの強制、ファイアウォール設定 |
| ユーザーの構成 | ユーザーのログオン時 | そのユーザーがどのPCを使っても | デスクトップの壁紙、IEのプロキシ設定 |
「設定したのに効かない」の典型原因
コンピューター設定を変更した場合、gpupdate /force を実行しても「ログオフ＆ログオン」では反映されません。マシン自体の再起動が必要です（または gpupdate /force /boot）。ユーザー設定はログオフ＆ログオンで反映されます。
4. 適用順序の鉄則：LSDOU と例外
GPOには複数の設定が重なった場合の「優先順位」があります。これを LSDOU と呼びます。Linuxの変数のオーバーライドに近い感覚です。
- L (Local): ローカルグループポリシー（そのマシン自身の個別設定）
- S (Site): Active Directoryの「サイト」（物理的な拠点）
- D (Domain): ドメイン全体
- OU (Organizational Unit): 組織単位（もっとも細かい区分）
**後に適用されたものが優先（上書き）**されます。つまり、OUに紐付けられた設定が、ドメイン全体の設定を上書きします。
重要な例外：Enforced と Block Inheritance
LSDOU原則には2つの「特権的な上書き手段」があります。これを知らないと、「なぜ上位の設定が効いているのか」が全く理解できなくなります。
| 機能 | 設定場所 | 効果 | Ansibleで近い概念 |
|---|---|---|---|
| Enforced（強制） | GPO側 | このGPOの設定は下位OUに上書きさせない |
no_log: true や変数の !unsafe
|
| Block Inheritance（継承のブロック） | OU側 | 上位から流れてくる設定を受け取らない |
hosts: !all で特定グループを除外 |
ただし、Enforced は Block Inheritance より強いです。上位でEnforcedが設定されたGPOは、Block Inheritanceを設定したOUにも流れ込みます。
【優先順位の整理（強 → 弱）】
Enforced GPO（上位） > OU設定 ≧ Domain設定 > Site設定 > Local設定
※ Block Inheritance は Enforced GPO には無効
「Default Domain Policy」は触りすぎない
ドメイン全体の設定をここに集中させるのは、Ansibleでいう group_vars/all にすべての変数を書き込むようなものです。管理が困難になるため、特定のセキュリティ設定は専用OUと専用GPOで管理するのが定石です。パスワードポリシーとアカウントロックアウトポリシーのみ、ここに設定するのが推奨です。
5. 実践：エンジニアのためのGPOデバッグ
Linuxで ansible-playbook --check を行うように、Windowsでも「今、どのポリシーが適用されているか」を確認するコマンドが必須です。
gpupdate：設定の強制反映
# 設定を今すぐ同期する（Linuxの systemctl reload に近い）
gpupdate /force
# コンピューター設定を再適用して再起動する
gpupdate /force /boot
gpresult：適用状況の確認
「設定したはずなのに反映されない」時の調査用コマンドです。
# どのGPOが適用されているか概要を表示（管理者権限推奨）
gpresult /R
# 詳細なHTMLレポートを出力（「なぜこの設定が勝ったか」まで追える）
gpresult /H C:\temp\gpo_report.html
# 別のユーザーの適用状況を確認する場合
gpresult /R /USER domain\username
gpresult /R の出力を読むポイント：
COMPUTER SETTINGS ← ここがコンピューター設定の適用結果
Applied Group Policy Objects ← 実際に適用されたGPO（後のものが優先）
Default Domain Policy
Tier2_PC_Security
Denied Group Policy Objects ← ← これが「設定したのに効かない」の原因調査箇所
MyNewPolicy (セキュリティフィルタリングによって拒否されました)
「拒否されました」の主な原因
Denied Group Policy Objects に表示される場合、原因は主に2つです。①セキュリティフィルタリング：GPOには「誰に適用するか」のACLがあり、デフォルトは Authenticated Users。コンピューターアカウントが含まれているか確認してください。②WMIフィルタリング：WMIクエリ（OSバージョン等）で適用対象を絞っている場合、クエリ条件を満たさないと拒否されます。
おわりに
GPOは「GUIベースの構成管理ツール」です。一度マスターすれば、数千台のWindowsマシンのセキュリティ設定を数分で変更できる絶大なパワーを手にできます。しかし、その強力さゆえに、設定を間違えるとドメイン全体を一瞬で脆弱に（あるいは起動不可に）するリスクも孕んでいます。
設定変更前には必ずテスト用OUで検証し、gpresult で意図通りに適用されていることを確認してから展開するのが鉄則です。
今回の「エンジニアの知恵」
GPOの設定画面（グループポリシー管理エディター）には数千もの項目がありますが、そのほとんどは特定のレジストリキーに対応しています。ADMXファイル（
C:\Windows\PolicyDefinitions\配下）の中身を読めば、その設定がどのレジストリ値を操作しているか正確に把握できます。たとえば
WindowsUpdate.admxを開けば、Windows Update の挙動を制御しているレジストリパスが一目瞭然です。「GUIの設定の裏にあるレジストリを把握する」——これがエンジニアらしいGPOの使い方です。