リモートデスクトップで接続時にパスワードを要求するGPO設定と確認方法

リモートデスクトップの接続先で、保存済みのパスワードによる自動ログオンを制限したい場合は、ホスト側のグループポリシー「接続するたびにパスワードを要求する」を検討します。本記事では設定場所と適用結果の確認方法を説明します。

この設定は、接続元PCでのパスワード保存そのものを禁止する設定とは別です。また、多要素認証を追加する機能ではありません。SSOやパスワードレス認証を含むすべての接続で、必ず同じ入力画面になるという意味でもありません。

以下の画像は2019年の操作例です。現在のOS、クライアント、認証方式では画面が異なります。設定前に管理者が対象環境の仕様と現在のポリシーを確認してください。

目次

ローカルグループポリシーエディタを開く

操作対象はリモートデスクトップで接続される側のPC/サーバーです。ローカルポリシーを管理できる環境では、その端末で管理者としてローカルグループポリシーエディタを開きます。

「Winキー」 + 「Rキー」 を同時タイプ

「gpedit.msc」と入力してOK

ローカル グループポリシーエディターが立ち上がる

ドメインやMDMで管理されている端末では、ローカル設定を変えても組織の設定が優先される場合があります。管理担当者に適用元を確認し、まず少数の検証対象で試してください。変更前の値と適用元を記録し、リモート接続ができなくなった場合のコンソールなどの復旧経路を確保します。

「接続するたびにパスワードを要求する」を有効にする

接続先の次の場所を開きます。

コンピューターの構成 → 管理用テンプレート → Windowsコンポーネント → リモートデスクトップサービス → リモートデスクトップセッションホスト → セキュリティ

「接続するたびにパスワードを要求する」を開き、検証対象で「有効」を選んで適用します。英語名は Always prompt for password upon connection です。

有効にすると、Remote Desktop Connectionクライアントに渡したパスワードによる自動ログオンを許可せず、接続時に入力を求める設定になります。「未構成」は、このポリシーで自動ログオンを決めない状態であり、「無効」と同じ指定ではありません。詳しい対応範囲とADMXの対応関係はMicrosoftの公式ポリシー説明を確認してください。

一律にPCの再起動を必須とするのではなく、組織で定めたポリシー反映手順に従い、適用結果を確認してから新しい接続で試します。業務中の端末や共有サーバーを確認なしに再起動しないでください。

さあ、試してみましょう。

  1. 接続先で、意図した設定が適用されたことを確認します。グループポリシーの場合は管理者のコマンドプロンプトで次の読み取り用コマンドを使い、コンピューター側の結果を確認できます。
gpresult /scope computer /z

結果には端末名や組織の構成などが含まれるため、そのまま外部へ貼り付けないでください。MDM由来の設定はこのコマンドだけで判断せず、管理側の適用状況も確認します。

  1. 作業を保存したテストアカウントで新たにRDP接続し、資格情報の入力が必要になるか、入力後に正常に接続できるかを確認します。
  2. 通常使用するクライアントと認証方式でも確認します。接続中のセッション、ロック解除、通信断からの自動再接続まで一度の確認で保証しないでください。

次は元記事の環境で表示された、保存済みの資格情報を使用できない旨の画面例です。同じメッセージが出ること自体を成功条件にせず、適用結果と新規接続時の動作を確認してください。

パスワード保存の禁止やSSOとの違い

接続元で保存を禁止したい場合は、Remote Desktop Connection Client配下の別のポリシー「パスワードを保存できないようにする」が対象です。本記事のホスト側設定だけで、各クライアントに保存済みの資格情報を一括削除することはできません。

Remote Credential Guardなどは、資格情報を接続先に渡さずに認証する仕組みやSSOを利用します。入力画面を出すためだけに、NLA、Credential Guard、Remote Credential Guardなどの保護機能を無効にしないでください。組織が求めるのが「毎回の本人確認」なのか「端末へのパスワード保存の禁止」なのかを分け、認証設計を管理者と確認します。

戻す場合と確認資料

問題が出た場合は、この設定を記録しておいた変更前の値へ戻し、適用結果と接続を再確認します。元が「未構成」なら「未構成」へ戻します。ドメインGPOやMDMで配布している場合は、その管理元の担当者が変更してください。復旧のために無関係なポリシーを一括リセットする必要はありません。

この記事を書いた人

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

コメント

コメントする

目次