Windows 10やWindows 11には、頻繁かつ微妙に名前が変化するサービスが複数存在することをご存じでしょうか。例えば、あるときは「Connected Devices Platform ユーザー サービス_57b90a」で、次に確認したときには「Connected Devices Platform ユーザー サービス_31da72」という具合です。その正体とは……。
この記事は会員限定です。会員登録(無料)すると全てご覧いただけます。
以下の画面1は、ある「Windows 10」のPCにサインインして、「サービス」スナップイン(Services.msc)を開いたところです。サービスの名前(表示名)が「_57b90a」で終わるサービスを複数確認できるでしょう。
画面2は、同じPCでいったんサインアウトして、同じユーザーで再びログオンしたときのものです。「_57b90a」で終わっていた全てのサービス名が、今度は「_31da72」で終わる名前に置き換わっています。
これはサービス名が変更されたわけではありません。正確には、ユーザーがログオンするたびに「サービスの作成、開始、停止、削除が繰り返されている」のです。
この挙動は、Windows 10 バージョン1703(Creators Update)から導入された「ユーザーごとのサービス(Per-user Service)」によるものです。ユーザーごとのサービスは、ユーザーがWindows(Windows 10 バージョン1703以降)またはWindows Server(「Windows Server 2019」以降のデスクトップエクスペリエンスのみ)にログオンしたときに作成され、必要に応じて開始され、そのユーザーがサインアウトしたときに停止および削除されます。
ユーザーごとのサービスは、「サービス」スナップインではローカルシステムアカウント(Local System)で動作するように見えますが、実際にはログオン中のユーザーのセキュリティコンテキスト(トークン)に関連付けられます。
従来のサービスは、ローカルシステムアカウントやローカルサービスアカウント(Local Service)、ネットワークサービスアカウント(Network Service)、サービス専用に作成されたユーザーアカウント、仮想サービスアカウント(NT SERVCE\<サービス名>)のいずれかで実行されてきました。しかし、これらのアカウントは、悪意のあるユーザーがサービスプロセスに侵入し、そのセキュリティトークンを使用して本来アクセスできないリソースにアクセスする可能性があり、ユーザーが危険にさらされるリスクがあります。ログオンユーザーのセキュリティトークンで動作するユーザーごとのサービスは、たとえ侵入されたとしても、そのユーザーが持つ権限を越えたセキュリティアクセスが不可能という制限がかかります。
以下の画面3は、Windows Sysinternalsの「Process Monitor」でブートログを取得し(「Options」メニューの「Enable Boot Logging」を選択して再起動して取得)、プロセスツリー(「Tools」メニューの「Process Tree」)を開いたものです。緑色のバーは、各プロセスのライフタイム(開始から終了または現在実行中)を示しています。ログオンセッションを開始した「Windowsセッションマネージャー」(プロセスID 5444のsmss.exe)の作成したプロセスより後に、ログオンユーザーのセキュリティトークンで幾つかのサービスが開始されていることが分かります(選択中のものは「クリップ モード ユーザー サービス_XXXXXX」に対応)。
では、ユーザーごとのサービス名の最後に付加される「_XXXXXX」はどこからくるのでしょうか。同じユーザーでもログオンするたびに変換するため、ユーザー固有のものではないようです。
「Windows Server 2022」の「リモートデスクトップサービス」環境で見てみましょう。ローカル管理者である「Administrator」のみがログオンしている状態で、アクティブなセッション(query session)、実行中のユーザーごとサービス(net start |findstr _)、および「HKEY_LOCAL_MACHINE\SYSEM\CurrentControlSet\Services」の下にあるユーザーごとのサービスのレジストリを確認すると、現在、Administratorには「_709bd」が関連付けられており、5つのユーザーごとのサービスが存在することが分かります(画面4)。
リモートデスクトップ接続経由で2ユーザー(user01とuser02)がさらにログオンすると、ユーザーごとのサービスが幾つか増えました。一方のユーザーには「_192ef8」、もう一方のユーザーには「_249ef9」が関連付けられており、サービスのレジストリもユーザーごとのサービスごとに増加しているのが分かります(画面5)。
では、「_XXXXXX」の部分はどこから来ているのでしょうか。その答えは、「HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\VolatileUserMgrKey」レジストリキーに格納されています。
このレジストリキーには、揮発性のレジストリであり(再起動すると消える)、ログオンセッションが作成されると「User Manager」サービスによって「\<セッションID>\<ユーザーのSID>」サブキーが作成され、「contextLuid」値に現在のブートで一意のローカルユーザー識別子(LUID)が割り当てられます(画面6)。
ユーザーのSID(セキュリティ識別子)は、管理者として開いたコマンドプロンプトで「WMIC USERACCOUNT GET NAME, SID」コマンドを実行するか、Windows Sysinternalsの「PsGetSid」で確認できます。
もう一度、画面4や画面5を見てください。サービスのレジストリとして「_XXXXXX」を含まないキーが存在することに気が付いたでしょうか。これはユーザーごとのサービスのテンプレート(「サービス」スナップインには表示されません)であり、「テンプレートのサービス名_XXXXXX」が作成されて、テンプレートのレジストリ設定がコピーされるようになっています。
ユーザーごとのサービスの知識がないと、ランダムな16進数が付き、しかも名前が変化するサービスは、正規のサービスをかたった悪意のある何かのように見えるかもしれません。しかし、これはWindowsの正規のサービスであり、正常な動作であることを知っておきましょう。
岩手県花巻市在住。Microsoft MVP 2008 to 2023(Cloud and Datacenter Management)。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker&Windowsコンテナーテクノロジ入門』(日経BP社)、『ITプロフェッショナル向けWindowsトラブル解決 コマンド&テクニック集』(日経BP社)。
Copyright © ITmedia, Inc. All Rights Reserved.