コンテンツにスキップ

gMSA（グループ管理サービスアカウント）とは？サービス用アカウントのパスワードをADに任せる

2026-10-27 更新約8分で読めます

最終確認: 2026-10-27

30秒で復習

  • gMSA（ジーエムエスエー）＝Windowsのサービスやタスクを動かすための、パスワードをActive Directory（AD）が自動で管理してくれるアカウント。 Windows Server 2012 から使える。
  • パスワードはADが自動で作る長いランダムな文字列で、既定で30日ごとに自動で変わる。人は誰もパスワードを知らない。
  • 「パスワードを取り出してよいサーバー」をグループで指定するので、複数のサーバーで同じアカウントを使える（1台だけの sMSA との違い）。
  • 使うときは、サービスのログオンに CORP\svc-web$ のように末尾に $を付けて指定し、パスワード欄は空にする。
  • 弱点は「取り出してよいサーバー」と「ドメインコントローラー」。ここを乗っ取られるとパスワードも取られるので、許可するサーバーは最小にし、DCは最重要の資産として守る。
  • 覚え方：「合鍵を人に配らず、金庫（AD）が毎月勝手に鍵を作り替えてくれる」

用語の正式名称と読み方

用語 正式名称 意味
gMSA group Managed Service Account 複数のサーバーで使える、パスワード自動管理のサービス用アカウント
sMSA standalone Managed Service Account 1台のサーバー専用の旧版（Windows Server 2008 R2〜）
dMSA delegated Managed Service Account 古いサービス用アカウントから移行するための新しい種類（Windows Server 2025〜）
サービスアカウント — 人ではなく、プログラム（サービス・バッチ・Webアプリ）がログオンするためのアカウント
KDS ルートキー Key Distribution Service root key DCがgMSAのパスワードを計算するための元になる鍵。フォレストに1つ作る
DC Domain Controller ADのサーバー。ユーザー・パスワード・グループを管理する

質問：gMSAとは？ 何がうれしい？

答え： サービス用のアカウントのパスワード管理を、人の手からADに移す仕組み。これまでのサービス用アカウントは、普通のユーザーアカウントを作り、パスワードを人が決めて設定していた。その結果、次のような問題が起きやすかった。

従来のサービス用ユーザー 合鍵を人に配る ✕ パスワードを人が決める（短くなりがち） ✕ 手順書や設定ファイルに書かれる ✕ 止まるのが怖くて何年も変えない ✕ 構築した人・手順書を見た人が知っている ✕ 漏れたら、どのPCからでもログオンできる gMSA 金庫（AD）が鍵を管理する ○ ADが長いランダムなパスワードを作る ○ どこにも書かない（書けない） ○ 既定で30日ごとに自動で替わる ○ 人は誰もパスワードを知らない ○ 許可したサーバーだけが取り出せる
観点 普通のユーザーをサービス用に使う gMSA
パスワードを決めるのは 人 AD（自動）
パスワードの強さ 覚えやすい・短いものになりがち 長いランダムな文字列
パスワードの変更 止まるのが怖くて何年も変えない 既定で30日ごとに自動
パスワードを知っている人 構築した人・手順書を見た人 誰も知らない
使えるサーバー どこでも（漏れたら、どこからでもログオンできる） 許可したサーバーだけ
変更時のサービス停止 全サーバーの設定を手で直す 自動で切り替わる（再設定不要）

イメージ（たとえ話）

  • 普通のサービス用アカウント＝合鍵を作って関係者に配る。誰が持っているか分からなくなり、鍵を替えるとみんなに配り直す必要があるので、何年も同じ鍵を使い続ける。
  • gMSA＝金庫（AD）が毎月勝手に鍵を作り替え、登録したロボット（サーバー）だけが鍵を受け取れる。人は鍵を見たことがないので、漏らしようがない。

質問：どんな仕組みで動く？

答え： DCがKDSルートキーをもとにパスワードを計算し、取り出してよいと登録されたサーバーだけがパスワードを受け取って、サービスを起動する。

ドメインコントローラー KDSルートキーで パスワードを計算 30日ごとに自動更新 取り出してよいサーバー（グループ） サーバーA Windowsサービスを起動 サーバーB タスク・IISアプリプール ○ パスワードを取り出して起動 ログオン：CORP\svc-web$（パスワード欄は空） 許可なしのサーバー ✕ 取り出せない 管理者 パスワードを 知らない ＝ 漏れない 使い回せない
  1. 最初に一度だけ、フォレストに KDSルートキーを作る
  2. gMSAを作るときに、パスワードを取り出してよいサーバー（ふつうはサーバーのコンピューターアカウントを入れたグループ）を指定する
  3. 許可されたサーバーは、必要なときにDCからパスワードを受け取り、サービスやタスクを起動する
  4. パスワードの期限が来ると、DCが新しいパスワードを計算し、サーバーも自動で新しいものを使う

sMSA・gMSA・dMSA の違い

種類 使えるようになった版 使えるサーバー 主な用途
sMSA Windows Server 2008 R2 1台だけ 1台のサーバーのサービス（今は gMSA を使うのが一般的）
gMSA Windows Server 2012 許可した複数台 Webファーム、クラスター、タスク、IIS、SQL Server など
dMSA Windows Server 2025 1台のサーバーに結び付く 古いサービス用アカウントからの移行

質問：どうやって作って使う？

設定の流れ

1 KDSルートキー フォレストに1回 反映まで最大10時間 2 gMSAを作る 取り出してよい グループを指定 3 サーバーに入れる Install → Test True なら準備OK 4 サービスに設定 CORP\svc-web$ パスワードは空

コマンドの例（PowerShell）

# ① KDSルートキーを作る（フォレストに1回。DCに行き渡るまで最大10時間かかる）
Add-KdsRootKey -EffectiveImmediately

# ② gMSAを作る。WebServers グループのサーバーだけがパスワードを取り出せる
New-ADServiceAccount -Name "svc-web" `
  -DNSHostName "svc-web.corp.example.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "WebServers"

# ③ 使うサーバーで（RSAT の AD PowerShell モジュールが必要）
Install-ADServiceAccount -Identity "svc-web"
Test-ADServiceAccount   -Identity "svc-web"   # True なら準備OK
  • サーバーを WebServers グループに入れた直後は、グループの変更がまだ反映されていない。サーバーを再起動してから③を実行する。
  • ④ サービスの「ログオン」タブで、アカウントに CORP\svc-web$ を指定し、パスワード欄は空のままにする。
  • パスワードの変更間隔（既定30日）は、作るときにしか決められない。

使える場所・使えない場所

使える 使えない・向かない
Windowsサービス 人が対話的にログオンする用途
タスクスケジューラのタスク パスワードの入力を求めるアプリ
IISのアプリケーションプール ドメインに参加していないサーバー
SQL Server のサービス gMSAに対応していない古いアプリ（製品ごとに要確認）

質問：セキュリティで気をつけることは？

答え： パスワードは強くても、取り出せる場所が狙われる。「誰がパスワードを取り出せるか」と「DCの守り」がポイント。

リスク 起きること 対策
許可したサーバーを乗っ取られる そのサーバーの管理者権限があれば、gMSAのパスワードを取り出して、なりすませる 取り出してよいサーバーは必要な台数だけ。そのサーバー自体の管理者を絞り、EDRで守る
グループを書き換えられる 「取り出してよいグループ」に攻撃者のPCを入れられる グループを変更できる人を絞り、変更を監視する
DC・KDSルートキーを盗まれる ルートキーがあれば、gMSAのパスワードをオフラインで計算できてしまう DCは最重要の資産（Tier 0）として守る。バックアップの扱いも同じ
gMSAに権限を付けすぎる gMSA経由でドメイン全体に被害が広がる gMSAにはそのサービスに必要な権限だけ。Domain Admins に入れない
dMSAの移行機能の悪用（BadSuccessor） OUへの書き込み権限があるだけで、dMSAを使って高い権限を得られる問題が2025年に報告された dMSAを作ったり属性を書き換えたりできる人を確認する。修正の状況は最新情報で確認する
  • gMSAのパスワードは長くランダムなので、サービス用アカウントを狙うKerberoasting（チケットを盗んでパスワードを総当たりする攻撃）には強い。「弱いパスワードのサービス用アカウント」をgMSAに置き換えるのは、効果の大きい対策。

これまでのノートとのつながり

  • 「パスワードを人が知らない・自動で替わる」は、証明書の秘密鍵と同じく「鍵は本人（機械）だけが持つ」考え方。
  • オンプレのレガシーデータをMCPで扱うで、MCPサーバーから SQL Server に Windows認証でつなぐなら、MCPサーバーのサービスを gMSA で動かし、DB側では読み取り専用の権限だけを与える構成がきれい。
  • 「必要なサーバーだけがパスワードを受け取れる」は、ZTNAの「許可されたものだけ」と同じ最小権限の考え方。

具体例

場面 従来 gMSAにすると
Webサーバー3台のIIS 共通の svc_web ユーザー。パスワードは5年前のまま svc-web$ を3台に許可。パスワードは毎月自動で変わる
夜間のバッチ（タスクスケジューラ） 管理者個人のアカウントで実行 → 異動で止まる バッチ専用の gMSA で実行。人の異動に影響されない
SQL Server のサービス パスワード変更のたびに、サービスの再設定と再起動 再設定不要。変更はADとSQL Serverの間で自動

関連メモ

確認したいこと

  • 今、普通のユーザーアカウントで動いているサービス・タスク・アプリプールはいくつあるか。パスワードを最後に変えたのはいつか
  • フォレストに KDSルートキーはもう作ってあるか
  • それぞれのサービスは gMSA に対応しているか（製品のマニュアルで確認）
  • gMSAのパスワードを取り出せるサーバーと、そのグループを変更できる人は誰か
  • Windows Server 2025 のDCがある場合、dMSAを作れる・書き換えられる権限を持つ人は誰か

参考資料