Windows:リモートデスクトップのアクセス制限の仕方|特定のユーザーのみ許可する

RDPを特定ユーザーだけに許可するには、対象サーバーごとのADセキュリティグループを作り、そのグループをローカルのRemote Desktop Usersへ追加し、GPOの「Allow log on through Remote Desktop Services」に必要グループだけを指定します。Administratorsも既定で権利を持つことがあるため、管理者範囲を別途監査します。明示的なDenyはAllowより優先するため、広い拒否グループを安易に入れず、コンソール/帯域外復旧経路を確保してください。

Remote Desktop Usersへの所属、Allowユーザー権利、Denyユーザー権利、RDP有効化、ファイアウォール、NLAのすべてが整って初めて接続できます。グループ所属だけで完了ではありません。

目次

対象をグループで管理する

ユーザー個人を各サーバーへ直接追加するのではなく、`GG-RDP-SRV01-Users`のように用途と対象が分かるドメイングループを使います。所有者、申請理由、承認者、期限、メンバー更新を管理し、退職・異動・保守終了で自動または定期的に削除します。

管理者用RDPと業務用RD Session Hostを分けます。管理目的のサーバーへ一般利用者を許可せず、RD Session Hostはコレクション、ライセンス、プロファイル、セッション制限も設計します。この記事のユーザー権利だけでRDSファーム全体の認可を代替しません。

ローカルRemote Desktop Usersを設定する

単体PCならSystem PropertiesのRemote DesktopでSelect users that can remotely access this PCから追加できます。ドメイン環境ではGPP Local Users and Groupsまたは管理製品で、対象ADグループをローカルRemote Desktop Usersへ追加します。既存メンバーを全削除するReplace操作を不用意に使いません。

Add-LocalGroupMember -Group 'Remote Desktop Users' -Member 'CONTOSO\GG-RDP-SRV01-Users'
Get-LocalGroupMember -Group 'Remote Desktop Users'

PowerShell例はローカルの検証端末で対象を確認してから実行します。ローカライズされたOSでグループ表示名が異なる場合や、ドメインコントローラーにはローカルグループがない点を考慮します。対象を取り違えないようホスト名とドメインを同時に表示します。

Allow log on through Remote Desktop Services

GPOのComputer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights AssignmentでAllow log on through Remote Desktop Servicesを設定します。Remote Desktop Usersと必要な管理グループを含め、GPOを対象サーバーOUへだけリンクします。

ユーザー権利の一覧は「追加」ではなくGPOで定義した集合に置き換わるため、既存管理グループを落とすと遠隔管理不能になります。現在値、適用GPO、非常用管理者を確認し、検証サーバーで適用してから広げます。

Deny log on through Remote Desktop Services

確実に拒否したいアカウントやローカルアカウントにはDenyを使えますが、DenyはAllowより優先します。Domain UsersやAdministratorsのような広いグループを入れると、許可対象もそのメンバーなら全員拒否されます。グループのネストを展開して影響を確認します。

Microsoftの現行資料では、旧ADユーザープロパティの「RDSログオン拒否」だけに頼らず、GPOのDeny log on through Remote Desktop Servicesを使うよう案内しています。対象サーバーとユーザーをセキュリティフィルターで限定し、別OUへの誤適用を監視します。

RDP自体とネットワークを限定する

Settings/System/Remote Desktopまたはサーバー管理でRDPを有効化し、Windows FirewallのRemote Desktopルールを必要な管理ネットワーク、RD Gateway、VPNからだけ許可します。3389をインターネットへ直接公開しません。NLAを有効にし、MFAを提供するGateway/ZTNAを検討します。

クリップボード、ドライブ、プリンター、COM、USB、オーディオ等のリダイレクトは情報持ち出し経路になります。業務要件ごとにGPOで制限し、全部有効を既定にしません。セッションのアイドル、切断、終了時間も未保存作業への影響を検証します。

パイロットテスト

  • 許可グループの標準ユーザーがNLA経由で接続できる
  • 許可されていない同部署ユーザーが拒否される
  • Deny対象は別のAllow所属でも拒否される
  • 承認済み管理者が非常時に接続できる
  • RDP以外の対話/ネットワークログオン権利を誤変更していない
  • ログオフ、切断、再接続、同時セッションが設計どおり

テストではログオン監査の成功/失敗、TerminalServices関連ログ、Securityログ、NPS/Gateway/Entra等の認証ログを時刻で照合します。エラー文だけでパスワード問題と断定せず、Allow/Deny、グループトークン、NLA、ライセンス、接続上限を切り分けます。

「管理者なのに入れない」とき

管理者がDenyグループにも所属していないか、Allow一覧からAdministratorsを外していないか、GPOがどのOUから適用されたかを`gpresult`で確認します。ローカルポリシーを直してもドメインGPOで上書きされるため、最終設定元を修正します。

遠隔から唯一の管理経路を失った場合に備え、ハイパーバイザーコンソール、iDRAC/iLO、クラウドシリアルコンソール、現地担当など承認済み帯域外アクセスを準備します。緊急解除アカウントを日常利用せず、使用をアラートします。

変更の戻し方

誤設定時は対象GPOのリンクまたはセキュリティフィルターを検証前へ戻し、Remote Desktop Usersの旧メンバーとユーザー権利を復元します。Denyを消しただけでAllowが戻るとは限りません。コンソールから`gpupdate`とRSoPを確認し、許可/拒否テストを再実行します。

継続運用

四半期ごとに許可グループ、最終利用、管理者、ローカルアカウント、例外期限をレビューします。長期未使用者を削除し、共有アカウントを個人識別可能なアカウントへ置き換えます。RDPログオンを許可しても、サーバー内ファイルやアプリ権限は別途最小化します。

ロックアウトと緊急アクセス

パスワードスプレーや誤設定で許可ユーザーがロックアウトする場合に備え、Account Lockout、NLA、RD Gateway、MFAのログを統合します。ロックアウト解除のためにポリシー閾値を緩めるのではなく、送信元遮断、資格情報ローテーション、端末調査を行います。

緊急用アカウントは通常の許可グループから分離し、長いランダム秘密、保管庫、使用時承認、アラート、利用後ローテーションを設定します。ローカルAdministratorを全サーバーで同じパスワードにせず、Windows LAPS等で端末ごとに管理します。

接続元端末の条件

ユーザーが許可されていても、管理対象外端末や危険な場所からの接続を許さないよう、VPN/ZTNA、Gateway、端末証明書、準拠状態、MFAで接続元を制限します。サーバー側のユーザー権利はIDの一条件であり、ネットワークと端末信頼を置き換えません。

公式情報・参考資料

この記事を書いた人

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows/Office(Teams・Excel)からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

コメント

コメントする

目次