アイドル状態のリモートデスクトップ（RDP）セッションを指定時間後に自動ログオフさせるには、二つのポリシーを組み合わせます。「アクティブでアイドル状態のリモート デスクトップ サービス セッションの制限時間を設定する」で時間を決めるだけでは、通常はセッションが切断され、利用者のプログラムと未保存データはサーバー側に残ります。ログオフまで行うには「制限時間に達したらセッションを終了する」も有効にする必要があります。
ログオフは切断と違い、実行中アプリを終了し、未保存の作業を失わせる可能性がある操作です。いきなり本番全体へ適用せず、対象ユーザー、除外が必要な管理用アカウント、テスト端末、通知、復旧方法を決めてから段階的に導入してください。本記事ではローカルまたはドメインのグループポリシーを使い、レジストリを直接編集しません。
切断・ログオフ・ロックの違い
| 状態 | アプリとセッション | 再接続時 |
|---|---|---|
| 画面ロック | セッションは接続中でアプリも継続 | 認証後に同じ画面へ戻る |
| RDP切断 | 通信は切れるがセッションとアプリはサーバー側に残る | 通常は同じセッションへ再接続できる |
| ログオフ | セッションとユーザープロセスを終了 | 新しいサインインになる |
「アイドル制限を設定したのにログオフされない」という事例の多くは、制限時間だけを有効にして終了ポリシーを有効にしていない状態です。逆に、終了ポリシーまで有効にすれば、未保存の文書や管理コンソールの途中作業も閉じられます。セキュリティ上の目的だけでなく、業務上許容できるアイドル時間を利用部門と合意する必要があります。
適用前に現在のセッションを確認する
Windows Serverまたは対象のRDPホストで、現在のセッション状態を読み取ります。Microsoftのquserコマンドは、ユーザー名、セッション名、ID、状態、アイドル時間、ログオン時刻を表示します。
quserIDLE TIMEは判断材料ですが、表示単位や状態を誤読しないよう、テストアカウントで実際の経過時間と照合してください。アプリ内で動画再生や自動処理が動いていても、RDPの入力がないためアイドルと判定される場合があります。「処理が動いているからアイドルではない」とは限りません。長時間ジョブを対話セッションで動かしている環境では、自動ログオフ前にサービスやスケジュールタスクへ移す検討が必要です。
同時に、既存のグループポリシー結果を確認します。管理者として開いたコマンドプロンプトまたはPowerShellで、コンピューター側の要約を読み取ります。
gpresult /scope computer /rドメイン参加端末ではローカル設定だけでなく、サイト、ドメイン、OUにリンクされたGPOが適用されます。gpresultは実際の結果セットを確認する入口です。大規模変更の前にはGroup Policy ResultsまたはGroup Policy Modelingも使い、対象ユーザーとコンピューターの組み合わせ、セキュリティフィルター、WMIフィルター、継承を確認します。
設定場所と必要な二つのポリシー
単体PCで検証する場合はローカルグループポリシーエディター、Active Directory環境ではグループポリシー管理を使います。ポリシーの場所は次のとおりです。
コンピューターの構成
管理用テンプレート
Windows コンポーネント
リモート デスクトップ サービス
リモート デスクトップ セッション ホスト
セッションの時間制限利用するポリシーは、次の二つです。
- 「アクティブでアイドル状態のリモート デスクトップ サービス セッションの制限時間を設定する」を有効にし、業務要件で合意したアイドル時間を選びます。
- 「制限時間に達したらセッションを終了する」を有効にし、制限到達時の動作を切断ではなくログオフへ変えます。
Microsoftのポリシー説明では、制限時間に達する約2分前に警告が表示されます。ただし、利用者がその瞬間に画面を見ているとは限らず、警告だけをデータ保護策にしてはいけません。自動保存、業務アプリの終了方法、利用者への事前周知、例外申請を合わせて設計します。
ローカルGPOで小さく検証する手順
- 本番と同じOS・役割の検証用RDPホストを用意します。
- テストアカウントに保存不要なアプリだけを開かせ、現在のquser結果を記録します。
- 上記二つのポリシーを有効にし、最初は短い検証用時間を選びます。
- ポリシー更新後にサインインし直し、gpresultで適用を確認します。
- キーボードやマウスを操作せず待ち、警告、切断、ログオフの順序を観察します。
- 再接続して新規セッションになること、前のテストアプリが残っていないことを確認します。
検証中は重要なファイルを開かず、管理者がコンソールまたは別経路から復旧できる状態を保ちます。設定変更を行った管理セッション自身がログオフ対象になることもあります。グループポリシー更新を強制するか、次回の通常更新を待つかは、組織の変更手順に従ってください。実行中ユーザーへ無断で強制更新しないことが重要です。
ドメインGPOで展開する場合
Active Directory環境では、最初に検証用OUへGPOをリンクし、少数のホストとテストユーザーで結果を確認します。RDPセッションホストの設定としてコンピューター側へ適用すると、対象ホスト上のセッションへ一貫して効かせやすくなります。ユーザー側にも同種の設定がある構成では、Microsoftの説明上、コンピューター側の設定が優先されるため、両方へ矛盾する値を配らないようにします。
本番展開前に、管理者、ヘルプデスク、夜間バッチ担当、長時間処理を行う利用者、共有端末の運用者へ影響を確認します。OUを広げる際は、適用対象、除外グループ、変更日時、期待する制限値、元に戻す条件を変更記録へ残します。グループポリシーのモデリングは「もしGPOをこのOUへリンクしたら」という予測に役立ち、Resultsは実際の適用結果確認に役立ちます。
設定が効かないときの確認順
ログオフではなく切断される
「制限時間に達したらセッションを終了する」が有効かを確認します。アイドル制限だけなら切断が既定動作です。gpresultで対象コンピューターに適用されたGPOを確認し、別GPOの値で上書きされていないかを調べます。設定名が似た「切断されたセッションの制限時間」や「アクティブなセッションの制限時間」と取り違えないでください。
想定時間になっても状態が変わらない
対象がRDPセッションであるか、ポリシー更新後に作成されたセッションか、適用先コンピューターが正しいOUにあるかを確認します。quserのSESSIONNAMEとSTATE、IDLE TIMEをテスト記録と比較します。RemoteApp、VDI、Azure Virtual Desktop、第三者製品などでは管理レイヤーが別にあるため、一般的なRDPセッションホストのGPOだけで判断しないでください。
一部ユーザーだけ結果が違う
セキュリティフィルター、GPO継承、ループバック処理、ユーザー側ポリシー、RDSコレクションや製品固有設定を確認します。利用者の申告だけで推測せず、そのユーザーと対象ホストのgpresultまたはGroup Policy Resultsを採取します。レポートには組織名、ユーザー名、端末名が含まれるため、共有範囲を限定してください。
本番値を決めるときの考え方
短すぎるアイドル時間は、会議中、資料閲覧中、長時間計算中の利用者を意図せずログオフさせます。長すぎる値は、放置セッションによるリソース消費やアクセス継続の時間を増やします。業務の最長無操作時間、アプリの自動保存、再ログイン所要時間、セキュリティ基準、同時セッション数を基に決めます。画面ロックの時間と同じ値にする必要はありません。
「全ユーザー一律」が適切でない環境では、対話利用ホストとバッチ用ホストを分ける、長時間処理を非対話サービスへ移す、承認済み例外OUを設けるといった構成を検討します。ただし、例外アカウントを広く増やすと統制が崩れるため、所有者、期限、レビュー日を決めます。
元に戻す方法
問題が起きた場合は、変更した二つのポリシーを「未構成」へ戻し、組織の通常手順でポリシーを反映します。ドメインGPOなら、リンク範囲を検証OUへ戻す、GPOの変更を復元するなど、変更記録に定めたロールバックを使います。「無効」は明示的な別設定として残ることがあるため、変更前が未構成だったなら未構成へ戻します。
すでにログオフされたセッションの未保存データは、ポリシーを戻しても復元できません。ロールバックは今後のセッション動作を戻すものです。だからこそ、本番展開前のテスト、利用者通知、自動保存、バックアップ、例外設計が必要です。設定後はquserとgpresultで事実を確認し、想定どおりでなければ対象範囲を広げないでください。
コメント