gMSAとは？設定手順と使いどころをわかりやすく解説｜サービスアカウントを安全に管理する

サービスアカウントのパスワード、誰が管理してますか？

前任者が設定したまま変えていない
パスワードが共有ドキュメントに書いてある
そもそも誰も把握していない

こういうサービスアカウントがドメインに何十個も存在している現場は珍しくありません。

そのサービスアカウントこそ、Kerberoastingの主要な標的です。
SPNが設定されていて、パスワードが弱く、しかも高権限を持っている。
攻撃者にとって理想的な踏み台になります。

その根本解決策がgMSAです。
本記事ではgMSAの仕組みから設定手順まで、実務で使える形で解説します。

Kerberoastingの仕組みと攻撃の流れについては「KerberoastingとDCSyncの仕組みと防御策｜AD攻撃の2大手法を解説」を参照してください。

gMSAとは

ADが自動でパスワードを管理する仕組み

gMSAとは、Active Directoryがパスワードの生成・管理・ローテーションを自動で行う特殊なサービスアカウントです。

gMSA（group Managed Service Account：グループ管理サービスアカウント）
Active Directoryが自動でパスワードを管理するサービスアカウント。120文字のランダムなパスワードが30日ごとに自動ローテーションされる。人間がパスワードを知ることができないため、Kerberoastingによるパスワードクラックが事実上不可能になる。

gMSAの最大の特徴は人間がパスワードを知ることができない点です。パスワードはActive DirectoryのKDSが自動生成・管理するため、管理者であっても平文パスワードを取り出すことはできません。

KDS（Key Distribution Service）
Active Directory上でgMSAのパスワード生成に使う暗号鍵を管理するサービス。DC上で動作し、KDSルートキーを使ってgMSAのパスワードを定期的に生成・更新する。

通常のサービスアカウントとgMSAの違い

項目	通常のサービスアカウント	gMSA
パスワード管理	手動（人間が設定・変更）	ADが自動生成・自動ローテーション
パスワード長	任意（短いことが多い）	120文字固定（ランダム）
ローテーション周期	手動のため不定期	30日ごとに自動
Kerberoasting耐性	低い（パスワードが弱ければクラックされる）	事実上不可能（120文字ランダム）
設定の手間	少ない（ユーザー作成と同じ）	やや多い（KDSルートキーの準備が必要）
対応サービス	ほぼすべて	Windows標準サービス・一部のアプリのみ

通常のサービスアカウントでAES暗号を強制した場合でも、パスワードが弱ければ辞書攻撃は成立します。gMSAは120文字のランダムパスワードを使うため、AES・RC4どちらの暗号化であっても現実的なクラックが不可能です。

gMSAが使えるサービス・使えないサービス

gMSAはすべてのサービスに対応しているわけではありません。事前に対応状況を確認することが重要です。

対応している主なサービスは、Windowsサービス（サービスコントロールマネージャーで管理するもの）・IIS（インターネットインフォメーションサービス）のアプリケーションプール・タスクスケジューラのタスク・SQL Serverのサービスアカウントです。

対応していない、または注意が必要なサービスは、非Windowsシステム（LinuxサービスなどはgMSA非対応）・古いバージョンのサードパーティアプリ・インタラクティブログオン（ユーザーとして直接ログインする用途）です。

対応状況はアプリケーションのドキュメントを確認するか、試験的に適用して動作を確認してください。

gMSAの設定手順：DC上での事前準備

KDSルートキーを作成する

gMSAを使うには、まずDC上でKDSルートキーを作成する必要があります。これはドメイン全体で1回だけ行う作業です。

# KDSルートキーを作成する（DC上で管理者権限で実行）
Add-KdsRootKey -EffectiveImmediately

重要：-EffectiveImmediatelyを指定しても、実際に使えるようになるまで最大10時間かかります。これはKDSの仕様で、DC間でのレプリケーション完了を待つためです。演習環境など1台のDCしかない環境では即時使用できますが、本番環境では事前に作成しておいてください。

作成後は以下で確認できます。

# KDSルートキーの確認
Get-KdsRootKey

EffectiveTimeが現在時刻より過去になっていれば使用可能です。

gMSAアカウントを作成する

KDSルートキーが準備できたら、gMSAアカウントを作成します。

# gMSAアカウントを作成する
New-ADServiceAccount `
    -Name "svc_webapp_gmsa" `
    -DNSHostName "svc-webapp.nlab.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "WebServers" `
    -Description "Webアプリ用gMSAアカウント"

各パラメーターの意味を整理します。

パラメーター	説明
`-Name`	gMSAのアカウント名（`$`が自動付与される）
`-DNSHostName`	サービスのFQDN（SPNに使われる）
`-PrincipalsAllowedToRetrieveManagedPassword`	パスワードを取得できるグループまたはコンピューター
`-Description`	用途の説明（管理のために必ず記載する）

-PrincipalsAllowedToRetrieveManagedPasswordには、このgMSAを使うサーバーが所属するADグループを指定します。

利用するサーバーに使用権限を付与する

gMSAを使うサーバーを事前にADグループに追加します。

# gMSAを使うサーバーを格納するグループを作成する
New-ADGroup -Name "WebServers" -GroupScope Global -GroupCategory Security

# グループにサーバーを追加する
Add-ADGroupMember -Identity "WebServers" -Members "WEB01$", "WEB02$"

コンピューターオブジェクトを追加する際は、コンピューター名の末尾に$を付けることを忘れないでください。

グループへの追加後、サーバー側でグループポリシーを更新します。

# サーバー側でグループポリシーを更新する（対象サーバー上で実行）
gpupdate /force

# gMSAアカウントをローカルに登録する（対象サーバー上で実行）
Install-ADServiceAccount -Identity "svc_webapp_gmsa"

# 登録が正常に完了したか確認する（対象サーバー上で実行）
Test-ADServiceAccount -Identity "svc_webapp_gmsa"

Test-ADServiceAccountがTrueを返せば正常に使用できる状態です。

gMSAをサービスに適用する

Windowsサービスへの適用手順

gMSAをWindowsサービスのログオンアカウントとして設定します。

GUIで設定する場合は、services.mscでサービス管理コンソールを開き、対象サービスを右クリック→「プロパティ」→「ログオン」タブ→「アカウント」を選択し、アカウント名にnlab\svc_webapp_gmsa$と入力（末尾に$）します。パスワード欄は空白のままでOKです。

PowerShellで設定する場合は以下の通りです。

# サービスのログオンアカウントをgMSAに変更する
$serviceName = "MyWebService"
$gmsaAccount = "nlab\svc_webapp_gmsa$"

Set-Service -Name $serviceName -Credential (
    New-Object System.Management.Automation.PSCredential(
        $gmsaAccount,
        (New-Object System.Security.SecureString)
    )
)

gMSAを使う場合、パスワードは空（New-Object System.Security.SecureString）で問題ありません。ADが自動で管理するためです。

適用後の動作確認

# サービスを再起動して動作確認する
Restart-Service -Name "MyWebService"

# サービスの状態を確認する
Get-Service -Name "MyWebService" | Select-Object Name, Status, StartType

# gMSAのパスワード取得状態を確認する（DC上で実行）
Get-ADServiceAccount -Identity "svc_webapp_gmsa" -Properties * |
    Select-Object Name, PasswordLastSet, PrincipalsAllowedToRetrieveManagedPassword

サービスが正常に起動しStatusがRunningになっていれば設定完了です。

現場でよくある設定ミス

KDSルートキー作成直後に使おうとして失敗する

Add-KdsRootKey -EffectiveImmediatelyを実行した直後にgMSAを作成・使用しようとすると「KDSルートキーが見つからない」エラーが出ます。本番環境では最大10時間の待機が必要です。事前準備として余裕を持って作成しておいてください。演習環境（DCが1台のみ）では即時使用できるため、この問題は発生しません。

DNS設定が不完全でgMSAが解決できない

-DNSHostNameに指定したFQDNがDNSで正しく解決できないと、gMSAの認証に失敗します。gMSA作成前にDNSレコードが正しく設定されているか確認してください。

グループメンバーシップの反映を待たずに使用する

サーバーをグループに追加した直後は、サーバー側のKerberosチケットにグループ情報が反映されていません。gpupdate /forceを実行してからサーバーを再起動するか、新しいKerberosチケットを取得するまで待つ必要があります。「設定したのに使えない」というトラブルの大半はこれが原因です。

gMSA非対応のサービスに無理に適用しようとする

サードパーティのアプリケーションや古いミドルウェアはgMSAに対応していない場合があります。その場合はgMSAへの移行を諦め、パスワードを30文字以上のランダムな文字列にして定期的にローテーションする運用で対処してください。

チェックリスト

事前準備の確認

[ ] KDSルートキーが作成されており、EffectiveTimeが過去になっている
[ ] gMSAを使うサーバーをまとめるADグループが作成されている
[ ] DNSにgMSAのFQDNレコードが登録されている

gMSA作成・設定の確認

[ ] New-ADServiceAccountでgMSAが正常に作成されている
[ ] 対象サーバーがPrincipalsAllowedToRetrieveManagedPasswordに含まれるグループのメンバーになっている
[ ] 対象サーバー上でInstall-ADServiceAccountが完了している
[ ] Test-ADServiceAccountがTrueを返している

動作確認

[ ] サービスがRunning状態で正常起動している
[ ] ローテーション後もサービスが正常に動作することを確認した（30日後）
[ ] gMSAアカウントの用途・適用サービスを管理台帳に記録している

まとめ

ドメイン内のサービスアカウント一覧を確認し、gMSAに移行できるものを特定してください。

# SPNが設定されているサービスアカウントを一覧表示する
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} `
    -Properties ServicePrincipalName, PasswordLastSet |
    Select-Object Name, PasswordLastSet, ServicePrincipalName

このコマンドで表示されたアカウントがKerberoastingの標的になりえます。パスワードの最終更新日が古いアカウントから優先的にgMSAへの移行を検討してください。

gMSAへの移行はサービスアカウントのセキュリティを根本から改善する最善策です。設定の手間はありますが、一度移行してしまえばパスワード管理の負担がゼロになります。

次のステップとして、ローカル管理者アカウントの自動パスワード管理にはLAPSが有効です。「ハッシュ攻撃への多層防御」として、gMSA・LAPS・Credential Guardの3つを組み合わせることで、攻撃者が横展開に使える認証情報を大幅に減らせます。