長年運用されているActive Directory環境で、突然Default Domain Controllers PolicyのGptTmpl.infが失われてしまうと、セキュリティ設定の整合性が崩れ、管理者は大きな不安を感じるものです。特にドメイン固有のSIDを含む重要ファイルがない状況では、一般的な復旧手段がうまく機能しないことも多々あります。そこで本記事では、実運用のドメインでGptTmpl.infが欠落してしまった場合の具体的な対処法や注意点を、できるだけ分かりやすく解説していきます。
GptTmpl.infとは何か？その重要性を知る
Active Directory上のグループポリシーには、さまざまな設定を記述したファイルが含まれています。その中で、GptTmpl.inf はセキュリティ関連の設定情報が集約された重要ファイルです。このファイルが欠落していると、意図したセキュリティ設定が正しく反映されないばかりか、ポリシーの整合性が崩れる原因にもなります。
GptTmpl.infの主な役割
- セキュリティポリシーの反映 例：パスワードポリシー、アカウントロックアウトポリシーなど
- ユーザー権利の割り当て（User Rights Assignment）の管理 例：ログオン権限、シャットダウン権限など
- 監査ポリシーの適用 例：成功/失敗イベントの監査ログ設定など
- 各種オブジェクトに対するアクセス制御リスト (ACL) 設定 例：フォルダやレジストリキーへのアクセス権
これらの設定が欠落すると、予期せぬ権限付与やセキュリティホールが生じるリスクが高まり、ドメイン全体の安全性が脅かされます。
なぜ消失するのか？GptTmpl.infが壊れる原因
GptTmpl.infが失われる具体的な原因として、以下のようなケースが考えられます。
- 運用歴の長さによるファイル破損・散逸
何度もOSアップグレードやドメインの機能レベル変更を繰り返すうちに、SYSVOL内のファイルが壊れたり消失したりすることがある。 - バックアップ手順の不備
ある時点でグループポリシーを壊すトラブルが発生しても、過去のバックアップが正しく取られていない場合、元に戻せなくなる。 - 誤操作やウイルス感染
管理者による誤っての削除や、マルウェアによる影響でファイルが消えることがある。
いずれの理由にしろ、Default Domain Controllers PolicyのGptTmpl.infが欠落すると、Controller上のセキュリティ設定が大きく不透明になり、ドメイン運用を続けるうえで重大なリスクを背負うことになります。
欠落したGptTmpl.infの復旧手段：基本アプローチ
GptTmpl.infを復旧する一般的な手段として、Microsoftが用意しているツールや別の健全なドメインからのコピーなどが挙げられます。しかしながら、Default Domain Controllers Policyはドメイン特有のSIDを含むために単純にファイルをコピーするだけでは問題が解決しない可能性があります。以下で詳しく見ていきましょう。
dcgpofixコマンドによる復旧の限界
Windows Serverには、Default Domain PolicyとDefault Domain Controllers Policyを既定の状態に戻すコマンドとしてdcgpofix（dpogpfixとも表記）が用意されています。
しかし、本記事の前提にもあるように、dcgpofixはポリシーの初期化に近い形での再生成しか行わないため、ドメイン独自のSIDが盛り込まれた設定までは完全に復旧しきれない場合があります。特に大量のユーザー権利設定が存在していた環境では、期待したGptTmpl.infの内容にならないことが多々あるでしょう。
テストドメインからのファイル流用：SIDの問題
この問題を解決するため、同じOSバージョン（例：Windows Server 2019）・同じ機能レベル（例：2016）で構築したテストドメインを用意し、そこからGptTmpl.infをコピーしてくる方法が一般的に考えられます。
しかし、テストドメインのファイルをそのまま利用すると、テストドメイン固有のSIDが記述されているため、実運用ドメインでは無効なSIDとして扱われるか、整合性エラーを引き起こす可能性があります。
ドメイン固有のSIDをどう取り扱うか
テストドメインから取得したGptTmpl.infをそのまま適用すると、表面上はファイルが補われたように見えても、実際にはSIDが異なるため「正しく機能しない」または「誤った権限を割り当てる」といった危険性を孕みます。そこで重要になるのが、ファイル内に記載されたSIDを正しい形に置き換える作業です。
SIDの基本構造を理解する
SID (Security Identifier) は、Windowsがセキュリティや権限管理を行ううえで用いる一意の識別子です。形式としては以下のように表記されます。
S-1-5-21-XXXXXXXXXX-XXXXXXXXXX-XXXXXXXXXX-XXX
最初の「S-1-5-21」部分は多くのドメインで共通ですが、その後ろに続く数値列がドメインやアカウントごとのユニークな値を示しています。SIDには大きく2つの種類があります。
| SIDの種別 | 例 | 解説 |
|---|---|---|
| Well-known SID | S-1-5-32-544 (Administrators グループ) | すべてのWindows環境で共通。事前に定義された特権グループなど。 |
| ドメイン固有SID | S-1-5-21-<ドメイン固有>-XXXX | ドメインごとに異なる。ユーザーやグループに付与される。 |
GptTmpl.infには「Well-known SID」の記述もあれば「ドメイン固有SID」の記述も含まれています。Well-known SIDについては共通の値なので書き換え不要ですが、ドメイン固有SIDは運用ドメインの実際のSIDに差し替える必要があります。
運用ドメインのSIDを確認する方法
実運用ドメインにおける各ユーザーやグループのSIDを確認するには、以下の方法が便利です。
- コマンドプロンプトでの確認
whoami /groups
wmic useraccount get name,sid
これらのコマンドで、現在ログオンしているユーザーやコンピューターアカウント、特定のユーザー/グループのSIDを取得できます。
- Active Directoryユーザーとコンピューター (dsa.msc)
GUIからユーザーやグループの「属性エディタ」を開き、objectSIDの値を確認することも可能です。 - PowerShellスクリプトの活用
PowerShellでもGet-ADUser、Get-ADGroupなどのコマンドレットを用いてSIDを一覧出力できます。
実践：GptTmpl.infを手動で再生成する手順
ここでは、テストドメインから取得したGptTmpl.infをベースに、ドメイン固有のSIDを置き換える実践的な方法を紹介します。あくまで一例ですが、手作業で誤りがないよう慎重に進めるのがポイントです。
1. テストドメインでのGptTmpl.infの取得
まずは同じOSバージョン・同じ機能レベルで作成したテストドメインにおいて、SYSVOLからDefault Domain Controllers PolicyのGptTmpl.infを取得します。パスの例は以下です。
\\<テストドメイン名>\SYSVOL\<テストドメイン名>\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf
取得したファイルは運用ドメイン側の管理者がアクセスできる場所（例：一時フォルダや共有フォルダ）に置いておきます。
2. ファイル内のSIDを抽出して洗い出す
テキストエディタやPowerShellなどを使い、GptTmpl.inf内に記述されたSIDをすべて抽出します。例えば、以下のようなスクリプトを利用するイメージです。
Select-String -Pattern "S-1-5-[0-9-]+" -Path .\GptTmpl.inf |
Select-Object -Unique |
Out-File .\SID_list.txt
このようにして重複を省きつつ、一意なSIDを一覧化します。
抽出したSIDの中で「S-1-5-32-xxx」の形で始まるものはWell-known SIDである可能性が高く、そのままでも問題ないケースが多いです。しかし「S-1-5-21-<テストドメイン固有の値>-xxx」の形をしているものは、運用ドメインのSIDに置き換える必要があります。
3. 運用ドメインの該当ユーザー/グループSIDと突き合わせる
テストドメインでAdministratorsに相当するグループが「S-1-5-21-xxxxx-512」だとしても、運用ドメインでは別のSIDになっているかもしれません。
そこで、前述のコマンドやActive Directory上の情報をもとに、運用ドメイン側の該当グループやユーザーのSIDを確認しておきます。そして、テストドメインでいうところの「Administrators」「Domain Admins」「Enterprise Admins」などがどのSIDに該当するか対応表を作成する作業が必要です。
以下のような表を作成すると分かりやすいでしょう。
| グループ/ユーザー名 (テスト) | SID（テストドメイン） | グループ/ユーザー名 (運用) | SID（運用ドメイン） |
|---|---|---|---|
| Domain Admins | S-1-5-21-111-222-333-512 | Domain Admins | S-1-5-21-999-888-777-512 |
| Enterprise Admins | S-1-5-21-111-222-333-519 | Enterprise Admins | S-1-5-21-999-888-777-519 |
| Administrators | S-1-5-21-111-222-333-544 | Administrators | S-1-5-21-999-888-777-544 |
| … | … | … | … |
実際のファイルでは、より多くのSIDや独自のセキュリティグループが含まれる可能性があります。この対応表を用いながら、テストドメインから取得したGptTmpl.inf中のSIDを検索置換で変更します。
4. 置き換えたGptTmpl.infを適用
作成した新しいGptTmpl.infを、実運用ドメインの以下のパスに上書きコピーします。
\\<運用ドメイン>\SYSVOL\<運用ドメイン>\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf
この際には、事前に既存のファイルをバックアップしておくことを強く推奨します（破損や更なるトラブル時に元の状態に戻せるようにするため）。コピー後は次のコマンドを実行し、グループポリシーの更新が正常に行われるか確認します。
gpupdate /force
また、イベントビューワーのシステムログやセキュリティログを確認し、エラーや警告が発生していないかチェックすると安心です。
5. ポリシーをエディタで確認し、手動で微調整
Group Policy Management Console (GPMC) やグループポリシーエディタ (gpedit.msc) でDefault Domain Controllers Policyを開き、セキュリティ設定の内容が想定通りかどうかを確認します。
もし意図しないユーザー権利設定やACLが含まれていた場合は、手動で修正を加えつつ再度gpupdate /forceを実行して反映状況を確かめる作業を繰り返します。
復旧後の注意点と今後の対策
無事にGptTmpl.infを再生成・適用できたら、以下の点を踏まえて今後の運用に備えましょう。
バックアップの実施と定期的な検証
グループポリシーオブジェクトはSYSVOL上に物理ファイルとして存在するため、通常のシステムバックアップだけでなく、グループポリシーのエクスポート機能を利用した定期的なバックアップを推奨します。また、実運用のドメインに変更を加える前にテストドメインで検証する運用フローを確立すると、今回のようなトラブルを避けられます。
dcgpofixの過度な依存は禁物
dcgpofixはDefault Domain PolicyやDefault Domain Controllers Policyを「初期状態」に戻すことが主目的のコマンドであり、すでに独自設定やドメイン固有のSIDが入り組んだ環境では、期待する設定を100％復元できる保証はありません。安易にdcgpofixに頼りすぎないようにし、GptTmpl.infを含めたポリシー内部のファイルを常に把握しておく姿勢が重要です。
不明なSIDや権限設定の洗い出し
ユーザー権利やセキュリティ設定のエントリに、既に存在しないアカウントのSIDが残っている場合もあります。そのような「孤立したSID」はセキュリティホールになる可能性があるため、今回の復旧作業を機に定期的に“お掃除”することをおすすめします。
まとめ：慎重なSID差し替えこそが最善策
Default Domain Controllers PolicyのGptTmpl.infが欠落してしまうと、ドメイン固有のSIDを含む複雑なセキュリティ設定をどう再現するかが大きな課題になります。dcgpofixだけでは不十分なことが多いため、テストドメインで取得したファイルをベースに、運用ドメインの正しいSIDへ置き換えていく作業が確実かつ安全です。
時間と手間はかかるものの、実際のセキュリティ設定を正しく復元できる唯一の方法といっても過言ではありません。今回紹介した手順を参考にしながら、あなたのドメイン環境に合わせたファイル再生成と検証を丹念に行ってください。
最後に、運用の安定化には「定期的なバックアップ」「テストドメインでの事前検証」「エラー発生時の迅速なログ確認」が欠かせません。今後はこれらを意識し、安心・安全なドメイン運用を続けていただければと思います。
コメント