Active Directory の GPO をセキュリティグループで絞り込んだのに、gpresult では未適用、RDP も「リモート ログインを許可されていない」で拒否される――そんなときは「その設定はユーザー向けか、コンピューター向けか」を取り違えているケースが非常に多いです。User Rights Assignment（ユーザー権利の割り当て）を題材に、原因と確実な対処を具体例つきで解説します。
今回の症状を整理：セキュリティフィルタリングしたのに GPO が適用されない
よくある構成は次のとおりです。
- OU「Staff」を作成して GPO（例：Manager Policy）をリンクした
- GPO のセキュリティフィルタリング（Delegation/Advanced）で Authenticated Users の「Apply group policy」を外し、代わりに セキュリティグループ（Managers）へ「Apply group policy」 を付与して対象を絞った
- GPO 内は Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment を編集し、
- “Access this computer from the network”（ネットワークからこのコンピューターへアクセス）
- “Allow log on through Remote Desktop Services”（RDP のログオン許可）
gpupdate /forceをしてもgpresultでは GPO が未適用、RDP 接続も拒否される
結論から言うと、この手の「GPO が適用されない」は、GPO のリンク先 OU とセキュリティフィルタリングの“対象”がズレていることが原因になりがちです。特に User Rights Assignment はクセが強く、勘違いしやすいポイントがあります。
最重要ポイント：User Rights Assignment は「コンピューターに適用されるポリシー」
質問で編集しているのは Computer Configuration 配下 です。つまり、その GPO はユーザーではなくコンピューター（PC/サーバー）に適用されます。
| 項目 | 場所（GPO） | 適用対象 | リンク先 OU で見るべきオブジェクト | よくある勘違い |
|---|---|---|---|---|
| User Rights Assignment | Computer Configuration | コンピューター | コンピューターアカウント（例：SERVER1$） | ユーザー OU にリンクすればユーザーに効くと思う |
| ログオンスクリプト/ユーザー設定 | User Configuration | ユーザー | ユーザーアカウント | サーバー OU にリンクすればサーバー上のユーザーに効くと思う（※別の仕組み） |
この性質のため、OU「Staff」にユーザーしか入っていない状態だと、どれだけ「Managers」グループで絞っても、コンピューター向けポリシーは適用されません。gpresult で出てこないのは、この時点で説明がつきます。
「ユーザーに権限を与える設定」なのに、なぜコンピューターに適用されるのか
User Rights Assignment は「どのユーザー／グループが、そのコンピューターで何を許可されるか」を決める仕組みです。“権利を持つ主体”はユーザーですが、“設定が保存され反映される先”はコンピューターです。
つまり、RDP を許可したい対象が「Managers（ユーザー）」であっても、GPO 自体は「SERVER1（コンピューター）」へ適用される必要があります。
根本原因になりやすい 2 点：リンク先 OU とセキュリティフィルタリング
リンク先 OU が正しいか：対象サーバー（コンピューターアカウント）はそこに存在するか
まず確認すべきは単純で、しかし見落とされがちな点です。
- GPO をリンクしている OU「Staff」に、対象サーバーのコンピューターオブジェクト（例：SERVER1）は入っていますか？
- サーバーが別 OU（例：OU=Servers、または既定の Computers コンテナ）にいるなら、GPO はそちらの OU にリンクする必要があります。
よくある実務パターンとして、ユーザーは「OU=Staff」、サーバーは「OU=Servers」に分けます。User Rights Assignment はサーバーのローカルセキュリティに効くため、OU=Servers（コンピューターがいる場所）にリンクするのが基本です。
対処（どちらか）
- 対象サーバーのコンピューターアカウントを、GPO をリンクしている OU（例：Servers OU）へ移動する
- サーバーがいる OU（またはサーバーをまとめた OU）に GPO をリンクし直す
セキュリティフィルタリングの対象が正しいか：「Managers」は“ユーザーのグループ”
Authenticated Users の “Apply group policy” を外して絞り込む運用はよくありますが、ここで重要なのが、コンピューター向け GPO は「コンピューター（またはコンピューターが所属するグループ）」で絞る必要がある、という点です。
今回の「Managers」はユーザーが入るグループです。ところが、コンピューターが GPO を処理する際の判定は基本的にコンピューターアカウントのトークン（所属グループ）で行われます。したがって、
- Managers に Apply を付けても、コンピューター側の適用判定には噛み合わない
- 結果として GPO が “適用対象外（フィルタリング）” 扱いになり、gpresult に出ない
という状況が起きます。
「GPO はコンピューターに適用」「権利はユーザーに付与」——正しい設計に直す
ここまでの話を一言でまとめると、次の設計に変えるのが最短で安全です。
- GPO の適用対象（リンク先 OU / セキュリティフィルタリング）は「どのサーバー（コンピューター）に効かせたいか」で決める
- User Rights Assignment の中身で「どのユーザー／グループ（Managers など）を許可するか」を定義する
「Managers だけに適用したいから、GPO の適用を Managers に絞る」という発想は、User Rights Assignment では遠回りになりがちです。サーバーに適用さえできれば、権利の付与対象はポリシーの中でコントロールできます。
おすすめ構成（現場でトラブルが減る定番）
| 要素 | おすすめ | 理由 | 例 |
|---|---|---|---|
| GPO リンク先 | サーバーが入る OU | コンピューターポリシーはコンピューターの場所で決まる | OU=Servers |
| セキュリティフィルタリング | サーバー（コンピューター）を入れたグループ | “どのサーバーに適用するか” を明確化できる | GPO_Target_RDP_Servers（中身：SERVER1$, SERVER2$） |
| User Rights Assignment の中身 | 許可したいユーザー/グループを追加 | RDP 許可などは「そのサーバー上で誰がログオンできるか」を決めるため | Managers（ユーザーグループ）を “Allow log on through RDS” に追加 |
やることチェック：この順番で直すと迷わない
「gpresult で未適用」状態からの復旧は、次のチェックを上から潰すのが効率的です。
| チェック項目 | 確認方法 | OK の状態 | NG のときの典型対処 |
|---|---|---|---|
| GPO のリンク先 OU に対象コンピューターがいるか | ADUC / GPMC で OU を確認 | SERVER1（コンピューター）が OU 配下 | サーバーを OU に移動 / リンク先をサーバー OU に変更 |
| GPO の Computer Configuration が有効か | GPMC > GPO 状態 | Computer Configuration が有効 | 「User Configuration settings disabled」等になっていないか確認 |
| セキュリティフィルタリングでコンピューターが許可されているか | GPMC > Security Filtering / Delegation(Advanced) | 対象コンピューター（またはグループ）に Read + Apply | コンピューターを含むグループに Read/Apply を付与 |
| gpresult は「コンピューター」スコープで見ているか | gpresult /r /scope computer | Computer Settings に対象 GPO が表示 | scope が user になっていないか見直す |
| コンピューターのグループ所属が反映されているか | グループ追加後の挙動 | 再起動後に適用される | サーバー再起動（トークン更新） |
| 別 GPO で User Rights が上書きされていないか | GPMC のリンク順 / gpresult /h | 想定の GPO が勝っている | リンク順・継承・Enforced を再設計 |
実際の直し方：セキュリティフィルタリングを「コンピューター基準」に作り替える
「Authenticated Users を外したまま」絞り込みたい場合の最小セット
Authenticated Users の Apply を外すのは可能ですが、その場合は対象にしたい主体へ “Read と Apply” の両方が必要です。片方でも欠けると、GPO は適用されません。
おすすめの手順
- サーバー（コンピューターアカウント）だけを入れるセキュリティグループを作成する（例：GPO_Target_RDP_Servers）
- そのグループに対して、GPO の Delegation/Advanced で Read と Apply group policy を許可する
- Managers（ユーザーグループ）にはセキュリティフィルタリングを付けない（権利付与は User Rights Assignment の中身で行う）
「ユーザー権利の割り当てを Managers に設定したい」のに、「GPO の適用を Managers に絞る」という二重のフィルタリングをすると、今回のような混乱が起きます。GPO はサーバーに適用さえできれば OK、という割り切りが大切です。
まず適用確認だけしたい場合：Authenticated Users を一時的に戻す
切り分けとして非常に有効なのが、「まずは GPO が適用される状態を作る」ことです。運用上は絞り込みたいとしても、トラブルシュート中は一時的に次のようにします。
- Authenticated Users の Apply group policy を一時的に許可する（＝フィルタリングを緩める）
- その状態で
gpupdate /force→gpresultを確認し、適用できることを先に確かめる - 適用が確認できたら、改めて コンピューターグループで絞る設計に戻す
このやり方だと、「リンク先 OU が違うのか」「セキュリティフィルタリングが原因なのか」を短時間で切り分けできます。
コンピューターのグループ所属変更は“再起動”が効く：gpupdate だけでは足りないことがある
セキュリティグループで絞る場合、見落としがちなのがトークン更新です。コンピューターアカウントをグループに追加しても、その所属情報が OS 側で再評価されないと、GPO の絞り込みに引っかかりません。
| 対象 | 所属グループ変更の反映タイミング | 実務で効く対処 |
|---|---|---|
| コンピューター | 起動時に更新されることが多い | 再起動（最短で確実） |
| ユーザー | サインイン時に更新されることが多い | サインアウト→サインイン |
今回のように「コンピューターグループでフィルタリング」へ直した場合、サーバーを再起動してから gpresult を取り直すのが鉄板です。
gpresult の正しい見方：User Rights Assignment は “Computer Settings” に出る
「gpresult を見たけど出ていない」というとき、見ているスコープが user 側になっていることがあります。User Rights Assignment は Computer Configuration なので、確認はコンピューター側を明示します。
コマンド例（対象サーバー上で実行）
gpupdate /force
gpresult /r /scope computer
gpresult /h C:\Temp\gpresult.html/scope computerで Computer Settings を確認するgpresult /hは「適用された/されなかった理由（Security Filtering / WMI / 権限不足など）」が追いやすい
もし「The following GPOs were not applied because they were filtered out」などの表示がある場合、理由として Security Filtering が出ることが多いです。その場合はリンク先 OU とフィルタリング主体（ユーザー/コンピューター）のズレを最優先で疑ってください。
User Rights Assignment の注意点：複数 GPO で上書きされやすい（“追加”ではなく“置き換え”）
User Rights Assignment は、GPO を適用したときに「既存の権利に足される」感覚で触ってしまいがちですが、実際には GPO 側で定義した内容に置き換えが発生します。これが原因で、意図せず RDP できなくなるケースが少なくありません。
特に重要なのが次の 2 つです。
- Allow log on through Remote Desktop Services（RDP のログオン許可）
- Deny log on through Remote Desktop Services（RDP のログオン拒否）
例えば「Managers だけを許可」にしたつもりで、Administrators や Remote Desktop Users を外してしまうと、管理者でも入れなくなる事故が起きます。運用では次の考え方が安全です。
- RDP を許可するエントリに Managers（許可したいグループ）を足す
- 同時に Administrators など最低限の管理系主体を残す（環境ポリシーに合わせる）
- 「拒否（Deny）」側に意図せず入っていないかも必ず確認する
| 設定名（表示） | 内部名（参考） | 効く対象 | 誤設定の典型症状 |
|---|---|---|---|
| Access this computer from the network | SeNetworkLogonRight | 共有フォルダ、リモート管理などの“ネットワークログオン” | ファイル共有や管理系接続が拒否される |
| Allow log on through Remote Desktop Services | SeRemoteInteractiveLogonRight | RDP ログオン | 「リモート ログインを許可されていない」で拒否 |
| Deny log on through Remote Desktop Services | SeDenyRemoteInteractiveLogonRight | RDP ログオン拒否 | 許可側に入れても拒否側が勝って弾かれる |
なお、「Access this computer from the network」を設定している理由が「RDP できるようにしたい」だけであれば、まずは RDP 権限（Allow log on through RDS）に集中した方が切り分けが早いです。ネットワークログオン権利は別の用途（SMB/管理系接続）にも影響するため、むやみに狭めると別障害を生みます。
それでも RDP が拒否されるとき：GPO 以外のチェックポイント
今回の主原因は「GPO が未適用」ですが、GPO を正しく適用しても RDP が通らないことはあります。RDP は複数要素で成立しているため、次も併せて確認すると再発防止になります。
| 観点 | 確認する場所 | よくある落とし穴 | 対処例 |
|---|---|---|---|
| RDP 自体が有効か | サーバーのシステム設定 / GPO（Remote Desktop を許可） | 接続自体が無効（拒否メッセージが別になることも） | RDP を有効化、必要ならポリシーで統制 |
| Windows ファイアウォール | 受信規則（Remote Desktop） | ネットワークプロファイルで閉じている | 適切なプロファイルで規則を許可 |
| ローカルグループ | Remote Desktop Users / Administrators | 権利はあるがローカルグループ運用と矛盾 | グループ運用を統一（Restricted Groups 等） |
| NLA/資格情報 | イベントログ/資格情報 | 権利不足ではなく認証側で弾かれている | イベント ID を見て原因切り分け |
「リモート ログインを許可されていない」は、特に Allow log on through Remote Desktop Services（SeRemoteInteractiveLogonRight） が不足しているときに出やすいメッセージです。ここが通るようになったら、次にファイアウォールや RDP 有効化の要素を見ていくとスムーズです。
運用で失敗しないコツ：GPO 名・グループ名・適用範囲を“役割”で揃える
GPO を増やしていくほど「どれがどこに効いているか」が見えにくくなり、結果として「GPO が適用されない」相談が増えます。最初から運用ルールを作ると、後々の調査が圧倒的に楽になります。
- GPO 名は “何をする GPO か” が一目で分かる名前にする（例：GPO_Server_UserRights_RDP_Managers）
- セキュリティフィルタリング用グループは “どのコンピューターに適用するか”で命名（例：GPO_Target_RDP_Servers）
- 権利付与対象（Managers 等）は 設定の中身（User Rights Assignment）で表現し、フィルタリングで無理に混ぜない
- いきなり本番 OU にリンクせず、検証 OU（Pilot）で適用確認→段階展開する
まとめ：この問題の答えは「コンピューターに適用する設計」に戻すこと
- Computer Configuration の設定（User Rights Assignment）は、コンピューターが入っている OU にリンクしないと適用されない
- セキュリティフィルタリングで絞るなら、ユーザーグループ（Managers）ではなく、コンピューターアカウント（またはそれを含むグループ）で絞る
- コンピューターのグループ所属変更は、再起動で反映されることが多い（gpupdate だけでは足りないことがある）
- RDP の許可は GPO の適用とは別に、User Rights Assignment が上書き型である点にも注意する（管理者まで締め出さない）
「GPO が適用されない」を最短で解消する近道は、まずGPO を“対象サーバー（コンピューター）に確実に適用”させることです。その上で、User Rights Assignment の中で Managers を許可する――この順序に直すと、gpresult と実際の挙動が一致し、原因追跡も一気に楽になります。
コメント