Windows ServerでGPOのRestricted Groupsを使い、ローカルのAdministratorsグループを完全定義しているのに、余計なアカウントが削除されない──。RSoPの赤い×や「An unknown error occurred when attempting to open the database」が見えるケースで、原因の切り分けからログの取り方、復旧の実践手順までをまとめます。
起きている現象を「正しく言語化」する
今回の症状は、ひと言でいうと「Restricted Groups の“置き換え（Replace）”が成立していない」状態です。
| 観測できる事実 | 意味合い（推測ではなく整理） |
|---|---|
| GPOで指定したユーザーは Administrators に追加される | 少なくともGPO自体は読み込まれており、何らかの形で追加処理は走っている |
| 手動で追加した「余計なアカウント」が gpupdate /force・再起動後も残る | 本来の「完全定義（一覧以外は削除）」が完遂していない／削除フェーズが失敗・スキップしている |
| RSoPの「Administrators (Group name)」に赤い×、 「An unknown error occurred when attempting to open the database」 | セキュリティ拡張（Security Extension）の処理がエラーになっている可能性が高い（ローカルのセキュリティDB関連が典型） |
| winlogon.log が存在しない | ログが無効、もしくは出力できないほど早い段階で失敗、または出力先／権限の問題があり得る |
Restricted Groups の基本動作（ここがズレると迷走する）
Restricted Groups には大きく2つの指定方法があります。似ていますが挙動が違うため、トラブル時はここを最初に揃えます。
| 設定項目 | 挙動 | 今回の目的との相性 | よくある落とし穴 |
|---|---|---|---|
| このグループのメンバー（Members of this group） | 指定した一覧が「完全な答え」になり、一覧にないメンバーは削除される | ◎（不要ユーザーを排除したい） | 存在しないアカウントを1つ混ぜるだけで処理が不安定になることがある |
| このグループがメンバーである（This group is a member of） | 対象グループを、別のグループへ所属させる（“入れる側”の設定） | △（設計次第） | 「削除」目的なのにこちらだけ設定してしまい、意図と違う |
今回の「Administrators を完全定義して、余計なものは消したい」ケースは、必ず「このグループのメンバー」側で設計します。
なぜ「追加はされるのに削除されない」ことが起きるのか
Restricted Groups の更新は、グループポリシーの中でもセキュリティ拡張（Security Settings 系）が担います。ここが失敗すると、RSoPに赤い×が出たり、イベントログに SceCli/GroupPolicy のエラーが残ったりします。
そして厄介なのが、失敗の仕方によっては
- “追加だけが残って見える”
- “削除が行われない”
- “そもそも更新されていないが、別要因で増えたように見える”
のように、現場の見え方が揺れます。だからこそ、ログと検証手順で「失敗地点」を特定するのが最短です。
原因候補の優先順位（現場でハマりやすい順）
スレッドの状況（RSoPの赤い×＋ database エラー）を踏まえると、優先度は次の順番が現実的です。
| 優先 | 原因候補 | 一致しやすい症状 | 早い見分け方 |
|---|---|---|---|
| 高 | Restricted Groups に存在しないユーザー／グループが混入 （スペルミス、削除済み、ドメイン名違い） | 追加はされるが期待通りの完全置換にならない／端末によって差が出る | AD解決（SID変換）テスト、winlogon.logで「Cannot find」系 |
| 高 | ローカル セキュリティポリシー DB の不具合／破損 （典型：secedit.sdb周辺） | RSoPに「open the database」／SceCliエラー | イベントログ、セキュリティDBの再構築で改善する |
| 中 | DNS／ネットワーク不良でDC・SYSVOL到達が不安定 | 一部サーバーのみ再現、GPO適用自体が揺れる | SYSVOLアクセス、SRVレコード解決、nltest |
| 中 | 元のGPO自体の不整合・内部破損 | 新規GPOだと直る | Restricted Groupsだけの新規GPOで再現性比較 |
| 中 | 複数GPOの競合（別GPOでもRestricted Groupsを触っている） | 「どれが勝っているか」端末・OUで変わる | gpresult /h、RSoPでWinning GPO確認 |
切り分け：最短で原因に近づくチェックリスト
ここからは「作業順」を固定して、迷いを減らします。先に“観測”→ 次に“ログ”→ 最後に“破壊的な復旧”の順が安全です。
Administrators の現物を必ず確認する
RSoPの表示が正しくても、実際のローカルグループが変わっていないなら意味がありません。まずは現物確認を固定手順にします。
- GUI：lusrmgr.msc（ローカル ユーザーとグループ）→ Groups → Administrators
- CUI（どちらかでOK）
net localgroup Administratorspowershell -NoProfile -Command "Get-LocalGroupMember -Group 'Administrators' | Select-Object Name,ObjectClass,PrincipalSource"そして、検証は必ず同じパターンで行います。
- 余計なアカウントを1つ、手動で追加する（検証用）
gpupdate /forceを実行- 可能なら再起動（サーバー運用都合で難しければログオンし直しでも比較）
- もう一度
net localgroupで残っているか確認
イベントログで「セキュリティ拡張」の失敗を掴む
RSoPの赤い×があるなら、イベントログにも痕跡が残ることが多いです。まずここを押さえると、闇雲な再作成が減ります。
| ログ | 見る場所 | 注目ポイント |
|---|---|---|
| システム | イベント ビューアー → Windows ログ → システム | ソース：GroupPolicy / SceCli の警告・エラー |
| セキュリティ | イベント ビューアー → Windows ログ → セキュリティ | 監査設定が絡む場合に痕跡が出ることがある |
| GPO詳細 | アプリケーションとサービス ログ → Microsoft → Windows → GroupPolicy → Operational | どの拡張が、どのタイミングで、何を失敗したか |
「An unknown error occurred when attempting to open the database」に近い文言が出る場合、ローカルのセキュリティDB周り（後述）に寄せて調査します。
winlogon.log を確実に出す（出ないなら“出ない理由”を潰す）
Restricted Groups（セキュリティ設定）のデバッグは、winlogon.log が最短ルートです。ファイルが存在しない場合は、まず「有効化」と「書き込み先」を揃えます。
デバッグログの有効化（Security 拡張）
次のレジストリに ExtensionDebugLevel を設定します。
キー:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
値:
ExtensionDebugLevel (DWORD) = 2設定後に以下を実行します。
gpupdate /forceログの出力先は多くの環境で次です。
C:\Windows\security\logs\winlogon.logwinlogon.log が作られないときの確認ポイント
| 確認項目 | 狙い | やること |
|---|---|---|
| フォルダの存在 | 出力先が無いと作れない | C:\Windows\security\logs があるか確認（無ければ権限に注意して作成） |
| ディスク空き容量 | セキュリティDBもログも書けない | システムドライブの空き、イベントログのエラーも併せて確認 |
| EDR/AVの干渉 | セキュリティ領域をロックしていることがある | 一時的に除外設定（Windows\security 配下）を検討（運用ルールに従う） |
存在しないアカウント混入を「機械的に潰す」
Restricted Groups に1つでも解決できないユーザー／グループ名が混ざると、端末側の処理が不安定になることがあります。体感としては「追加はされるのに削除だけ効かない」「一部サーバーだけ崩れる」など、最も厄介な形になりがちです。
まずはGPO側の一覧を棚卸しする
- Admins GPO → Restricted Groups → Administrators → 「このグループのメンバー」一覧を全件確認
- 削除済みアカウント、テスト用残骸、スペルミス、別ドメイン表記がないか確認
- 個人ユーザー直書きが多いなら、運用として見直す（後述）
サーバー側で「SIDに変換できるか」をテストする
名前は合っているつもりでも、サーバーから見た名前解決（ドメイン到達、信頼関係、DNS）が不安定だと失敗します。PowerShellでのSID変換テストは、現場で再現性が高いです。
powershell -NoProfile -Command ^
"$name='DOMAIN\SomeUserOrGroup'; ^
try { ^
([System.Security.Principal.NTAccount]$name).Translate([System.Security.Principal.SecurityIdentifier]).Value ^
} catch { ^
'FAILED: ' + $_.Exception.Message ^
}"一覧の全メンバーに対してこのテストを回し、FAILED が出るものはGPOから修正・削除を最優先にします。
「open the database」エラーの本命：ローカル セキュリティDBの修復・再構築
RSoPに「An unknown error occurred when attempting to open the database」が出ているなら、名前の通り“端末ローカルのセキュリティデータベース”を開けていない可能性があります。Restricted Groups はこの領域に依存するため、ここが壊れていると期待通りの置換ができません。
作業前の注意（運用で事故らないために）
- 可能ならメンテナンス時間を確保（再起動を伴う可能性がある）
- ローカルセキュリティポリシーを手動でカスタムしている環境は影響範囲が広いので、事前にバックアップや手順確認を行う
- ドメインGPOでほぼ上書きされる設計なら、再構築のリスクは相対的に下がる
セキュリティポリシーのエクスポート（保険）
secedit /export /cfg C:\Temp\secpol_backup.infこのファイルは「戻す」ための万能薬ではありませんが、差分確認や状況証拠として有効です。
代表的な復旧アプローチ
環境差があるため、現場で採用されやすい順に紹介します。
アプローチA：デフォルトセキュリティテンプレートで再初期化
もっとも手堅いのは、デフォルトテンプレートを使ってローカルセキュリティ設定を再生成し、その後にGPOを再適用する流れです。まず %windir%\inf 配下にテンプレートがあるか確認します。
dir %windir%\inf\deflt*.inf多くの環境では defltbase.inf が使えます（見つからない場合は、そのOSに存在するテンプレートを選びます）。
secedit /configure /cfg %windir%\inf\defltbase.inf /db C:\Windows\security\Database\defltbase.sdb /verbose完了後に再起動し、あらためて以下を実行します。
gpupdate /forceアプローチB：セキュリティDB（secedit.sdb）を再作成させる
「open the database」が強く疑われる場合、セキュリティDB自体の再生成が効くことがあります。ただし、ファイルがロックされていてリネームできない場合があるため、手順は環境の運用ルール（セーフモード、オフラインメンテ等）に合わせてください。
対象になりやすいパス例：
C:\Windows\security\Database\secedit.sdb実施イメージ（例）：
secedit.sdbをバックアップ名にリネーム- 再起動
gpupdate /forceで再適用- RSoPの赤い×が消えるか、Administratorsのメンバー置換が動くか確認
この手順は「壊れたDBを捨てて作り直す」発想なので、影響を読めない環境ではアプローチAを優先し、必要なら段階的に進めます。
復旧できたかの判定基準
「直った気がする」で終わらせないために、判定を固定します。
| 判定項目 | 合格ライン |
|---|---|
| RSoP | Administratorsの項目で赤い×が消える（少なくとも database エラーが出ない） |
| ローカルAdministrators | 手動で追加した検証用アカウントが、GPO適用後に削除される |
| イベントログ | GroupPolicy/SceCli の同種エラーが再発しない |
| winlogon.log | 明確なエラー（Cannot find / database / unknown error）が消える、または原因が特定できる形で出る |
DNS・ネットワーク起因の「一部サーバーだけ壊れる」を潰す
Restricted Groups はドメインアカウントの解決やGPO取得に依存します。DNSがブレると、名前解決がたまに失敗し、結果的に処理が揺れます。
最低限の確認コマンド
ipconfig /allDNSサーバーがAD統合DNS（通常はDC）を向いていることを確認したうえで、SRVレコードを引けるかを見ます。
nslookup _ldap._tcp.dc._msdcs.<ドメイン名>SYSVOLへ到達できるかもセットで確認します。
\\<ドメイン名>\SYSVOLさらに、ドメインとのセキュアチャネルが怪しい場合は次も有効です。
nltest /sc_verify:<ドメイン名>ここで揺れがあるなら、Restricted Groups の問題に見えても本質はネットワーク／DNS／ドメイン参加状態です。まずそこを直すと、GPO側の見直しを最小限にできます。
GPOそのものの破損・競合を疑うときの実験方法
10か月は正常だったのに「最近、一部サーバーだけ」崩れた場合、GPOの破損や競合、OU設計変更の影響が紛れていることがあります。ここは再現性の取れる実験で潰します。
Restricted Groups だけの“ミニGPO”を新規作成して比較する
- Administrators の Restricted Groups 設定だけを持つGPOを新規作成
- テスト用OUを用意し、問題サーバーを一時的に移動
- そのOUにはミニGPOのみリンク（既存GPOは外す／リンク順も固定）
- gpupdate /force → 再起動 → Administrators のメンバーが完全置換されるか確認
| 結果 | 示唆 | 次の一手 |
|---|---|---|
| ミニGPOだと削除も効く | 元のAdmins GPOの不整合／競合の可能性が高い | 設定を新GPOへ移植して置き換え、競合GPOを整理 |
| ミニGPOでも削除が効かない | 端末側（セキュリティDB、名前解決、OS固有）の問題が濃厚 | winlogon.log・SceCli・DB再構築を優先 |
「赤い×」は本当に原因か？結論：原因というより“結果”
RSoPの赤い×は、ざっくり言えば「そのカテゴリの処理が正常完了していない」サインです。今回のように database エラーが併記される場合、赤い×そのものを消しに行くのではなく、
- 存在しないアカウント混入
- ローカルセキュリティDB（open the database）
- 名前解決・SYSVOL到達
のいずれかを直した結果として、赤い×も消える、という順番になります。
運用の改善：Restricted Groups を“壊れにくく”する設計
最後に、同じ事故を繰り返さないための運用寄りのポイントです。Restricted Groups は便利ですが、設計が雑だと「誰かが消した／作った」の影響を直に受けます。
個人ユーザー直書きを減らし、ADグループに寄せる
推奨は、Restricted Groups の一覧には「役割グループ」を入れ、個人ユーザーはその役割グループで管理する方式です。
| 方式 | メリット | デメリット |
|---|---|---|
| 個人ユーザーをGPOに直書き | 即時で分かりやすい | 退職・改名・移籍で「存在しないエントリ」が混入しやすい |
| 役割グループ（例：SG-Server-LocalAdmins）をGPOに指定 | GPOが安定し、変更頻度が下がる／棚卸ししやすい | グループ設計の初期コストがある |
Restricted Groups を触るGPOを1つに集約する
Restricted Groups は「勝ったGPOが答え」になりがちで、複数箇所で触ると運用事故が起きます。Administrators の完全定義をするなら、Administrators を定義するGPOは1つ、を原則にするとトラブルが激減します。
“いつの間にか増えている”を監視する
「削除されない」トラブルは、気づくのが遅れるほど危険度が上がります。少なくとも重要サーバーは、定期的に次のようなコマンドの出力を収集して差分監視すると安全です。
net localgroup Administrators運用監視に乗せられるなら、PowerShellでの定期収集＋差分検知（監査ログ連携）まで作ると、Restricted Groups の不調も早期に発見できます。
よくある質問（詰まりポイントだけ）
gpupdate /force だけで削除されるはず？再起動は必要？
環境によって見え方が変わりますが、「セキュリティ設定」系は更新タイミングが絡むため、検証では再起動までセットにすると判定が安定します。まずは「再起動しても消えない」ことを確認し、そのうえで原因追跡に進むのが確実です。
RSoPに正しいメンバーが出ているのに、なぜ現物が変わらない？
RSoPは「ポリシーとしてこうなるはず」を表示しますが、実際の適用が失敗すれば現物は変わりません。今回の赤い×＋ database エラーは、まさにそのギャップを示す典型です。
一部サーバーだけで起きるのはなぜ？
端末ローカルのセキュリティDB破損や、DNS設定・ドメイン到達性の揺れ、EDR/AVの干渉など、端末固有要因が入ると「一部だけ」になります。だからこそミニGPO実験と、winlogon.log／イベントログの併用が効きます。
Restricted Groups の「削除が効かない」は、見た目以上に原因が絞れます。①存在しないエントリの排除 → ②ログで失敗地点の特定 → ③必要ならセキュリティDB再構築の順で進めれば、遠回りせず復旧できます。
コメント