はじめに

第9回は、Windows管理の代名詞とも言える グループポリシー（GPO） を取り上げます。

Linuxで数千台のサーバー設定を管理する場合、Ansible、Puppet、Chef、あるいは最近ではTerraformといった構成管理ツール（IaC）を使うのが一般的です。Windowsの世界では、それらが普及する遥か前から「GPO」という強力な一元管理メカニズムがOSにネイティブ実装されていました。

「設定ファイルが散らばっていて管理できない」というLinuxエンジニアの悩みを、Windowsがどう解決しているのかを解剖します。

1. GPOとは何か？（Linux構成管理との対比）

GPO（Group Policy Object）を端的に定義すると、「Active Directory（AD）内の特定オブジェクトに対して、レジストリ設定やセキュリティ権限を強制適用する仕組み」 です。

Linuxエンジニアの感覚に翻訳すると、以下のようになります。

比較項目	Linux (Ansible等)	Windows (GPO)
方式	プッシュ型（SSH経由）	プル型（クライアントがSMB経由でDCのSYSVOLを参照・取得）
定義ファイル	`.yml`, `.conf`	ADMX / ADML（XMLベースの管理用テンプレート）
適用タイミング	コマンド実行時	OS起動時 / ログオン時 / 90〜120分間隔（ランダムオフセットあり）
構成の維持	定期的なPlaybook実行が必要	OSが自動で再適用（構成ドリフトを自動修正）

補足： GPOのプル間隔はデフォルト90分＋0〜30分のランダムオフセットです。すべてのクライアントが同時にDCへ問い合わせてアクセスが集中するのを防ぐ設計になっています。

2. 優先順位の鉄則：「LSDOU」を覚えよう

GPOには複数の設定が重なった場合の強力な優先ルールがあります。これを LSDOU と呼びます。Linuxの変数オーバーライド（例：Ansibleの group_vars vs host_vars）に近い考え方です。

L (Local): ローカルグループポリシー（そのマシン自身の個別設定）
S (Site): Active Directoryの「サイト」（物理的な拠点単位）
D (Domain): ドメイン全体
OU (Organizational Unit): 組織単位（もっとも細かい区分）

後から適用されるものが優先（上書き） されます。つまり、OUに紐付けられた設定が、ドメイン全体の設定を上書きします。「最後に書いたものが勝つ」Ansibleの変数優先度と同じ考え方です。

ポイント：
セキュリティ設定を「ドメイン全体（D）」にかけると、全サーバーに影響が出てしまいます。Linuxで特定のホストグループだけに設定を当てるように、Windowsでも「サーバー用OU」や「端末用OU」を作成し、そこに適切なGPOをリンクさせるのが定石です。

応用：「適用しない（ブロック継承・強制）」

Block Inheritance：子OU側で「上位のGPOを無視する」設定。特定部署だけ別ポリシーを適用したい場合に使います。
Enforced（No Override）：親GPO側で「下位に上書きさせない」設定。セキュリティ基準をどのOUにも例外なく徹底させたい場合に使います。

3. 設定の実体はどこにあるのか？

Linuxエンジニアが最も気になるのは「その設定データはどこに保存され、どう流れるのか？」でしょう。

管理用テンプレート（ADMXファイル）

GPOの設定項目（「パスワードの長さを14文字にする」など）の定義は、/etc のようなテキストではなく、ADMX というXMLファイルに記述されています。これは単なる「GUIエディターのUIを生成するための型紙（スキーマ定義）」であり、設定の実体ではありません。ADMLは言語ファイルで、UIの表示テキストを多言語化する役割を持ちます。

C:\Windows\PolicyDefinitions\        ← ADMXファイル（設定スキーマ）
C:\Windows\PolicyDefinitions\ja-JP\  ← ADMLファイル（日本語表示テキスト）

SYSVOLフォルダ

実際のGPOの設定内容は、ドメインコントローラー（DC）内の SYSVOL と呼ばれる共有フォルダに保存されます。

\\<ドメイン名>\SYSVOL\<ドメイン名>\Policies\{GPO-GUID}\
  ├── Machine\   ← コンピューター設定
  └── User\      ← ユーザー設定

クライアントはSMBプロトコル経由でSYSVOLを参照し、自身のバージョン番号（CSEバージョン）と比較して変更があればダウンロード・適用します。SYSVOLはDC間でDFSレプリケーションにより自動同期されるため、複数のDCが存在する環境でも設定の一貫性が保たれます。

レジストリへの書き込み

最終的に、GPOで指定された設定はクライアントのレジストリに書き込まれます。レジストリはWindowsが設定・状態情報を永続化するための階層型データベースで、HKLM\Software\Policies\ 以下がGPOの書き込み先として使われます。

# GPOが書き込むキーの例（管理用テンプレート設定）
HKLM\SOFTWARE\Policies\Microsoft\Windows\
HKCU\SOFTWARE\Policies\Microsoft\

Linuxで例えるなら、/etc/ 以下に設定ファイルを書き込むイメージに近いです。ただし、レジストリはバイナリ形式の一元管理データベースであるため、直接テキストエディタで編集することはできません。

4. 実践：エンジニアのためのGPOデバッグ

「設定が反映されない！」というトラブルは、Windows管理で最も多い問題の一つです。Linuxで ansible-playbook --check を叩くように、以下のコマンドを使いこなしましょう。

設定を即座に反映させる（gpupdate）

デフォルトでは90〜120分の間隔で反映されますが、テスト時は待っていられません。

# 設定を今すぐ同期する（Linuxの systemctl reload に近い）
gpupdate /force

# コンピューター設定のみ（ユーザー設定は除外）
gpupdate /force /target:computer

# ユーザー設定のみ
gpupdate /force /target:user

適用状況を調査する（gpresult）

どのポリシーが適用され、どれが競合で除外（Filtered/Not Applied）されたのかを確認します。

# 適用されているGPOのサマリーを表示
gpresult /R

# 詳細なHTMLレポートを生成してブラウザで確認
gpresult /H C:\temp\gpreport.html

# 別ユーザーの適用状況を確認（管理者権限が必要）
gpresult /R /user <ドメイン>\<ユーザー名>

gpresult /R の出力には以下のセクションが含まれます。

セクション	内容
Applied GPOs	実際に適用されたGPO一覧
Denied GPOs	リンクはあるが適用されなかったGPO（フィルタリング等の理由付き）
The following GPOs were not applied	空（設定なし）のため処理されなかったGPO

よくあるトラブルシュート：

設定が反映されない → gpupdate /force 後に gpresult /R で "Applied GPOs" に目的のGPOがあるか確認
意図しない設定になる → gpresult /H の詳細レポートで「どのGPOがどの設定を書いたか」を確認
DCへの接続 → nltest /dsgetdc:<ドメイン名> で認識しているDCを確認

おわりに

GPOは、数千台のWindowsマシンを「一瞬で一貫したセキュリティ状態にする」ための強力な仕組みです。しかし、一度設定を誤れば、一瞬で全マシンのログインを不可能にするリスクも秘めています。

LinuxエンジニアがAnsibleのコードをGitで管理するように、Windows管理においてもGPOのバックアップと変更管理を徹底することが、要塞化の第一歩となります。

# GPOをバックアップする（変更前に必ず実行）
Backup-GPO -All -Path C:\GPOBackup\

# 特定のGPOだけバックアップ
Backup-GPO -Name "セキュリティベースライン" -Path C:\GPOBackup\

今回の「エンジニアの知恵」

WindowsのGUI（グループポリシー管理エディター）で設定できる項目は数千ありますが、実は 「基本設定（Group Policy Preferences）」 を使えば、Linuxの ln -s のようなショートカット（シンボリックリンク相当）の作成や、ファイル・レジストリの配布といった「よりAnsibleに近い」柔軟な操作も可能です。

通常のGPO設定との大きな違いは、ユーザーがローカルで上書きできる点です。「強制はしないが、デフォルト値を配布したい」という用途に向いています。