仮想マシンへRDP接続すると、ローカルの一般ユーザーだけが「The requested session access is denied」で弾かれ、ローカル管理者やドメイン管理者は入れてしまう──この症状は、ユーザーをRemote Desktop Usersに追加しただけでは解決しない“典型パターン”です。本記事では、原因を切り分けやすい順に、設定箇所と具体的な確認ポイント、すぐ効く対処をまとめます。
まず状況を整理：なぜ「管理者はOKで一般ユーザーはNG」になりやすいのか
RDPのログオン可否は、単に「Remote Desktop Usersグループに入っているか」だけで決まりません。RDP接続は最終的にOSのユーザー権利（ユーザー権利の割り当て）や、GPOの許可/拒否で判定されます。特に“拒否”は最優先で、許可よりも強く効きます。
| 状態 | よくある説明 | 現実に起きていること |
|---|---|---|
| ローカル管理者 / ドメイン管理者はログオンできる | RDPは有効なのでネットワークやポートの問題ではない | 「管理者だけ許可」の権利設定や、管理用セッション扱いで管理者だけ通っている可能性が高い |
| ローカル一般ユーザーは「The requested session access is denied」 | Remote Desktop Usersに入れたのにダメ | RDPが管理用セッション(/admin)を取りに行っている、またはログオン権限/拒否で落ちていることが多い |
| ドメイン参加VMで特に起きやすい | ローカル設定は触っていない | ドメインGPOで「RDSでログオン許可」がAdministratorsのみ、または「拒否」側にUsers等が入っているケースがある |
この症状の原因は大きく次の3つに整理すると、切り分けが速くなります。
- (A) 接続が“管理用セッション(/admin)”扱いになっている（RDPファイルの設定や接続方法が原因）
- (B) ログオン権限/拒否ポリシー（ローカル or GPO）が噛んでいる（ユーザー権利の割り当ての問題）
- (C) Azure ADログオン関連の要件不足（Azure VMでオンラインID/Azure ADで入ろうとしている場合）
最優先で見るべき：RDPが「管理用セッション(/admin)」になっていないか
「The requested session access is denied」で、管理者は入れるが一般ユーザーだけ弾かれる場合、まず疑う価値が高いのがRDPが管理用セッション（コンソール/管理用セッション）を要求しているパターンです。
WindowsのRDP接続には、通常のセッションとは別に「管理用セッション（/admin）」へ接続するルートがあります。ここに繋ぎに行くと、環境によっては非管理者が拒否されやすいことがあります。特に、以前に管理者が作った.rdpファイルをそのまま使い回していると起きやすいです。
.rdpファイルを確認する（最短で効くチェック）
保存しているRDPファイル（拡張子 .rdp）をメモ帳で開き、次の行が含まれていないか確認します。
- administrative session:i:1
この設定が入っていると、RDPクライアントは管理用セッションで接続しようとします。一般ユーザーで弾かれる原因になりやすい“見落としポイント”です。
対処：administrative session を無効化して接続し直す
- 該当行を削除する
- または administrative session:i:0 に変更する
- その後、Remote Desktopクライアント（mstsc）をいったん完全に閉じてから、新しく起動して接続する
「mstscを起動し直す」が重要です。RDP接続は過去の接続情報を引きずることがあり、.rdpファイルを直したのに挙動が変わらないように見えるケースがあります。確実に切り分けるなら、いったんmstscを終了し、必要ならPC側のセッションやプロセスを整理してから再接続してください。
管理用セッションになってしまう典型例
| 典型パターン | 何が起きるか | 対処 |
|---|---|---|
| 管理者が作った.rdpファイルを配布・使い回し | administrative session が有効のまま残る | .rdpから該当行を削除/0にし、mstsc再起動 |
| コマンドで mstsc /admin を使っていた | 管理用セッションへ接続する | /adminを付けずに接続（通常接続で試す） |
| 接続を保存したショートカットに/admin相当の設定が残る | 意図せず管理用セッション要求になる | 接続設定を作り直す（新規.rdp） |
ここで一般ユーザーが入れるようになれば、原因は(A)です。もし変化がない場合、次は(B)の「ユーザー権利/拒否ポリシー」を見に行きます。
Remote Desktop Usersに入れても直らない本丸：ユーザー権利の割り当て（許可/拒否）
WindowsはRDPログオンを、次の権利（ユーザー権利の割り当て）で判断します。
- 許可：「リモート デスクトップ サービスを通じてログオンを許可する」
- 拒否：「リモート デスクトップ サービスを通じてログオンを拒否する」
- 拒否：「ローカルでログオンを拒否する」
ポイントは、拒否が1つでも当たると強制的に失敗することです。Remote Desktop Usersに入っていても、拒否側に対象ユーザー（または所属グループ）が入っているとログオンできません。
チェックすべき項目（最重要）
| 種類 | 項目名 | 重要ポイント | 推奨の考え方 |
|---|---|---|---|
| 許可 | リモート デスクトップ サービスを通じてログオンを許可する | ここにユーザー/グループが入っていないと基本的にログオン不可 | 運用上は「Remote Desktop Users」または専用グループを入れる |
| 拒否 | リモート デスクトップ サービスを通じてログオンを拒否する | ここに入っていると許可を上書きして必ず拒否 | UsersやAuthenticated Users等を入れると被害が大きい |
| 拒否 | ローカルでログオンを拒否する | 環境によりRDPにも影響して見えることがある（運用ポリシー次第） | 意図せず一般ユーザーが入っていないか確認 |
どこで確認するか（ローカル / ドメインGPO）
VMがドメイン参加しているかどうかで、確認場所が変わります。
| 状況 | 主な確認場所 | 補足 |
|---|---|---|
| ワークグループ（非ドメイン） | ローカル セキュリティ ポリシー（secpol.msc） | ローカルで完結。設定を変えたら反映は比較的早い |
| ドメイン参加 | ドメインGPO（Group Policy）＋ その結果としてVMに適用される設定 | ローカルで直してもGPOで上書きされることがある |
ローカル側で見る場合の手順は以下です。
- VMに管理者でログオン（コンソールでもRDPでも可）
- secpol.msc を起動
- 「ローカル ポリシー」→「ユーザー権利の割り当て」
- 次の項目を開いて、対象ユーザー/グループの有無を確認
- リモート デスクトップ サービスを通じてログオンを許可する
- リモート デスクトップ サービスを通じてログオンを拒否する
- ローカルでログオンを拒否する
ドメインGPOが絡む場合は、VM上で「何が最終的に適用されているか」を確認するのが近道です。GPOの設計意図と実際の適用結果がずれることは珍しくありません。
ドメインGPOが原因の典型パターン
「ドメイン管理者は入れるのに一般ユーザーは入れない」場合、GPOで次のような設定になっていることがあります。
- 「リモート デスクトップ サービスを通じてログオンを許可する」にAdministratorsのみが設定されている
- 「リモート デスクトップ サービスを通じてログオンを拒否する」にUsersやDomain Users等が入っている
この状態だと、Remote Desktop Usersに入れても効果が薄く、一般ユーザーが弾かれます。
対処の基本方針：許可に入れる、拒否から外す
運用上の要件（誰がRDPできるべきか）を満たしつつ、以下の形を目指すのが定石です。
- 許可：「リモート デスクトップ サービスを通じてログオンを許可する」にRDPを許可したいグループを入れる（例：Remote Desktop Users または専用のADグループ）
- 拒否：「リモート デスクトップ サービスを通じてログオンを拒否する」からRDPさせたいユーザー/グループを外す
- 拒否：「ローカルでログオンを拒否する」からも、意図せず対象が入っていないか確認する
設定変更後は反映のために、状況に応じて以下を実施します。
- gpupdate /force を実行
- それでも挙動が変わらない場合は再起動（特に権利系は再起動で安定することがある）
見落としがちな追加ポイント：RDPの許可設定とローカルグループの整合性
ユーザー権利（許可/拒否）が正しくても、VM側の基本設定が崩れていると別の形で詰まります。ここは“保険”として一度確認しておくと安心です。
「リモート デスクトップ」自体が許可されているか
- システムのプロパティ（または設定アプリ）で「リモート デスクトップを有効にする」がONになっているか
- 「このコンピューターへのリモート接続を許可する」相当の設定が有効か
Remote Desktop Users グループに正しく入っているか
既に追加済みとのことですが、念のため以下の観点で見直します。
- ローカルユーザーを追加したつもりが、別の同名アカウント（例：ドメイン側）を追加していないか
- グループに追加した直後、接続し直しているか（既存セッションの使い回しで見かけ上変わらないことがある）
アカウント制限がないか（パスワード、無効化、期限）
これはエラーメッセージが変わることも多いですが、運用現場では意外と混ざります。
- ローカルユーザーが無効化されていないか
- パスワード期限切れ、初回ログオンで変更が必要、などがないか
ログで確証を取る：どこで拒否されているかを特定する
同じ「ログオンできない」でも、RDPファイル（/admin）由来なのか、権利（許可/拒否）由来なのかで直し方が変わります。現場で迷いが出やすいときは、ログで“拒否理由の方向性”を掴むのが有効です。
見るべきログの例
- イベント ビューアー → Windowsログ → セキュリティ（ログオン失敗/失敗理由の手掛かり）
- アプリケーションとサービス ログ → Microsoft → Windows → TerminalServices-RemoteConnectionManager / TerminalServices-LocalSessionManager（RDP関連の動き）
ログの読み方は環境で差がありますが、確認したいのは次の方向性です。
- ユーザー権利（Allow/Deny）が原因なら、ログオン権限不足や拒否を示すヒントが出ることがある
- 管理用セッション要求が原因なら、接続要求の形が通常と異なるため、RDP関連ログに違いが出ることがある
ログは“決定打”というより、切り分けを後押しする材料として使うと効果的です。まずは(A)(B)の順で直しやすいところから当てに行き、ログで裏取りすると最短で収束します。
Azure VMで「Azure AD（オンラインID）」ログオンを絡めている場合の追加要件
質問文では「ローカルユーザー」とありますが、現場では次のような“混在”がよく起きます。
- ローカルユーザーで入ろうとしているが、途中からAzure ADのユーザーでのログオンも試している
- Azure VMの標準運用としてAzure ADログオンを前提にしている
この場合、(C)の要件不足が原因で、似たような拒否エラーに見えることがあります。Azure ADログオンを狙うなら、次を確認します。
Azure ADログオンの構成チェック
| チェック項目 | 確認の意図 | 不足時に起きやすいこと |
|---|---|---|
| AADLoginForWindows 拡張が導入されている | Azure AD資格情報でのWindowsログオンを成立させる土台 | Azure ADでのログオンが通らない/認証が進まない |
| VMへのログイン権限（ロール）が付与されている | Azure側で「このユーザーがVMにログインしてよい」ことを許可する | 認証できてもログオン権限で落ちる |
| PKU2U（オンラインID利用）関連のポリシーが無効化されていない | オンラインID/関連認証フローを許可する | 認証周りが想定通り動かず、結果的にログオンできない |
PKU2Uポリシーの位置（代表例）
ローカル セキュリティ ポリシーまたはGPOで、次の設定が無効化されていると、Azure ADログオンで詰まることがあります。
- ネットワーク セキュリティ: このコンピューターへの PKU2U 認証要求でオンライン ID を使用できるようにする
Azure ADログオンを使う運用をしているなら、ここが意図せず「無効」になっていないか確認し、必要に応じて有効化します（組織のセキュリティポリシーとの整合性は必ず取ってください）。
現場で刺さる「切り分け」：最短で原因に当てる順番
ここまでの内容を、運用担当がそのまま手順書として使える形に落とします。迷ったらこの順で進めると、最短で収束しやすいです。
| 手順 | やること | 狙い | 直ったら原因候補 |
|---|---|---|---|
| 1 | .rdpを開いて administrative session:i:1 を削除または0にする | 管理用セッション要求の排除 | (A) |
| 2 | mstscを完全に閉じて、新規起動して接続 | セッション/設定の使い回しによる誤判定を避ける | (A)の残存要因を潰す |
| 3 | VM側で「RDSでログオン許可/拒否」「ローカルでログオン拒否」を確認 | 拒否ポリシーの有無を確定させる | (B) |
| 4 | ドメイン参加なら、GPOの適用結果を前提に修正（ローカル修正だけで終わらせない） | 上書き問題の回避 | (B) |
| 5 | Azure ADログオン運用なら AADLoginForWindows / ロール / PKU2U を確認 | Azure ADログオンの前提不足を排除 | (C) |
よくある落とし穴集：対処しても戻る、直ったのにまた再発する
GPOで上書きされて「直したはずが戻る」
ローカルセキュリティポリシーで許可を追加して直ったように見えても、ドメインGPOが定期適用されると元に戻ることがあります。再発する場合は、“ローカルで直した”ではなく“GPOで直した”になっているかを確認してください。
誰かが作った.rdpファイルが原因で、端末や担当者によって再現する
同じVMでも「AさんのPCだと入れないが、BさんのPCだと入れる」という場合、VM側の設定だけでなく、クライアント側の.rdpファイル差分が原因のことがあります。配布している.rdpファイルがあるなら、administrative sessionの有無をテンプレートとして統一しておくと事故が減ります。
“Remote Desktop Usersに入れた”だけで安心してしまう
RDPログオンは、Remote Desktop Usersグループが起点になりやすい一方で、決定権はユーザー権利（許可/拒否）にあります。特にセキュリティ基準の高い環境では、GPOで「許可をAdministratorsだけに限定」していることもあります。運用の意図（誰がRDPすべきか）を確認したうえで、専用グループを作って許可に追加するのが安全です。
安全に運用するための推奨設計（再発防止）
場当たり的にユーザーを直接許可に入れていくと、台数が増えたときに破綻しやすくなります。再発防止の観点では、次のような設計が扱いやすいです。
| 設計の考え方 | 内容 | メリット |
|---|---|---|
| RDP専用グループを作る | 「VM-RDP-Users」などのADグループを作成し、許可にそのグループを入れる | 人の入れ替えがグループ管理で完結し、監査もしやすい |
| 拒否は最小限にする | 拒否ポリシーに大きなグループ（Users、Domain Users等）を入れない | 意図しない影響範囲を避けられる |
| .rdpテンプレートを統一する | administrative sessionを無効にしたテンプレートを配布する | 端末差・担当者差の事故が減る |
| Azure ADログオンは要件を明文化 | 拡張、ロール、ポリシー（PKU2U等）を運用標準として固定する | 「入れるはずの人が入れない」トラブルを減らせる |
まとめ：このエラーは「接続方式」か「権利（許可/拒否）」を疑うと最短で直る
「The requested session access is denied」で一般ローカルユーザーだけが弾かれる場合、原因は大きく3つに集約できます。
- 管理用セッション(/admin)扱いになっていないか（.rdpの administrative session が最有力）
- ユーザー権利の割り当て（許可/拒否）で弾かれていないか（拒否が入っていると必ず落ちる）
- Azure VM等でAzure ADログオンを絡めているなら、拡張・ロール・PKU2Uなどの前提を満たしているか
まずは.rdpの administrative session を外し、mstscを起動し直して再接続。それでもダメなら、VM側（またはGPO）の「RDSでログオン許可/拒否」を確認する。この順番で当てると、遠回りせずに解決へ辿り着きやすくなります。
コメント