日常的にサーバー運用を行う中で、グループポリシー (GPO) によるローカル グループの管理やファイル配布設定は非常に便利です。しかし、一度設定したルールやターゲットを変更した際に、意図しない再追加や対象外のはずのサーバーが処理されるといったトラブルが発生することもあります。ここでは、そうした問題の原因と対策をわかりやすく解説します。
GPOでローカルAdministratorsグループへ再度追加されてしまう問題
GPOを活用してローカルAdministratorsグループに特定のユーザーやグループを追加する設定を行った後、対象サーバーの移動やグループの変更を行っても、なぜか再び追加されてしまう……。この現象はさまざまな要因で発生します。以下では、考えられる原因と具体的な対処方法を詳しく紹介します。
GPOスコープとアクションの基本理解
GPOの「Local Users and Groups (ローカル ユーザーとグループ)」設定では、以下の4種類のアクションを選ぶことができます。
| アクション (Action) | 内容 |
|---|---|
| Create (作成) | 指定したローカルユーザーやグループが存在しない場合のみ新規に作成します。既に存在する場合は変更しません。 |
| Replace (置換) | 常に既存の設定を置換します。すでに同名のローカルユーザー/グループがあれば削除され、新たに指定したメンバー構成が適用されます。 |
| Update (更新) | 既存のものに対して指定した設定を追加・更新します。存在しない場合は新規に作成されるため、「追記」的な動きとなる点がポイントです。 |
| Delete (削除) | 指定したユーザーやグループをローカルから削除します。 |
もし意図せず再追加される場合、「Update」が設定されており、GPO適用のたびに追記される動きになっている可能性があります。また、「Replace」アクションの場合、GPOが適用されるたびに常に上書きされるため、ローカルで削除しても再び追加されるケースがあります。
アクションの再確認
- Group Policy Management Console (GPMC) で当該のGPOを開き、「コンピューターの構成」→「環境設定」→「コントロール パネルの設定」→「ローカル ユーザーとグループ」を確認します。
- 問題のエントリをダブルクリックし、「Common (共通)」タブではなく「Properties (プロパティ)」タブのAction (アクション)が何になっているかチェックします。
- 特に「Update (更新)」や「Replace (置換)」を使用している場合は、意図しないサーバーであっても再追加が行われる可能性があるため注意が必要です。
アイテムレベル ターゲットの再確認
GPO環境設定の「Common (共通)」タブにある「Item-level targeting (アイテムレベル ターゲット)」は、より細かい条件設定を可能にします。しかし、構成が複数あったり、OUレベルやWMIフィルターなどと組み合わさっていたりすると、狙った通りのサーバーだけから除外されていないケースが出てきます。
- ターゲットとなっているセキュリティグループやコンピューターグループを正しく設定しているか確認してください。
- サーバーを移動しただけでは、GPOのリンク先のOUやセキュリティフィルタリング条件が変わらない可能性があります。移動先のOUで別のポリシーが同じ設定を行っていないか見直しましょう。
- 同一ドメイン内に複数のGPOがある場合、どの順番で適用されているか (GPResult ツールなどで) をチェックし、別のGPOが同様の設定を上書きしていないか確認します。
gpresult での適用状況把握
トラブルシューティングの王道として、gpresult コマンドは非常に有用です。以下は一例です。
gpresult /h C:\gpresult.html上記コマンドを実行すると、HTML形式でレポートが生成されます。ブラウザで開けば、どのGPOが適用されたか、何が拒否されたかが一覧で分かりやすく確認できます。意図しないGPOが適用されていないか、もしくは今回外したはずのサーバーが別のGPOで対象になっていないか、しっかりチェックしてみてください。
ユーザーセクションでのファイル更新とアイテムレベル ターゲット
次に、GPOの「ユーザー構成」配下でファイル更新やコピーを行いたい場合に、ユーザーグループをターゲットに指定できず困るケースについて解説します。アイテムレベル ターゲットのUI上でユーザーグループを参照できない問題が見られる場合は、以下の点を確認してください。
ユーザー側とコンピューター側の違い
GPOには大きく分けて「コンピューターの構成 (Computer Configuration)」と「ユーザーの構成 (User Configuration)」があります。基本的には、コンピューターの構成はコンピューターアカウントが対象、ユーザーの構成はユーザーアカウントが対象となる仕組みです。
- ユーザーセクションで「ユーザーグループ」をターゲット条件にしたい場合、対象となるユーザーがログオンしていることが前提となり、コンピューター セクションとはやや動きが異なります。
- ユーザーセクションでドメイングループを指定できない、あるいはローカルグループしか表示されない場合は、グループスコープ (グローバルグループ/ユニバーサルグループなど) の違いが影響していることも考えられます。
グループスコープの確認
Active Directory上のグループには、以下のスコープが存在します。
- グローバルグループ (Global Group)
- ユニバーサルグループ (Universal Group)
- ドメインローカルグループ (Domain Local Group)
たとえば、ドメインローカルグループやユニバーサルグループが配置されている場所によっては、ユーザーセクションのアイテムレベル ターゲットで一覧に出てこないことがあります。必ずしもすべてのグループが候補に表示されるわけではない点に注意しましょう。
別の方法で条件分岐を実現するには
どうしてもアイテムレベル ターゲットでユーザーグループを選べない場合、下記の代替策があります。
- WMIフィルターを活用する
ユーザーだけに限らず、OSのバージョンやコンピューター属性など、いろいろな条件を設定できます。ただし、ユーザーグループそのものをWMIで直接判別するのは難しい場合があるので、実現できるかどうかをあらかじめテストしておきましょう。 - セキュリティフィルタリング
GPOの「セキュリティ フィルタリング」で対象を特定のユーザーやグループに絞り込みます。これによって、そもそもそのユーザーやグループにしかGPOが適用されないようになります。アイテムレベル ターゲットが使えない場合でも、セキュリティ フィルタリングなら汎用的に利用できます。 - スクリプトによるコントロール
ログオン スクリプトやスタートアップ スクリプトでグループ判定を行い、条件を満たせばファイルをコピーする、といった方法です。例えばPowerShellスクリプトでユーザーが所属するグループを判定し、条件合致時にファイル操作を行う、といった実装が考えられます。
以下はPowerShellの例です。
# ユーザーが所属するグループを取得し、条件に応じてファイルをコピーするスクリプト例
$userGroups = [System.Security.Principal.WindowsIdentity]::GetCurrent().Groups |
ForEach-Object { $_.Translate([System.Security.Principal.NTAccount]) }
if($userGroups -match "YourDomain\\TargetUserGroup"){
# ファイルのコピー処理
Copy-Item -Path "\\Server\Share\SourceFile.txt" -Destination "C:\LocalFolder"
}このようにGPOを使わずにスクリプトで制御することで、アイテムレベル ターゲットの制約を回避できます。
トラブルシューティング時のポイント
GPOでアイテムレベル ターゲットを用いた設定がうまく動かない場合は、イベントログやgpresultを併用して原因を特定するのが有効です。特にユーザー構成のポリシーが実際にいつどのユーザーに対して適用されたかを知るには、ユーザーが実際にログオンしている状態でgpresult /rなどを実行する必要があります。コンピューター構成とユーザー構成で異なる適用タイミングを持つ点を意識しましょう。
GPOトラブルを未然に防ぐためのベストプラクティス
多くの企業や組織で、GPOの管理には次のようなベストプラクティスが存在します。日頃からこれらのポイントを意識することで、トラブルを未然に防げる可能性が高まります。
1. GPOの設計と命名規則の確立
GPOにわかりやすい名前を付け、どのOUにリンクし、どのグループに対して、どのような目的で設定しているのかを誰が見ても理解できるようにしましょう。また、GPOの使い回しを避け、管理しきれない複雑さを生まないように注意します。
2. 既存GPOの影響範囲を明確化
既に運用されているGPOで、同様の設定が行われていないか定期的にチェックします。特にローカルAdministratorsグループへの追加に関しては、複数のGPOが同時に同じ操作を行うと競合リスクが高まります。GPResultやGPMCの「Group Policy Inheritance」タブで適用優先度を確認し、意図せず上書きされていないか常に目を光らせてください。
3. テスト OU とステージング環境の活用
いきなり本番環境のサーバーやクライアントに対してGPOを適用すると、思わぬトラブルが発生することがあります。テスト用に専用のOUを用意して検証を行い、十分に動作確認してから本番環境へ反映する流れを定着させることでリスクを大きく減らせます。
4. ポリシー変更時はアナウンスとドキュメント化を徹底
少しの変更であっても、どのサーバーにどのような影響があるのかを事前に整理し、関係者に周知することが重要です。設定変更の履歴を残しておくと、万が一トラブルが起きた際に原因を突き止めやすくなり、復旧もスムーズです。
まとめ
ローカルAdministratorsグループに対するGPO設定が意図せず再適用される問題は、アクション設定の見落としやアイテムレベル ターゲットの範囲設定、もしくは別のGPOとの重複が原因であることが多いです。また、ユーザー構成配下でのファイルコピーや更新におけるターゲット指定の問題は、GPOそのものの仕組みやグループのスコープ、セキュリティフィルタリングとの併用方法を正しく把握していないことが一因となるケースがあります。
これらのポイントを把握し、GPOがどのように適用され、どの条件下で処理されるかを明確にすることで、運用上のトラブルは大幅に減少します。日々の運用では、gpresult やイベントログを活用した検証とトラブルシューティングが鍵を握ります。もしどうしても解決できない場合は、スクリプトによる代替案やWMIフィルター、セキュリティフィルタリングなど、ほかの手段も柔軟に検討してみてください。
コメント