とりあえずLocalSystemで動かしているサービスは、今すぐ変えるべきですか？

一律に即時変更が正解とは限りません。まず、そのサービスが本当にLocalSystem相当のローカル権限(管理者を超える強い特権)を必要としているかを確認してください。ファイルの読み書きとネットワーク通信程度なら、仮想アカウント(NT SERVICE\サービス名)へ移すのが第一候補です。移行時には、必要なフォルダーやレジストリへのアクセス許可の付与、プロファイルやDPAPIに依存したデータの扱い、「サービスとしてログオン」権限の有無を確認します。検証環境で起動と主要機能を確かめてから、本番を切り替えてください。

仮想アカウントとNetworkServiceはどちらを選ぶべきですか？

新規に選ぶなら仮想アカウントをおすすめします。両者はネットワーク上ではどちらもコンピューターアカウント(DOMAIN\コンピューター名$)として見え、ローカル権限が小さい点も似ています。しかしNetworkServiceは複数のサービスが同じアカウントを共有するため、ACLで「このサービスだけに許可する」という分離ができません。仮想アカウントはサービスごとに固有の身元を持ち、ACLにNT SERVICE\サービス名を直接指定できます。SQL Serverなど近年のMicrosoft製品の既定も仮想アカウントです。

gMSAはワークグループ環境(ドメインなし)でも使えますか？

使えません。gMSAはActive Directoryのドメインコントローラーがパスワードを生成・管理する仕組みで、ドメインとKDSルートキーの作成が前提です。ワークグループ環境では、仮想アカウントかLocalService/NetworkServiceでローカル処理を完結させるのが基本です。他のマシンへのアクセスが必要な場合は、接続先に用意したアカウントの資格情報を明示的に使うなどの別設計になります。コンピューターアカウント(PC$)としてのネットワークアクセスも、ドメイン環境でだけ成り立つ話です。

サービスの実行アカウントを変えたら、保存していた設定や資格情報が読めなくなりました。なぜですか？

実行アカウントには、それぞれ固有のユーザープロファイル・%TEMP%・HKEY_CURRENT_USER・DPAPIキーが紐づいているためです。特にDPAPI(CryptProtectData等)でユーザースコープの保護をかけたデータは、原則として保護したときと同じアカウントでしか復号できません。また、プロファイル配下(AppData等)に保存したファイルは、新アカウントからは別のパスになります。アカウント切替の前に、DPAPI保護済みデータの再作成手順(APIキーの再入力等)と、プロファイル配下のファイルの移行を計画してください。

サービスから共有フォルダにアクセスしたいだけなら、ドメインユーザーは必要ですか？

多くの場合は不要です。ドメイン環境なら、LocalSystem・NetworkService・仮想アカウントで動くサービスは、リモートに対してコンピューターアカウント(DOMAIN\コンピューター名$)として認証されます。共有フォルダの共有アクセス許可とNTFSアクセス許可にそのPC$を追加すれば読み書きできます。サービス固有の身元でアクセス制御したい場合や、複数サーバーで同じ身元が必要な場合は、ドメインユーザーではなくgMSAを検討してください。

Windowsサービスアカウントの選び方

更新履歴(6件・最終更新 2026年09月06日)

この記事に加えた変更の記録です。アーカイブした更新前のバージョンは、DOI付きの固定URLから読めます。

2026年09月06日: 記事の主張を変えず、実行アカウントの選定、ローカル権限とネットワーク上の身元、gMSA導入、切替・監査の順に整理した。
2026年08月22日: 知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
2026年08月22日: 知識マップの関係を総点検し、説明文と食い違っていた関係(向きの逆転・過剰な一般化・述語の取り違え)を修正しました。本文の説明は変えていません。
2026年08月22日: 知識マップの「gMSAはWindows LAPSの後継」という関係を削除しました。両者は別の問題を解く仕組みで、後継関係にはないためです。本文の説明は変えていません。
2026年08月22日: 知識マップの「gMSAをSCMに用いることは推奨されない」という関係を、「gMSAはパスワード入力を前提とするアプリと両立しない」に改めました。gMSAがサービスの第一候補であるという本文の趣旨に図を合わせたものです。本文の説明は変えていません。
2026年08月21日: 仕組みの説明を図で追えるよう、Mermaid図を22点追加しました。実行アカウントが決める3つのこと、サービス起動時にSCMがトークンを割り当てる流れ、LocalSystem乗っ取り時の被害の広がり、LocalSystemが既定値のまま選ばれ続ける構造、WRPとTrustedInstallerの関係、LocalServiceとNetworkServiceのネットワーク上の身元の違い、共有アカウントの分離不能、仮想アカウントが長所を保ったまま短所を解消する関係、仮想アカウントの身元がPC$へ縮退する制約、コンピューターアカウント(PC$)でのリモートアクセス、PC$方式の2つの限界、ドメインユーザー運用の負のスパイラル、Kerberoastingの流れ、gMSAのパスワード管理の流れ、KDSルートキー作成後の待ち時間、gMSA導入の4段階、gMSA対応の見極め、「サービスとしてログオン」権限の構成経路による違い、プロファイル依存とデータ配置の対策、DPAPI保護データとアカウント変更の関係、イベントID 4624によるサービス起動の監査、実行アカウントの判断フローの図です。本文の文章とコード、参考リンクは変えていません。
2026年08月20日: 初版公開

この記事を引用する(DOI（登録済みアーカイブ）: 10.5281/zenodo.22054263)

以下のDOIは過去に登録されたアーカイブを指しており、現在の本文とは一致しない場合があります。現在の本文を参照するときは、このページのURLを使用してください。

小村豪(2026)「Windowsサービスのアカウント選定 ── LocalSystem・仮想アカウント・gMSAの使い分け」合同会社小村ソフト. https://comcomponent.com/blog/windows-service-accounts-gmsa-guide/

DOI（登録済みアーカイブ）: 10.5281/zenodo.22054263
DOI（前回登録した版）: 10.5281/zenodo.22054264

「LocalSystemで動くサービスが、監査で過剰な権限だと指摘された。何に変えればよいのか」「共有フォルダーに接続するためにドメインユーザーを使っているが、パスワードの期限切れでサービスが止まる」── この2つは、サービスの実行アカウントが設計判断ではなく、「動いた設定」のまま固定されているときに起きる典型的な相談です。

実行アカウントを選ぶときは、PC内で何ができるか、接続先から誰に見えるか、パスワードを誰が管理するかを分けて考えます。ローカルの権限を強くすることと、共有フォルダーに認証して接続できることは、同じではありません。¹²

本記事の結論は、単一マシン内で完結する業務サービスは仮想アカウント、ドメイン内でサービス固有の身元が必要ならgMSAを第一候補にすることです。「サービスに人間用のパスワードを持たせない」構成を基本にし、ドメインユーザーは最後の手段とします。ただし、既存サービスを一律に即時変更するのではなく、必要な権限と移行時の影響を確かめます。³⁴

対象は、中小企業の情シス担当者とWindowsアプリ開発者です。元記事の2026年8月時点のMicrosoft Learnにもとづく説明を、選定 → ローカル権限 → ネットワーク上の身元 → gMSAの導入 → 切替・監査の順に整理します。サービス自体の作り方は「Windowsサービスの作り方と運用」を参照してください。

1. まず選ぶ：6つのアカウントと4つの質問

1.1 比較する軸は「権限・身元・パスワード管理」

サービスの起動時、サービスコントロールマネージャー(SCM)は、構成されたアカウントでログオンします。成功するとアクセストークンをサービスプロセスに割り当て、以後のファイルやパイプへのアクセスは、そのトークンとアクセス制御リスト(ACL)の突き合わせで判定されます。実行アカウントを選ぶとは、サービスに渡すトークンの中身を決めることです。¹

アカウント	ローカル権限	ネットワーク上の身元	パスワード管理	主な使いどころ
LocalSystem	ほぼ無制限(SYSTEM＋Administrators)	コンピューターアカウント(PC$)	利用者による設定は不要	OSと一体で動く、強い特権が必須の例外的なサービス
LocalService	最小(Users相当)	匿名	不要	ネットワーク上の身元が不要なローカル処理
NetworkService	最小(Users相当)	コンピューターアカウント(PC$)	不要	低権限で、マシン単位の身元があればよい処理
仮想アカウント `NT SERVICE\<名前>`	最小＋ACLで個別に付与	コンピューターアカウント(PC$)	不要(自動管理)	単一サーバーで動く業務サービスの既定解
ドメインユーザー	付与した分だけ	そのユーザー自身	手動。期限・漏えい・ローテーションの管理が必要	gMSA非対応アプリで固有の身元が必要な場合の最後の手段
gMSA	付与した分だけ	そのgMSA自身	ADが自動生成・自動ローテーション	ドメイン環境でサービス固有の身元、または複数サーバーで共通の身元が必要な場合

表のPC$によるネットワーク認証はドメイン環境が前提です。ワークグループでは同じ方法は使えません。また、LocalSystemにもWRP保護領域などの制限があります。「ほぼ無制限」を文字どおりの無制限と捉えないでください。⁵⁶²⁷

LocalSystem・LocalService・NetworkService・仮想アカウントでは、利用者がサービス用のパスワードを設定・管理する必要はありません。一方、ドメインユーザーやローカルユーザーを使う構成では、SCMに保存するパスワードの期限や変更を人が管理します。gMSAは、パスワード自体は存在しますが、その管理をADに任せる方式です。¹⁸

1.2 選定は4つの質問で進める

最初に他のマシンへWindows認証で接続するかを確認し、必要ならドメイン参加の有無、マシン単位の身元で足りるか、アプリがgMSAに対応するかの順に判断します。

flowchart TB
    accTitle: 実行アカウントの判断フロー
    accDescr: ネットワークアクセスの有無、ドメイン参加、マシン単位の身元で足りるか、gMSA対応の4つの質問に順に答えて実行アカウントを決める
    q1{"他マシンへWindows認証で接続?"} -->|しない| va["仮想アカウント"]
    va -.-> sys["特権必須ならLocalSystem"]
    q1 -->|する| q2{"ドメイン参加?"}
    q2 -->|いいえ| cred["資格情報を保護し保存"]
    q2 -->|はい| q3{"マシン単位で足りる?"}
    q3 -->|はい| pcacl["仮想アカウント+PC$許可"]
    q3 -->|いいえ| q4{"アプリはgMSAに対応?"}
    q4 -->|はい| gmsa["gMSA"]
    q4 -->|いいえ| du["専用ユーザー+緩和策"]

図1: ローカルで完結するなら仮想アカウント。ドメイン内でPC$では粒度が足りない場合はgMSAへ進む。ワークグループでは、資格情報を別に設計する。

やりたいこと・困りごと	最初の判断	詳しく読む
単一マシンの通常の業務サービスを動かす	仮想アカウントを選び、必要なACLを付与する	2章
LocalSystemから変更したい	本当に強いローカル特権が必要か、先に確認する	2.3・7章
ドメイン内の共有フォルダーやDBに接続したい	マシン単位でよければ、仮想アカウント等＋接続先でのPC$許可を検討する	3章
接続先でサービスを区別したい、複数サーバーで同じ身元を使いたい	gMSAの要件とアプリの対応を確認する	4・5章
gMSAに対応しないアプリで固有の身元が必要	専用ドメインユーザーと緩和策を組み合わせる	6章
アカウント変更後に起動しない、設定を読めない	ログオン権利・ACL・プロファイル・DPAPIを分けて確認する	7章

既存のLocalServiceによるローカル処理や、NetworkServiceによるマシン単位のアクセスを、理由なくすべて置き換える必要はありません。新規に選ぶときは、低権限とサービス単位の分離を両立できる仮想アカウントを基本にします。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全19件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. PC内の権限を決める：仮想アカウントを基本にする

2.1 LocalServiceとNetworkServiceは、ネットワーク上の身元が違う

LocalServiceとNetworkServiceは、低権限サービスのための組み込みアカウントです。どちらもローカルでは、おおむねUsersグループのメンバー相当の最小限の権限で動きます。違うのは、リモートに提示する資格情報です。⁶³

アカウント	名前・SID	リモートへの接続
LocalService	`NT AUTHORITY\LOCAL SERVICE`、`S-1-5-19`	匿名資格情報を使う。認証が必要なリソースへのアクセスには向かない
NetworkService	`NT AUTHORITY\NETWORK SERVICE`、`S-1-5-20`	コンピューターの資格情報を使う。ドメイン内では `DOMAIN\コンピューター名$` として見える

ネットワークに出ない、または身元を求められないならLocalService。ドメイン内でマシンの身元が必要ならNetworkService、という使い分けです。

ただし、どちらも複数のサービスが同じアカウントを共有する点に注意します。ACLをその共有アカウントに付与している限り、サービスごとの区別はできません。LocalServiceで動くサービスが5つあれば、そのアカウントに許可したリソースへ5つともアクセスできてしまいます。SQL ServerがLocal Serviceをサポートしない理由も、共有アカウントでは他サービスから分離できないためです。³

2.2 仮想アカウントなら、サービスごとにACLを付与できる

仮想アカウントは、Windows Server 2008 R2 / Windows 7以降で使える、管理されたローカルアカウントです。名前は NT SERVICE\<サービス名>。アカウントの作成やパスワード設定は不要で、サービス1つにつき固有の身元を持ちます。ドメイン環境のネットワークアクセスには、コンピューターアカウントの資格情報を使います。²

LocalService・NetworkServiceの「パスワード管理不要」という長所を保ちつつ、アカウントを共有する弱点を解消できるわけです。SQL Serverのセットアップが既定で NT SERVICE\MSSQLSERVER などを使うのも、この考え方です。³

実務上の利点は、ACLにそのサービスを直接指定できることです。グループ作成やパスワード管理を増やさずに、「このデータフォルダーへの変更権限を、このサービスに付与する」という設定ができます。

次は、既存の MyAppService を仮想アカウントへ切り替える例です。実行前に7章のログオン権利・データ配置・DPAPIを確認し、検証環境で起動と主要機能を確かめてください。

# サービスのログオンアカウントを仮想アカウントへ変更する
# obj= の値は「NT SERVICE\サービス名」。パスワードは指定しない
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# 構成の確認(SERVICE_START_NAME を確認する)
sc.exe qc MyAppService

# データフォルダーへの変更権限を、このサービスにだけ付与する
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

GUIでは、services.msc のサービスのプロパティ →「ログオン」タブで、アカウント名を NT SERVICE\サービス名 にし、パスワード欄は空のままにします。仮想アカウントやMSAではパスワードを指定しません。変更はサービスの再起動で反映されます。³

ローカルで固有の身元を持てても、ネットワークの先でサービスを区別できるとは限りません。この制限は3章で説明します。

2.3 LocalSystemは「動くから」ではなく、必要な特権で判断する

LocalSystem(NT AUTHORITY\SYSTEM、表示名はローカルシステム)は、SCMが使う定義済みアカウントです。トークンには NT AUTHORITY\SYSTEM と BUILTIN\Administrators のSIDが含まれ、広範なローカル権限を持ちます。SeDebugPrivilege や SeTcbPrivilege などの強い特権も既定で有効です。⁵

この強さは、侵害されたときの被害の大きさでもあります。LocalSystemのサービスに任意コード実行の脆弱性があると、全ユーザーのファイルの読み取り・改ざん、他プロセスのメモリ読み取り、資格情報の窃取と横展開の起点になり得ます。NTFS上でSYSTEMは既定でフルコントロールを持ちます。⁶ 認証情報の窃取と横展開の関係は「図解でわかるNTLMとKerberos」「Windows LAPS実務ガイド」でも扱っています。

それでもLocalSystemが選ばれ続けるのは、sc.exe create で obj= を省略した場合の既定値であり、古いサンプルやインストーラーの雛形にも多く残っているためです。開発中に権限エラーに遭遇しにくく、「動いたのでそのまま」にしがちです。しかしMicrosoftも、ほとんどのサービスにこの特権レベルは不要で、必要がなければLocalServiceやNetworkServiceを検討するよう説明しています。⁹⁵

LocalSystemでも、何でも無条件に変更できるわけではありません。Windows Vista以降のWindowsリソース保護(WRP)は、重要なシステムファイル・フォルダー・レジストリキーの変更をTrustedInstaller(Windows Modules Installerサービス)に制限します。SYSTEMや管理者でも、通常の書き換えはアクセス拒否になります。「TrustedInstallerのアクセス許可が必要です」はこの仕組みです。⁷

その制限があっても、LocalSystemが業務サービスには過大な権限を持つことは変わりません。妥当な例外は、デバイスドライバーとの密接な連携、OSのセキュリティ基盤の操作、他サービスやセッションの管理など、要求される特権がそもそも管理者相当を超える処理です。バックアップエージェントやEDRなどでは、その必要性が問題になります。

例外に該当する場合も、本当に特権を使うコードパスがあるか、必要な部分だけを分離できないかを確認します。見極め方は「Windows の管理者特権が必要になるのはいつなのか」を参照してください。

3. 接続先から見える身元を決める：PC$で足りるか

3.1 共有フォルダーへの接続だけなら、ドメインユーザーは不要なことが多い

ドメイン参加マシンでLocalSystem・NetworkService・仮想アカウントを使うサービスは、リモートに対して DOMAIN\コンピューター名$ として認証されます。サービスから共有フォルダーへアクセスできないのは、接続先のACLにこのPC$が許可されていないだけ、という場合があります。⁵²

ここで必要なのは、サービスのローカル権限を強くすることではなく、接続先に正しい身元を許可することです。共有フォルダーでは、共有アクセス許可とNTFSアクセス許可の両方を設定します。

次はファイルサーバー側で、APPSV01 上のサービスに変更権限を与える例です。GUIでアカウントを選ぶ場合は、「オブジェクトの種類」に「コンピューター」を含めます。

# ファイルサーバー側: APPSV01 上のサービスに共有フォルダへの変更権限を与える
# 共有アクセス許可とNTFSアクセス許可の両方に付与が必要
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

SQL Serverでも、コンピューターアカウントをWindowsログインとして登録する考え方は同じです。接続文字列は Integrated Security=true を使い、サービス側でドメインユーザーのパスワードを持たずに接続します。

-- DB サーバー側: APPSV01 上のサービスからの Windows 統合認証を許可する
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

これはDBサーバー側でWindowsログインを作成する部分の例です。接続先で必要なアクセス許可を与える、という原則は共有フォルダーと変わりません。

3.2 PC$ではサービス単位の許可・監査ができない

仮想アカウントの身元はマシンローカルであり、ドメインからは認識されません。ネットワークに出るとPC$にまとまるため、同じマシンのどのサービスから来たのかを、アカウントだけでは区別できません。¹⁰⁴

flowchart TB
    accTitle: 仮想アカウントの身元はマシンの外で縮退する
    accDescr: マシン内ではサービスごとに固有の仮想アカウントも、ネットワーク上ではコンピューターアカウントに縮退し、リモート側からはどのサービスか区別できない
    vaa["仮想アカウントA"] --> pc["コンピューターアカウントPC$"]
    vab["仮想アカウントB"] --> pc
    pc --> remote["リモート側から見える身元"]
    remote -.-> nodist["どのサービスか区別できない"]

図2: PC内ではサービスごとに分離できても、接続先には同じPC$として見える。ローカルの分離とネットワーク上の分離は別の判断になる。

この方式の限界は2つです。

限界	何ができないか	次に選ぶ対応
身元がマシン単位になる	同じPCのLocalSystem・NetworkService・仮想アカウントのサービスを、接続先で個別に許可・監査できない	サービス固有の身元が必要ならgMSAを検討する
ドメインが前提になる	ワークグループにはADのコンピューターアカウントがなく、PC$認証を使えない	明示的な資格情報を保護して扱う別設計、またはドメイン参加を検討する

複数サーバーで同じ身元を共有したい場合も、マシンごとに異なるPC$や仮想アカウントでは足りません。ドメイン内でサービス固有・複数サーバー共通の身元が必要になったら、ドメインユーザーより先にgMSAを検討する、というのが本記事の方針です。gMSAもワークグループで使えるわけではありません。

4. gMSAの役割：固有の身元を持ち、パスワード管理をADに任せる

4.1 パスワードの生成・配布・更新を人間から切り離す

gMSA(グループ管理サービスアカウント)は、パスワード管理をドメインコントローラーに委ねるドメインアカウントです。ドメインコントローラーがKDS(キー配布サービス)のルートキーからパスワードを計算し、許可されたホストだけが取得してサービスに使います。⁸

flowchart TB
    accTitle: gMSAのパスワード管理の仕組み
    accDescr: KDSのルートキーからドメインコントローラーがパスワードを計算し、許可されたホストだけがそれを取得してサービスの実行に使い、パスワードは既定30日ごとに自動ローテーションされる
    kds["KDSルートキー"] --> dc["DCがパスワードを計算"]
    dc --> host["許可されたホストが取得"]
    host --> svc["サービスの実行に使用"]
    dc -.-> rot["既定30日ごとに自動ローテーション"]

図3: 人間がパスワードを知らなくても、許可されたホストが取得し、自動更新される資格情報でサービスを運用できる。

効果	運用上の意味
240バイトのランダム生成パスワード	総当たり・辞書攻撃による解読が現実的でなくなり、Kerberoasting耐性が大きく上がる
既定30日ごとの自動ローテーション	管理者が変更を計画し、パスワード更新のためにサービスを止める必要がない
複数サーバーで同じ身元を共有できる	負荷分散配下のサーバーファームでも、同じプリンシパルで相互認証できる
SPN管理を簡素化できる	サービスプリンシパル名の登録・管理を簡素化し、管理の委任もできる

これらが、手動管理のドメインユーザーよりgMSAを優先する理由です。¹¹ Windows LAPSがローカル管理者パスワードの管理を自動化するのに対し、gMSAはサービスアカウントのパスワード管理を担う、と捉えると位置づけを理解しやすくなります。両者は対象が違う仕組みです。

4.2 アプリの対応確認は省略しない

gMSAは、Windowsサービス、IISアプリケーションプール、タスクスケジューラなど、標準の仕組みでログオン身元を構成するものに広く対応します。しかし、すべてのアプリが使えるわけではありません。内部でパスワードの入力を要求する作りでは使えず、フェールオーバークラスタリング自体がgMSAをサポートしない、といった制約もあります。¹⁰

候補にしたら、本番投入前にテスト環境で「gMSAで起動すること」と「必要なリソースへアクセスできること」を確認します。これはMicrosoftも求めている手順です。¹¹

関連する選択肢には、単一サーバー用のsMSA(スタンドアロン管理サービスアカウント)と、Windows Server 2025で導入されたdMSA(委任管理サービスアカウント)もあります。dMSAは認証をデバイス識別に結び付け、資格情報窃取に対抗する仕組みです。新規構成ではgMSAを基本に、要件に応じてこれらも検討します。²

5. gMSAを導入する：前提確認からサービス設定まで

5.1 先に確認する要件

確認項目	要件・注意点
ドメイン	Active Directoryドメイン環境であること。ワークグループでは使えない
機能レベル	ドメインとフォレストの機能レベルがWindows Server 2012以上であること
KDSルートキー	作成済みであること。新規作成後は複製の待ち時間を見込む
gMSA名	ドメイン内だけでなく、フォレスト内で一意にする
パスワード変更間隔	作成時にしか設定できないため、作成前に決める
アプリ	gMSAでの起動・リソースアクセスを検証する(4.2)

gMSA名や変更間隔も、導入前に決める事項です。アカウントを作ってから考えると、作り直しが必要になります。¹⁰

5.2 KDSルートキーを確認し、なければ作成する

KDSルートキーの作成は、フォレストで1回だけの作業です。既存のキーを確認してから、未作成の場合にだけ追加します。

# ドメイン管理者として、ドメインコントローラー(または AD PowerShell モジュール
# の入った管理端末)で実行する

# KDS ルートキーの有無を確認し、なければ作成する(フォレストで1回だけ)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # 実際に使えるのは最大10時間後

-EffectiveImmediately を指定しても、作成直後から使えるとは限りません。全ドメインコントローラーへの複製を待つため、作成後は最大10時間の待ち時間があり、その間はgMSAを作成できません。複製が不完全なままパスワード取得に進み、失敗する事故を防ぐためです。導入計画にはこの時間も含めてください。¹²

5.3 取得を許可するホストを絞り、gMSAを設定する

手順は4段階です。前半はAD側の構成、後半はサービスを動かす各サーバー側の作業になります。¹⁰

段階	作業	確認すること
① 取得を許可するグループを作る	対象サーバーのコンピューターアカウントを追加する	グループ追加後、サーバーを再起動してメンバーシップを反映する
② gMSAを作る	`New-ADServiceAccount` で取得を許可するグループを指定する	名前とDNS名、許可するホストの範囲が合っている
③ 各サーバーにインストールする	`Install-ADServiceAccount` を実行する	`Test-ADServiceAccount` が `True` を返す
④ サービスの実行アカウントに設定する	`DOMAIN\名前$` を指定し、サービスを再起動する	パスワード欄は空。ログオン権利とリソース側のACLも確認する

次の例を実行する前に、7.1の「サービスとしてログオン」の権利も構成します。sc.exe config が成功したことと、サービスがログオンできることは別です。

# ① パスワード取得を許可するセキュリティグループを作り、
#    サービスを動かすサーバーのコンピューターアカウントを追加する
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# グループメンバーシップはコンピューターのログオン時に評価されるため、
# 追加後は対象サーバーを再起動しておくのが確実

# ② gMSA を作成する
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ サービスを動かす各サーバー上で、gMSA をインストールして検証する
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True なら取得できている

# ④ サービスの実行アカウントに設定する。名前の末尾に $ を付け、パスワードは指定しない
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

services.msc でも、アカウント名は CORP\svc-batch$ のように末尾に $ を付け、パスワード欄は空のままにします。MSA系アカウントは対話的なサインインには使えません。³

接続先の共有フォルダーやSQL Serverでは、PC$の代わりに CORP\svc-batch$ へ必要なアクセス許可を付与します。これで、人がパスワードを管理せずに、サービス固有の身元でネットワークアクセスする構成になります。Test-ADServiceAccount による取得確認だけで終えず、実際のサービスの主要機能まで検証してください。

6. ドメインユーザーは最後の手段：使うなら緩和策をそろえる

6.1 期限切れの回避が、別のリスクを固定化する

ドメインユーザーやローカルユーザーをサービスに割り当てると、SCMはパスワードを保存し、起動のたびにログオンに使います。しかし、SCMは期限を管理しません。保存されたパスワードが期限切れになればログオンに失敗し、サービスは起動しなくなります。¹

ここから、期限切れ事故を防ぐために無期限へ変更し、同じパスワードを複数サーバーの手順書・スクリプト・タスクに平文で残し、最後は「変えるとどこが止まるか分からない」ため退職者が出ても変更できない、という悪循環が起きます。

Microsoftも、ドメインアカウントをサービスに使う構成では、パスワードとSPNの手動管理に運用工数がかかり、メンテナンスがサービス停止を招き得ると指摘しています。無期限にするだけでは、管理の問題を解消できません。³

6.2 SPNを持つアカウントはKerberoastingの対象にもなる

Kerberos認証を受けるサービスは、実行アカウントにSPN(サービスプリンシパル名)を登録します。ドメインの認証済みユーザーはそのサービスチケットを要求できるため、攻撃者がチケットを取得し、オフラインでパスワードの総当たりを試みるのがKerberoastingです。

人間が決めた10〜16文字程度のパスワードに頼るのではなく、長いランダム生成パスワードを使うことが対策になります。Microsoftも、長いパスワードの強制と、機械生成の長大なランダム値を使うgMSAを挙げています。¹³

同じ文書が触れているKerberosアーマリング(FAST)は、事前認証データやKDC偽装への耐性を保護するものです。認証済みユーザーによるSPNへのサービスチケット要求自体を防ぐものではなく、サービスアカウントのパスワード強度の代わりにはなりません。SPNとKerberos、NTLMへ切り替わる条件は「図解でわかるNTLMとKerberos」を参照してください。

6.3 非対応アプリでは、専用アカウントと運用をセットにする

アプリがgMSAに対応しないなどの理由で、専用ドメインユーザーを使わざるを得ない場合は、次の緩和策をすべて実施します。

項目	実施すること
パスワード	25文字以上のランダム生成にする。パスワード管理ツール以外の手順書・スクリプト・共有Excelに書かない
アカウントの用途	人間用と兼用せず、サービス専用にする。サービスごとに分ける
ログオンの制限	対話型ログオンとリモートデスクトップを拒否し、「サービスとしてログオン」を許可する
権限	所属グループとアクセス許可を最小化する。Domain Adminsに追加しない
更新と台帳	定期ローテーションの手順を整え、変更が波及するサーバー・サービス・タスク等を台帳化する

サービスの身元を人間のアカウントから切り離すことも、重要な原則です。⁴ これらの管理を人が続けるより、対応するサービスをgMSAへ移すほうが安全で運用も軽くなる、というのがgMSAを優先する理由です。

7. 切替と監査：アカウント名だけ変えて終わらない

7.1 「サービスとしてログオン」の権利を確認する

サービスとして起動するには、アカウントに SeServiceLogonRight(サービスとしてログオン) が必要です。LocalSystem・LocalService・NetworkServiceには組み込みで与えられていますが、それ以外のアカウントで動かす場合は、この権利の割り当てを確認します。¹⁴

構成方法	権利の扱い	運用で確認すること
`services.msc` の「ログオン」タブ	スナップインが権利を自動付与する	ポリシー適用後も必要な権利が保たれるか
`CreateService` / `ChangeServiceConfig`、`sc.exe config`	アカウントが権利を持つかを検証しない	権利を付与する手順を別に含める
GPOでの構成	ローカルでの付与がポリシー適用時に上書きされ得る	組織側のポリシーにも対象アカウントを含める

ローカルセキュリティポリシー(secpol.msc)やGPO・Intuneによる権利の構成を、デプロイ手順に明記します。ツールの副作用に頼らないことが大切です。サービス専用アカウントには、対話型ログオンの拒否も組み合わせます。

7.2 プロファイル配下のデータと、ACLを確認する

SCMはサービス起動時に、そのアカウントのユーザープロファイルをロードします。したがって %TEMP%、%APPDATA%、HKEY_CURRENT_USER の実体はアカウントごとに異なります。切替後に設定やキャッシュが「消えた」ように見えるのは、旧アカウントとは別のプロファイルを参照しているためです。¹

対策は、サービスのデータを C:\ProgramData\<アプリ名> のような明示的なパスへ置き、実行アカウントにACLを付与することです。アカウントごとのプロファイルから切り離せば、次のアカウント変更で保存先を移し直す必要をなくせます。既にプロファイル配下に保存しているデータは、切替計画に移行を含めてください。

必要なフォルダーだけでなく、レジストリなどのアクセス許可も確認します。アカウントを低権限に変更したあとに、以前のLocalSystem権限を前提としていた処理が失敗しないかを検証します。

7.3 DPAPI保護データは、ファイルを移すだけでは引き継げない

ユーザースコープのDPAPI(CryptProtectData、.NETの ProtectedData など)で保護したデータは、原則として保護時と同じアカウントでしか復号できません。実行アカウントを変えると、保存済みの接続文字列やAPIキーが読めなくなります。

このため、プロファイルのファイル移行とは別に、切替後にシークレットを再投入する手順を用意します。DPAPIが正しく保護している結果でも、準備していなければサービスの障害になります。保存先の設計は「Windowsアプリの機密情報保存」を参照してください。

gMSAやPC$によるWindows統合認証で済む接続なら、シークレットの保存そのものをなくせます。「どこに保存するか」より先に「保存しなくて済むか」を考えるのが順序です。

また、「呼び出し元ユーザーの権限で処理したい」場合は、サービスの実行アカウントを強くするのではなく、偽装(インパーソネーション)を検討します。詳しくは「Windowsの偽装トークンを正しく扱う」で説明しています。

7.4 サービス一覧で棚卸しし、ログで起動時の身元を確認する

最初の棚卸しには、サービス一覧の実行アカウントを集計します。次の例は、アカウント別の件数と、Windowsフォルダー外のパスを持つLocalSystemサービスを確認するものです。

# どのサービスがどのアカウントで動いているかを集計する
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# LocalSystem で動く非標準のサービスを洗い出す(パスで自社/サードパーティ製を見分ける)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

業務サービスがLocalSystemやドメインユーザーで動いていたら、1章の判断に戻り、必要な特権・接続先で必要な身元を確認します。パスによる抽出は候補を見つける手がかりとして使い、サービスの実際の用途と処理内容で判断してください。

サービスの起動は、セキュリティイベントログの イベントID 4624、ログオンタイプ5(Service) で確認できます。これはSCMによるサービス開始のログオンを表します。「仮想アカウント」フィールドは、MSA・仮想アカウントによるログオンかを示すため、管理されたアカウントの利用状況の監視にも使えます。¹⁵

7.5 本番切替前の確認をまとめる

確認するもの	切替前後で確かめること
ローカル権限	必要な特権と、フォルダー・レジストリ等へのACLがそろっている
ネットワーク上の身元	PC$またはgMSAなど、想定した身元に接続先のアクセス許可を与えている
ログオン権利	「サービスとしてログオン」が割り当てられ、ポリシーで失われない
保存先	プロファイル、TEMP、HKCUの変化と、既存データの移行を確認した
DPAPI	ユーザースコープで保護した資格情報等の再投入手順がある
動作と監査	検証環境で起動・主要機能を確認し、切替後の実行アカウントとログを確認する

LocalSystemから移す場合も、gMSAを導入する場合も、この確認を終えてから本番を切り替えます。最小権限化と、必要な機能が動き続けることをセットで確かめるのが移行の要点です。

8. まとめ

サービスアカウントの選定では、ローカル権限・ネットワーク上の身元・パスワード管理を分けて考えます。LocalSystemが既定値でも、それを使う理由にはなりません。通常の業務サービスは仮想アカウントを基本にし、必要なACLを付与します。強い特権が本当に必要な場合だけ、LocalSystemを検討します。⁵³

ドメイン内の接続先でマシン単位の身元があればよいなら、仮想アカウント等とPC$へのアクセス許可で済むことがあります。サービス固有の身元や、複数サーバーで共通の身元が必要ならgMSAを選び、パスワード管理をADに任せます。ワークグループではPC$もgMSAも使えず、資格情報を扱う別の設計が必要です。²¹⁰

ドメインユーザーが必要な場合は、専用アカウント・長いランダムパスワード・ログオン制限・最小権限・ローテーションと台帳をそろえます。切替時には、アカウント名だけでなく、ログオン権利・プロファイル・DPAPIも確認します。

次にサービスを構成するときの問いは、「このサービスは、誰として、どこまでアクセスできるべきか」です。その答えに合わせてアカウントを選び、「動いた設定」のまま固定しないようにしてください。

参考リンク

Microsoft Learn, Service User Accounts. サービスがユーザーアカウントのセキュリティコンテキストで実行されること、SCMが起動時にアカウントへログオンしてアクセストークンをサービスプロセスへ関連付けること、SCMがユーザープロファイルをロードすること、SCMはパスワードの期限を管理せず期限切れではログオンが失敗しサービスが起動しないことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Service accounts. 仮想アカウントが自動管理されるローカルアカウントでパスワード管理が不要なこと、名前がNT SERVICE<SERVICENAME>形式であること、ドメイン環境ではコンピューターアカウント(\$)の資格情報でネットワークへアクセスすること、sMSA・gMSA・dMSA・仮想アカウントの使い分けの基準について。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶
Microsoft Learn, Configure Windows service accounts and permissions. SQL Serverの既定サービスアカウントが仮想アカウント(NT SERVICE\MSSQLSERVER等)であること、仮想アカウント・MSA指定時はパスワード欄を空にすること、MSAが末尾$付きの名前で対話サインインには使えないこと、Local Serviceが共有アカウントであるため分離できずSQL Serverでサポートされないこと、ドメインアカウント利用時はパスワードとSPNの手動管理に工数がかかり保守作業がサービス停止を招き得ること、常に最小権限のアカウントでサービスを実行すべきことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸
Microsoft Learn, Securing on-premises service accounts. オンプレミスのサービスにはまずgMSA、使えなければsMSA、次いでコンピューターアカウント、最後にユーザーアカウントという優先順位、コンピューターアカウントを使う場合はどのサービスがそのアカウントを使っているかを判別できず変更の監査ができないこと、サービスアカウントの役割(サービスの識別・認証・起動)について。 ↩ ↩² ↩³
Microsoft Learn, LocalSystem Account. LocalSystemがローカルコンピューター上で広範な特権を持ち、トークンにNT AUTHORITY\SYSTEMとBUILTIN\AdministratorsのSIDを含むこと、パスワードを持たないこと、リモートサーバーへはコンピューターの資格情報を提示すること、SE_DEBUG_NAMEやSE_TCB_NAMEを含む特権の一覧、ほとんどのサービスにはこの特権レベルは不要でLocalService/NetworkServiceの利用を検討すべきことについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Local accounts. SYSTEM(S-1-5-18)がNTFSボリューム上で既定でフルコントロールを持つこと、NETWORK SERVICE(S-1-5-20)がリモートサーバーへコンピューターの資格情報を提示すること、LOCAL SERVICE(S-1-5-19)がローカルで最小限の特権を持ちネットワークへは匿名資格情報を提示することについて。 ↩ ↩² ↩³
Microsoft Learn, About Windows Resource Protection. Windowsリソース保護(WRP)が重要なシステムファイル・フォルダー・レジストリキーの置き換えを防ぐこと、WRP保護リソースへのフルアクセスがTrustedInstallerに制限されており、変更はWindows Modules Installerサービスを介したサポートされた置換メカニズムでのみ行えること、保護リソースを変更しようとするアプリケーションはアクセス拒否を受けることについて。 ↩ ↩²
Microsoft Learn, Group Managed Service Accounts overview. gMSAがWindowsにパスワード管理を任せるドメインアカウントであること、キー配布サービス(kdssvc.dll)の共有シークレットからドメインコントローラーがパスワードを計算し、メンバーホストがドメインコントローラーへ問い合わせて現在と直前のパスワードを取得すること、サーバーファームで同一プリンシパルによる相互認証を可能にすることについて。 ↩ ↩²
Microsoft Learn, sc.exe config. サービスの実行アカウントをobj=パラメーターで指定すること、その既定値がLocalSystemであること、LocalSystem以外のユーザーアカウントを使う場合のpassword=パラメーターについて。 ↩
Microsoft Learn, Manage group Managed Service Accounts. gMSAの前提条件(ドメイン/フォレスト機能レベル2012以上、KDSルートキーの作成)、gMSA名がフォレスト内で一意である必要があること、パスワード変更間隔は作成時のみ設定できること、New-ADServiceAccountの-PrincipalsAllowedToRetrieveManagedPasswordでパスワード取得を許可するグループを指定すること、Install-ADServiceAccount/Test-ADServiceAccountの手順、仮想アカウントの身元がマシンローカルでドメインから認識されないこと、フェールオーバークラスターがgMSAをサポートしないこと、SCM・IISアプリプール・タスクスケジューラがgMSAでのログオン構成に対応することについて。 ↩ ↩² ↩³ ↩⁴ ↩⁵
Microsoft Learn, Secure group managed service accounts. gMSAのパスワードが240バイトのランダム生成で総当たり・辞書攻撃を受けにくいこと、Windows OSが30日ごとにパスワードを変更し管理者による変更計画やサービス停止が不要なこと、サーバーファームへの展開とSPN管理の簡素化、サービスがgMSAをサポートしない場合はsMSA、それも不可なら強力なパスワード管理を伴う標準ユーザーアカウントを使うこと、本番前にテスト環境でgMSAでの動作を確認すべきことについて。 ↩ ↩²
Microsoft Learn, Create a Key Distribution Service (KDS) root key. ドメインコントローラーがgMSAパスワードの生成を始めるためにルートキーが必要なこと、Add-KdsRootKey -EffectiveImmediatelyによる作成手順、作成後最大10時間はAD複製の収束を待つためgMSAを作成できないこと、複製が不完全なままではパスワード取得が失敗し得ることについて。 ↩
Microsoft Learn, Protect SMB traffic from interception. サービスアカウント保護策としてのgMSA(機械生成の長大なランダムパスワードにより総当たり・辞書攻撃によるパスワード解読が現実的でなくなること)、長いパスワードの強制、Kerberosアーマリング(FAST)への言及などの推奨事項について。 ↩
Microsoft Learn, Policy CSP - UserRights: LogOnAsService. 「サービスとしてログオン」権利によりセキュリティプリンシパルがサービスとしてログオンできること、Local System・Local Service・Network Serviceには組み込みでこの権利があること、それ以外のアカウントで実行するサービスにはこの権利の割り当てが必要なこと、グループポリシーでの構成パスについて。 ↩
Microsoft Learn, 4624(S): An account was successfully logged on. イベント4624がログオンセッション作成時にアクセス先コンピューターで記録されること、ログオンタイプ5がサービス(SCMによるサービス開始)を意味すること、「Virtual Account」フィールドでMSA・仮想アカウントによるログオンを識別でき、管理されたサービスアカウントの監視に使えることについて。 ↩

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

Windowsアプリ開発

業務アプリ、装置連携、通信ツールなどの Windows ソフト開発を支援します。

サービスを見るお問い合わせ

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

とりあえずLocalSystemで動かしているサービスは、今すぐ変えるべきですか？: 一律に即時変更が正解とは限りません。まず、そのサービスが本当にLocalSystem相当のローカル権限(管理者を超える強い特権)を必要としているかを確認してください。ファイルの読み書きとネットワーク通信程度なら、仮想アカウント(NT SERVICE\サービス名)へ移すのが第一候補です。移行時には、必要なフォルダーやレジストリへのアクセス許可の付与、プロファイルやDPAPIに依存したデータの扱い、「サービスとしてログオン」権限の有無を確認します。検証環境で起動と主要機能を確かめてから、本番を切り替えてください。
仮想アカウントとNetworkServiceはどちらを選ぶべきですか？: 新規に選ぶなら仮想アカウントをおすすめします。両者はネットワーク上ではどちらもコンピューターアカウント(DOMAIN\コンピューター名$)として見え、ローカル権限が小さい点も似ています。しかしNetworkServiceは複数のサービスが同じアカウントを共有するため、ACLで「このサービスだけに許可する」という分離ができません。仮想アカウントはサービスごとに固有の身元を持ち、ACLにNT SERVICE\サービス名を直接指定できます。SQL Serverなど近年のMicrosoft製品の既定も仮想アカウントです。
gMSAはワークグループ環境(ドメインなし)でも使えますか？: 使えません。gMSAはActive Directoryのドメインコントローラーがパスワードを生成・管理する仕組みで、ドメインとKDSルートキーの作成が前提です。ワークグループ環境では、仮想アカウントかLocalService/NetworkServiceでローカル処理を完結させるのが基本です。他のマシンへのアクセスが必要な場合は、接続先に用意したアカウントの資格情報を明示的に使うなどの別設計になります。コンピューターアカウント(PC$)としてのネットワークアクセスも、ドメイン環境でだけ成り立つ話です。
サービスの実行アカウントを変えたら、保存していた設定や資格情報が読めなくなりました。なぜですか？: 実行アカウントには、それぞれ固有のユーザープロファイル・%TEMP%・HKEY_CURRENT_USER・DPAPIキーが紐づいているためです。特にDPAPI(CryptProtectData等)でユーザースコープの保護をかけたデータは、原則として保護したときと同じアカウントでしか復号できません。また、プロファイル配下(AppData等)に保存したファイルは、新アカウントからは別のパスになります。アカウント切替の前に、DPAPI保護済みデータの再作成手順(APIキーの再入力等)と、プロファイル配下のファイルの移行を計画してください。
サービスから共有フォルダにアクセスしたいだけなら、ドメインユーザーは必要ですか？: 多くの場合は不要です。ドメイン環境なら、LocalSystem・NetworkService・仮想アカウントで動くサービスは、リモートに対してコンピューターアカウント(DOMAIN\コンピューター名$)として認証されます。共有フォルダの共有アクセス許可とNTFSアクセス許可にそのPC$を追加すれば読み書きできます。サービス固有の身元でアクセス制御したい場合や、複数サーバーで同じ身元が必要な場合は、ドメインユーザーではなくgMSAを検討してください。

著者プロフィール

記事の著者プロフィールページです。

小村豪

合同会社小村ソフト代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

プロフィールを見るお問い合わせ

公開リンク

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal