セイテクエンジニアのブログかつて山市良と呼ばれたおじさんのブログ vol.194　セッションとデスクトップと私｜セイテク・シス管道場（Web）

vol.194　セッションとデスクトップと私｜セイテク・シス管道場（Web）

2026年04月13日配信
執筆者：山内和朗

　「セイテク・シス管道場（Web）」では、Windows Serverの要素技術やシステム管理の基本的な部分に焦点を当てたいと思います。前回、ローカルセキュリティ機関（LSA）のログオンセッションと、デスクトップを持つセッションを一緒くたに語ってしまいましたが、実は全く別のものです。また前回は「ログオン/ログオフ」なのか「サインイン/サインアウト」なのかという話題でしたが、今回は明確に「ログオン/ログオフ（または切断）」で語ることができる話題です。

LSAログオンセッションはアクティブなセキュリティトークン群

　
　ログオンセッションは、ユーザーアカウントやサービスアカウントがWindowsに認証されるときに作成されるものです。それは、ローカルコンソールへのログインやリモートデスクトップ（RDP）接続、SSH接続（最近のWindowsに標準搭載）に限定されません。ファイル共有やWebアプリケーションのネットワーク認証、保存された資格情報によるサービス開始、Runasコマンドを使用した別の資格情報を使用したプログラム実行、認証されていないユーザーの代理や偽装などによって、アクセストークンとともに作成、管理されます。各セッションは、64ビットのローカルで一意な識別子（LUID）で識別され、今回説明するもう1つのセッション（RDSセッション）の情報も含んでいます。

　Windows SysinternalsのLogonSessionsを使用すると、LSAによって作成されたアクティブなログオンセッションを列挙でき、LUIDや使用された認証パッケージを確認できます（画面1）。認証パッケージとして、ローカルアカウントによるログインには「NTLM」、ドメインアカウントによるログインには「Kerberos」、オンラインアカウント（MicrosoftアカウントおよびMicrosoft Entra IDアカウント）には「CloudAP（Cloud Authentication Provider）」が使用されます。ただし、オンラインアカウントのユーザー名ではなく、それに紐づいたローカルアカウントやドメインアカウント（Microsoft Entra IDのハイブリッド環境）のログオンセッションとして存在します。

LogonSessions｜Sysinternals（Microsoft Learn）

vol194_scr01
画面1　Windows SysinternalsのLogonSessionsツールの実行結果の一部

　Windows Sysinternalsといった外部のツールを使いたくないという場合は、次のPowerShellコードを実行することで、logonsessionsライクな結果を取得することができます（画面2）。logonsessionsにある認証パッケージの情報や、RDSセッション番号は取得できません。また、実在するユーザーアカウントのログオンセッションのみに限定され、内部コンポーネント用（Window ManagerやFont Driver Host）の仮想ログオンセッションは結果に含まれません。

Get-CimInstance Win32_LogonSession | ForEach-Object {

    $luid = [uint64]$_.LogonId
    $high = $luid -shr 32
    $low  = $luid -band 0xFFFFFFFF
    $luidHex = ('{0:X8}.{1:X8}' -f $high, $low)

    $type = switch ([int]$_.LogonType) {
        0  {"System"}
        2  {"Interactive"}
        3  {"Network"}
        4  {"Batch"}
        5  {"Service"}
        7  {"Unlock"}
        8  {"NetworkCleartext"}
        9  {"NewCredentials"}
        10 {"RemoteInteractive"}
        11 {"CachedInteractive"}
        12 {"CachedRemoteInteractive"}
        13 {"CachedUnlock"}
        default {"Unknown"}
    }

    $users = Get-CimAssociatedInstance -InputObject $_ -Association Win32_LoggedOnUser

    foreach ($user in $users) {
        [PSCustomObject]@{
            LogonId   = $luidHex
            LogonType = $type
            User      = "$($user.Domain)\$($user.Name)"
            StartTime = $_.StartTime
        }
    }
} | Sort-Object LogonId

（プレーンテキストで表示、ダウンロード）

vol194_scr02

画面2　PowerShellのスクリプトでLSAログオンセッションを列挙したところ

ローカルコンソールからのログオンでも、それはRDSセッション

　リモートデスクトップサービス（RDS）は、Windows Serverの役割の1つですが、RDSの有効化状態に関係なく、その技術はWindows ServerおよびWindowsのログオンに深く関わっています。RDSは、Windows NT Server 4.0, Terminal Server Editionとして登場し、Windows 2000 Server以降のWindows ServerにRDS（旧称、Terminal Services）として組み込まれました。Windows XP以降はWindowsクライアントにも組み込まれ、ユーザーの切り替えやリモートデスクトップ（RDP）接続などに使用されています。

　実は、ローカルコンソールからのログオンと、ネットワーク経由のRDP接続のログオンは、どちらもLSAセッションに紐づくRDSセッションを作成します。現在アクティブなすべてのRDSセッションと自分のセッションを確認するには、「query session」コマンドまたは「quser」コマンドを実行します（画面3）。タスクマネージャー（Taskmgr.exe）の「ユーザー」タブで「ID」と「セッション」列を有効化することでも確認できます。

画面3　Administratorがコンソール（console）のセッション1に、localadminがリモートデスクトップ（RDP）接続でセッション2にログオン中。自分（私）のセッションはquery session/quserの行頭の>で判断できる

　システムサービスとWindowsサービス（Windows 10以降に導入されたユーザーサービスを除きます）は、常にRDSのセッション0を使用します。Windows XPやWindows Server 2003 R2までは、最初に対話ログオンしたユーザーもセッション0を使用していました。しかし、システムやサービスとユーザーが同じセッションを使用することはセキュリティ上の問題がありました。Windows VistaおよびWindows Server 2008以降では、セッション0はシステムとサービス専用となり、ユーザーはセッション1以降を使用するようになりました。これは「セッション0の分離（Session 0 Isolation）」と呼ばれ、後で説明する「ユーザーアカウント制御（UAC）」とともに、Windowsの歴史の中で重要なエポックとなりました。

　1つのRDSセッション（Session）は、1つ以上の名前付きウィンドウステーション（Window Station）を持ち、その中に1つ以上のデスクトップ（Desktop）オブジェクトを持ちます（図1）。これらのオブジェクトの存在は、Windows SysinternalsのProcess Explorer（Procexp）やWinObjツールを使用して確認することが可能です（画面4）。これらのツールを使わないでオブジェクトを確認する方法としては、デバッガー（WinDbg）でデバッグ（!object \Sessionsなど）するしかないでしょう。

Process Explorer｜Sysinternals（Microsoft Learn）
WinObj｜Sysinternals（Microsoft Learn）

図1　セッション、ウィンドウステーション、デスクトップの関係。コンソール（console）セッションが常に1とは限らないことに注意。起動直後はコンソールセッションは1になるが、その後、ログオフ/ログオンすると2以降になる

画面4　Windows SysinternalsのProcexpとWinObjを使用すると、アクティブなセッション、ウィンドウステーション、デスクトップオブジェクトを確認できる

　対話的なウィンドウステーション（つまり、セッション1以降）は、複数のデスクトップを持ちます。それらは「Default」「Winlogon」「Screen-saver」「DisConnect」で、ユーザーがエクスプローラー（Explorer.exe）シェル上でアプリケーションを実行するのは「Default」デスクトップです。「Screen-saver」デスクトップは、スクリーンセーバーが有効になっており、スクリーンセーバー実行中にのみ作成されるオブジェクトで、その中でスクリーンセーバー（*.scr）が実行されます。「Disconnect」デスクトップはユーザーがセッションから切断されたときのために使用されます。

　残るWinlogonデスクトップは、「セキュリティで保護されたデスクトップ（Secure Desktop）」とも呼ばれ、Ctrl＋Alt＋Delキーが押された時に制御が転送される場所であり、Windowsのログオン（サインイン）画面やWindowsセキュリティ（ロック/ユーザーの切り替え/サインアウト/パスワードの変更/タスクマネージャー）の画面（どちらもLogonUI.exe）、UAC昇格ダイアログボックス（Consent.exe）の表示に使用されます。Winlogonデスクトップでは、システムアカウント（NT AUTHORITY￥SYSTEM）として実行されるプログラム（LogonUI.exe、Consent.exe）だけに制限され、パスワード入力や昇格同意のセキュリティ操作が保護されます。

　WindowsにおけるCtrl＋Alt＋Delキーの操作は「Secure Attestation Sequence（SAS）」とも呼ばれます。SASの送信は常にWinlogonデスクトップに転送され、Winlogonデスクトップではユーザーモードアプリケーションは介入できないため、悪意のあるユーザープロセスからセキュリティ操作が保護されるという仕組みになっています（画面5）。

画面5　UAC昇格ダイアログボックス（が2つ目のWinlogonデスクトップでシステム権限で実行されている様子。この動作を参照するには、Procexpをシステム権限で実行する必要がある（psexec -i -s procexp.exeを利用）
画面5　UAC昇格ダイアログボックスが2つ目のWinlogonデスクトップでシステム権限で実行されている様子。Consent.exeの情報を参照するには、Procexpをシステム権限で実行する必要がある（psexec -i -s procexp.exeを利用）

　Windowsには、セッション0の分離と同時期にUACが導入されました。UACは、管理者としてログオンしている場合でも通常時は標準ユーザーの権限に制限され、特権操作が必要なときだけUAC昇格ダイアログボックスを表示して同意を求めます。UAC昇格ダイアログボックス（Consent.exe）はWinlogonデスクトップで動作するため、悪意のあるユーザープロセスはこれに介入することができません。

RDSセッションだからできる、コンソールへのシャドウ接続

　コンソールへのローカルログオンとネットワーク経由のリモートデスクトップ（RDP）接続がどちらも同じRDSセッションであるという事実は受け入れられないという人もいるでしょう。

　Windows Serverに対するリモートデスクトップ接続では、RDSの役割を有効化していなくても、ユーザーセッションへのシャドウ接続がサポートされます。シャドウ接続とは、これはアクティブなRDSセッションと同じセッションに、リモートから同時に接続して制御または参照する機能です。次の画面6は、Hyper-V VMの「仮想マシン接続」（基本セッションモード）でWindows Serverのコンソールにローカルログオンしているセッション1に、リモート（Hyper-Vホスト側）からネットワーク経由でシャドウ接続しているところです。このことから、コンソールへのローカルログオンもRDSセッションであることが分かるでしょう。

vol194_scr06
画面6　コンソールにローカルログオンしているセッション1に、リモートからシャドウ接続しているところ

　なお、シャドウ接続を許可するには、シャドウ接続を受け付けるWindows Server側で「コンピューターの構成￥管理テンプレート￥Windows コンポーネント￥リモートデスクトップサービス￥リモートデスクトップセッションホスト￥接続￥リモートデスクトップサービスのユーザーセッションのリモート制御のルールを設定する」ポリシーを構成し、Windowsファイアウォールで「リモートデスクトップ - シャドウ（TCP受信）を含む「リモートデスクトップ」ルールグループおよび「ファイルとプリンターの共有」ルールグループを許可」を有効にする必要があります。