グループ管理サービスアカウントの概要
従来の慣行として、通常のユーザーアカウントをサービスアカウントとして使用すると、パスワード管理の負担がユーザーにのしかかります。その結果、アカウントのパスワードが何年もの間同じ状態のままになりやすくなり、ブルートフォース攻撃や不正使用に対して非常に脆弱になります。グループ管理サービスアカウント（gMSAs）は、自動化タスク、サービス、アプリケーションをより安全に実行するための方法を提供します。
gMSA は Windows Server 2016 で導入され、Windows Server 2012 以降で活用できます。gMSA のパスワードは Windows によって完全に管理されます。パスワードはランダムに生成され、自動的にローテーションされます。さらに、サービス アカウント自体が、パスワード情報を問い合わせるサーバーに「インストール」されるため、どのユーザーもパスワードを知っている必要はありません。 Active Directory を実行時に参照します。その結果、gMSA は、サービス アカウントとして使用されるユーザー アカウントよりも、誤用や侵害（コンプロマイズ）に対してはるかに影響を受けにくくなっています。
グループ管理サービスアカウントのセキュリティ
gMSA は Active Directory の特定のオブジェクト タイプです。msDS-GroupManagedServiceAccount となります。これらのオブジェクトには、パスワードとそのローテーションに関連する特別な属性が付いています。 LAPS と同様に、gMSA の属性が、それらにアクセスする必要がある Active Directory のオブジェクトのみに対してロックされていることを確認してください。
gMSA の属性と権限
gMSA には次の属性があります：
- msDS-ManagedPassword— gMSA のパスワードを含む BLOB
- msDS-ManagedPasswordID— 現在の gMSA パスワードを生成するために使用されるキー ID
- msDS-ManagedPasswordPreviousID— 以前の gMSA パスワードを生成するために使用されるキー ID
- msDS-GroupMSAMembership— gMSA のパスワードを照会する権限を持つオブジェクトの一覧
- msDS-ManagedPasswordInterval— パスワードをローテーション（変更）する間隔（日数）
パスワード情報は msDS-ManagedPassword 属性に保存されているため、環境内で誰がパスワードを照会できるのかは必ず把握しておきたいところです。この情報は msDS-GroupMSAMembership 属性で設定されます。
ただし、これはその属性だけでは少し複雑です。Active Directory の権限が関係してくるためです。何らかの理由で、ユーザーまたはオブジェクトが msDS-GroupMSAMembership アカウント経由でパスワードを照会するための権限を持つように設定されていたとしても、gMSA の msDS-ManagedPassword 属性に対する「Read」権限がそれでも必要になります。
つまり、gMSA のパスワードを保護する方法には 2 つの手段があります。
- 必要なオブジェクトだけがパスワードを照会するための権限を持つようにし、それらが msDS-GroupMSAMembership に存在することを確認してください。
- アクセスが必要な管理ユーザーと、gMSA がインストールされているコンピューター アカウントだけが、その属性を読み取るための権限を持つようにしてください。また、gMSA およびその属性を変更できるのは管理者だけにし、誰も msDS-GroupMSAMembership 属性に自分を追加できないようにしてください。
理想的には、攻撃者が上記のいずれかのシナリオを悪用する選択肢を持てないように、gMSA を2つの経路の両方でしっかりとロックダウンします。以下では、gMSA 上の権限や設定が適切に管理されていない場合に、アカウントが侵害され、 権限昇格 または横方向への移動につながる仕組みを説明します。
gMSA のパスワードの悪用
gMSA を悪用すること は、概念的には比較的シンプルです。まず、Mimikatz のようなツールを使ってパスワードを取得するか、Active Directory の設定が不適切であるために直接クエリを実行して取得します。gMSA はサービスアカウントなので、通常は比較的権限が高いです。そのため、その後は多くの場合、横方向への移動や権限昇格が可能になります。
厳選した関連コンテンツ：
例のシナリオを順を追って見ていきましょう。
1. まずは、フィッシングのような手法を使って通常の Windows ユーザー アカウント「notadmin」を侵害します。このアカウントは Active Directory 内では最小限の権限しか持っていませんが、侵入した先のマシンではローカル管理者です。
2. 次に、gMSA が存在するかどうかを調べます。Windows PowerShell cmdlet にアクセスできるなら、これは非常に簡単です。単純なスクリプトを実行すると、Active Directory 内のすべての管理対象サービス アカウントが取得できます：
Get-ADServiceAccount -Filter *
3. スクリプトを少しだけ変更することで、gMSA のパスワードを照会できるのが誰かを特定できます：
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
ご覧のとおり、これらのサービス アカウントのパスワードを照会できるのは Kevin Joyce アカウントだけです：
4. これらのサービス アカウントがいずれかの特権グループのメンバーであるかどうかを確認することで、狙いたいターゲットの範囲を絞り込めます。そこから、オブジェクトの1つに設定されている権限をさらに掘り下げることができます：
Get-ADServiceAccount -Filter * -Properties memberof
ここでの結果を見ると、gMSA サービス アカウントが Domain Admins のメンバーであることが分かります。したがって、こちらを悪用の対象として試します。
5. Microsoft LAPS に関する投稿で提供されているスクリプトを修正することで、特定の gMSA 属性に対して、完全制御（Full Control）、すべてのプロパティを書き込む（Write All Properties）、またはプロパティを書き込む（Write Property）の権限を含む、マネージド サービス アカウントに対する権限を持つすべてのオブジェクトの一覧を取得できました。出力結果は以下のとおりで、スクリプトへのリンクは末尾にあります。
6. ご覧のとおり、notadmin アカウントには gMSA アカウントに対する完全制御（Full Control）権限があります。これにより msDS-GroupMSAMembership 属性を変更できるようになり、マネージド サービス アカウントのパスワードを取得できるようになります：
Set-ADServiceAccount -Identity gmsa -PrincipalsAllowedToRetrieveManagedPassword notadmin
7. パスワードを実際に照会できるようになったので、これで何ができるのかを見てみましょう：
Get-ADServiceAccount -Identity gmsa -properties msds-ManagedPassword
$pwd = Get-ADServiceAccount -identity gMSA -Properties msds-ManagedPassword
8. 属性に保存されている値は、パスワードそのものではなく、パスワードのデータを含む BLOB です。そのため、DSInternals のようなツールを使ってパスワードをデコードする必要があります：
$pw = ConvertFrom-ADManagedPasswordBlob $pwd.’msds-managedpassword’
ConvertTo-NTHash $pw.securecurrentpassword
これで SecureCurrentPassword と CurrentPassword を取得できます。CurrentPassword は役に立たないように見えますが、これはすべての文字が UTF-16 だからです。SecureCurrentPassword は NTLM ハッシュに変換でき、パス・ザ・ハッシュ攻撃（pass the hash） に使って、mimikatz で権限を昇格できます。
9. パス・ザ・ハッシュ（pass the hash） を行うには、mimikatz を実行してこのコマンドを使うだけです:
sekurlsa::pth /user:gmsa /domain:sbpmlab.net /ntlm:a99afa608b79a3c539a969212c505ea9
10. いま、Domain Admins のメンバーであった gMSA サービス アカウントとしてシェルが実行できているので、Active Directory を侵害するために好きなことが何でもできます。その中でも最も早い方法の1つですが、おそらくは最も目立つ（ノイジーな）やり方の1つは、DCSync 攻撃を実行して、krbtgt アカウントのハッシュを盗むことです:
lsadump::dcsync /user:krbtgt /domain:sbpmlab.net
gMSA の保護と監視
gMSA の悪用を防止し、検出するために使える戦略があります。
権限
最も明白で、ある意味でおそらく最も重要な防御策は、グループ管理サービスアカウント（group managed service accounts）に適切な権限が設定されていることを確認することです。これらのオブジェクトに対して誰が書き込みアクセスを持っているかを理解することは、それらを保護するうえで重要です。理屈の上では、パスワードを照会できる相手を制御する属性に自分を追加できる人は、すでにそのアカウントを乗っ取り、その特権を悪用するためのアクセス権を持っていることになります。
次に行うべきことは、これらのアカウントのパスワードを照会できる能力を持つのが誰なのか、そしてそのようなアクセスを必要とするのが誰なのかを正確に把握することです。実際には、gMSA のパスワードを取得できるべき唯一のアカウントは、その gMSA がインストールされているコンピューターアカウントだけです。
イベント ログ
ネイティブのイベント ログで探せるイベントがあり、それによって、gMSA アカウントのパスワードを誰が照会しているのかを特定するのに役立ちます。ドメインに対して「Audit directory service access」ポリシーを有効化し、監視したい gMSA に SACL を設定すると、人が msDS-ManagedPassword 属性を照会したときにイベント ログを生成できます：
この設定を有効にして新しい SACL を作成すると、イベント ID 4662 のイベント ログが生成されます。見た目は次のとおりです:
ご覧のとおり、ログには ‘notadmin’ アカウントが gMSA アカウント上のプロパティを読み取ったことが記録されています。読み取られたプロパティは Active Directory のスキーマに保存されている GUID ですが、ADSI Edit を使うと、ハイライトされている GUID が msDS-ManagedPasssword 属性に解決されることがわかります。
何らかのイベント ログ転送、または SIEM ソリューションを利用している場合、これらのログは、誰がこれらの属性にアクセスしているのかを特定するうえで非常に貴重です。
Netwrix StealthDEFEND
もう一つの選択肢は Netwrix StealthDEFEND のようなツールです。 Netwrix StealthDEFEND はネイティブのイベント ログに依存せず、gMSA パスワードへのアクセスや高リスクの権限付与をすぐに検出できます。たとえば、上に示したシナリオでは、 ‘notadmin’ アカウントがパスワードを照会したときに、次の脅威が生成されます:
さらに、Netwrix StealthDEFEND を使用すると、gMSA の悪用が検出されたときに実行するプレイブックを簡単に作成できます。プレイブックには、犯人のユーザー アカウントに MFA リクエストへ応答させること、アカウントを無効化すること、または ServiceNow インシデントを作成するといった複数のステップを含めることができます。
付録
gMSA 権限コード：
<#
Author: Kevin Joyce
Requirements: Active Directory PowerShell module, Domain Administrator privileges (to ensure the capability to get attribute GUIDs and view all permissions on all gMSA objects)
Description: Looks up permissions within Active Directory on a gMSA to determine access to modify the gMSA attribute (ms-ds-GroupMSAMembership).
Usage: populate the $target variable with the samaccountname of a gMSA.
To output the results to a text file run the following .gMSA_Permissions_Collection.ps1 > output.txt
#>
Import-Module ActiveDirectory
##Get the GUID of the extended attribute ms-ds-GroupMSAMembership from Schema
$schemaIDGUID = @{}
Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter '(name=ms-ds-GroupMSAMembership)' -Properties name, schemaIDGUID |
ForEach-Object {$schemaIDGUID.add([System.GUID]$_.schemaIDGUID,$_.name)}
<# **REPLACE DN VARIABLE BELOW**
Declare the samaccountname of the gMSA to search for#>
$target = 'gmsa'
##Get distinguished name of all gMSAs objects from the OU
$gMSAs = Get-ADServiceAccount -identity $target
<#Get objects that have specific permissions on the target(s):
Full Control(GenericAll)
Write all Properties (WriteProperty where ObjectType = 00000000-0000-0000-0000-000000000000
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access |
Where-Object { (($_.AccessControlType -eq 'Allow') -and ($_.activedirectoryrights -in ('GenericAll') -and $_.inheritancetype -in ('All', 'None')) -or (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -eq '00000000-0000-0000-0000-000000000000')))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -autosize
}
<#Get objects that have specific permissions on the target(s) and specifically the gMSA attribute:
WriteProperty
#>
Set-Location ad:
foreach ($gmsa in $gMSAs){
(Get-Acl $gmsa.distinguishedname).access |
Where-Object {(($_.AccessControlType -eq 'Allow') -and (($_.activedirectoryrights -like '*WriteProperty*') -and ($_.objecttype -in $schemaIDGUID.Keys)))} |
ft ([string]$gmsa.name),identityreference, activedirectoryrights, objecttype, isinherited -AutoSize
}
生の内容を表示gMSA_Permissions_Collection.ps1 によりホストされています GitHub
よくある質問
gMSA とは？
管理サービス アカウント（Managed Service Accounts：MSA）と同様に、グループ管理サービス アカウント（Group Managed Service Accounts：gMSA）は、サービスやアクセス管理を保護するために使用される管理対象のドメイン アカウントです。gMSA の機能により、ドメイン コントローラー（DC）による自動パスワード管理、サービス プリンシパル名（Service Principal Name：SPN）の管理の簡素化、さらに管理を他の管理者に委任できるため、 Active Directory のセキュリティ が向上し、特権アクセスを持つアカウントを最小限に抑えます。
MSA と gMSA の違いは何ですか？
MSA と異なり、gMSA は複数のコンピューターに関連付けることができます。
グループ管理サービス アカウントを見つけるには？
ドメイン コントローラー上の gMSA の一覧を取得するには、Server Manager > Tools > Active Directory Users and Computers > Managed Service Accounts を開きます。
gMSA は Domain Admin になれますか？
はい。gMSA アカウントは Domain Admins のメンバーにできますが、この運用は情報セキュリティ上危険になり得ます。
gMSA を作成するにはどうすればよいですか？
グループ管理サービス アカウントは、New-ADServiceAccount コマンドレットで作成します。
gMSAのオブジェクト権限は、その自動化が安全に保たれるかどうかを決定します。通常のアカウントがパスワード取得を制御する属性への書き込みアクセス権を持っている場合、その資格情報を読み取る権限を自分に付与し、サービスIDの既存の権利およびアカウントが持つ特権グループのメンバーシップを含めて行動できます。
その1つの権限が、堅牢な展開とドメイン全体の侵害の間に立つ唯一のものとなることが多いです。
サービスアカウントは非人間の識別子であり、組織の76％がそれらを完全に管理または監視していないと、Netwrix 2026 Data and Identity Security Reportによると報告されています。グループ管理サービスアカウントはパスワードを人の手から取り除きますが、どのプリンシパルがそれを取得できるかを書き換えられる人は、依然としてその識別子を乗っ取ることができます。
グループ管理サービスアカウント（gMSA）とは何ですか？
gMSAの仕組み
gMSAのパスワードは、それを使用するすべてのホストで同じシーケンスをたどります。
- 各ドメインコントローラーのKey Distribution Service（KDS）は、ドメイン内のすべてのgMSAのパスワードを計算するために使用される秘密を保持しています。
グループ管理サービスアカウントは、管理されたActive Directory domainアカウントで、サービス、アプリケーション、およびスケジュールされたタスクの実行に使用されます。Windowsはランダムなパスワードを生成し自動的にローテーションし、認可されたホストは実行時にActive Directoryから資格情報を取得するため、管理者はパスワードを知る必要もファイルに保存する必要もありません。
- ホストは前のパスワードも取得し、ローテーションが伝播する短い間、認証を維持します。
gMSAはWindows Server 2012より前のWindowsオペレーティングシステムには適用されないため、Windows Server 2012以降が必要です。gMSAは複数のコンピューターで1つのサービスIDをサポートしますが、スタンドアロンの管理サービスアカウントは1台のコンピューターのみをサポートし、通常のユーザーアカウントはパスワード管理を管理者に任せます。
- すべての認可されたホストが同じドメインプリンシパルとして認証されるため、gMSAは複数のホストでIDを共有するサービスのService Principal Name（SPN）管理も簡素化します。
- Windowsはデフォルトで30日ごとにパスワードを自動で変更し、ホスト側で事前通知や手動の介入は必要ありません。
- 認可されたホストがドメインコントローラーに連絡し、その秘密から計算された現在のパスワードを実行時に取得し、ローカルに保存しません。
gMSA とその他のサービスアカウントタイプの比較
これらの属性は一緒に、ホストにパスワードの取得方法を伝え、msDS-GroupMSAMembership は攻撃者が書き換える必要があるもので、下のウォークスルーで悪用される誤設定です。
Active DirectoryはオブジェクトクラスmsDS-GroupManagedServiceAccountを持つgMSAを表し、これらのスキーマ属性はパスワードと取得制御を保存します。
Windowsは複数のプリンシパルを提供します サービスの実行用で、それぞれ異なるサービスをサポートし、パスワードを異なる方法で管理します。アプリケーションの認証要件と展開モデルに応じてアカウントタイプを選択してください。
sMSAとは異なり、gMSAは複数のコンピューターで共有できるため、サーバーファームやロードバランスサービスに適しています。どちらもWindowsとActive Directoryがパスワード管理を行う管理サービスアカウントです。
gMSAが重要な理由
Microsoftは、gMSAのパスワードはマシン生成で自動的にローテーションされるがマシンに紐付けられていないため、侵害されたホストから読み取られる可能性があり、gMSAを直接dMSAに移行できないと指摘しています。
Windows Server 2025 は delegated managed service account (dMSA) を追加し、従来のサービスアカウントを管理されたランダムキー付きのマシンアカウントに移行し、認証をデバイスのIDに結びつけます。
誰も管理する必要のない強力なパスワード
通常のユーザーアカウントをサービスアカウントとして使用すると、パスワードの生成、配布、ローテーションが管理者の手に委ねられ、誰かがローテーションするまでパスワードは変更されません。gMSAはその手動のライフサイクルをドメイン管理の生成と取得に置き換えます。
パスワードは各ホストに届く必要があるため、ホストの認証とホストのセキュリティが資格情報保護の一部となります。
サーバーファーム全体での一つのアイデンティティ
Kerberosなどの相互認証をサポートする認証プロトコルでは、ファームホストサービスのすべてのインスタンスが同じプリンシパルを使用する必要があります。gMSAはすべてのメンバーホストに1つのドメインプリンシパルを提供し、管理者はホスト間でパスワードを同期することなく権限を集中管理します。
ブルートフォース攻撃や誤用のリスクを軽減
gMSAは、Windowsが30日ごとに変更するランダムに生成された240バイトのパスワードを使用し、ブルートフォース攻撃や辞書攻撃による侵害リスクを最小限に抑えます。管理者はアカウントと承認されたホストを設定し、パスワードを扱うことはないため、サービスはスクリプトや展開ノート、設定ファイルにパスワードをコピーすることなく強力な認証情報を取得します。
Windowsサービス、IISアプリケーションプール、およびスケジュールされたタスクはgMSAとして実行でき、MicrosoftのKerberoastingガイダンスではSQL Serverも挙げられています。アプリケーションのサポートは展開要件のままなので、本番環境に移行する前に各サービスをgMSAでテストしてください。
Kerberoastingに対するより安全なデフォルト設定
自動生成によりパスワードの選択が人の手から除かれ、自動ローテーションによりすべてのサービスホストで静的な資格情報を更新する繰り返し作業がなくなります。Microsoftは、サービスが使用できない場合を除き、オンプレミスのサービスにgMSAを推奨しています。
残された責任はアクセスガバナンスです。パスワード取得の権限を変更できる人は、パスワード生成に関与せずに資格情報を取得できるためです。
Kerberoasting は、任意のドメインアカウントを持つ攻撃者がサービスチケットを要求し、サービスアカウントのパスワードをオフラインで解析できるため、パスワードの強度が攻撃の成功を左右します。
MicrosoftのKerberoastingガイダンスは 弱いパスワードのアカウントを最も脆弱とし、可能な限りgMSAまたはdMSAの使用を推奨しています。生成されたパスワードは、人間が選んだ弱点を排除するためです。
gMSAを安全に設定する方法
Netwrix Threat Managerは、ハイブリッド環境全体での資格情報の盗難、横移動、および権限昇格を検出します。デモをリクエストしてください。
1. 要件を確認してください
gMSAを展開する前に、ドメイン、ホスト、管理、およびアプリケーションの要件を確認してください。
許可されたホストの明示的なリストでアカウントを作成し、各ホストにインストールして検証します。
- ドメインおよびフォレストの機能レベルがWindows Server 2012以降に設定されており、MicrosoftによるとすべてのデバイスでgMSA機能をサポートしています。
- Windows Server 2012以降を実行しているホスト。
- 管理システム上のActive Directory PowerShellモジュールで、gMSAコマンドレットを実行するには64ビットアーキテクチャが必要です。
- ドメインコントローラーで利用可能なKDSルートキー。
- Domain Admins または Enterprise Admins のメンバーシップ、または作成の委任権限
msDS-GroupManagedServiceAccountオブジェクト。 - Windowsサービス、IISアプリケーションプール、またはスケジュールされたタスクなど、gMSAをサポートするサービスです。
gMSA の作成を専用の管理グループに委任し、サービスの識別自体を管理グループから除外してください。
2. KDSルートキーを作成します
3. New-ADServiceAccountでgMSAを作成します
フェイルオーバークラスターはgMSAをサポートしていませんが、クラスタサービス上で動作するサービスがWindowsサービス、アプリケーションプール、またはスケジュールタスクである場合、またはgMSAをネイティブにサポートしている場合は、gMSAを使用できます。Kerberosもエンドツーエンドで機能する必要があるため、各サービスのSPNを登録し、DNSレコードと時計を正確に保ち、関係するシステム間でKerberosトラフィックを許可してください。
パラメーター名にもかかわらず、-EffectiveImmediately はレプリケーションをスキップしません。他のドメインコントローラーはキーがレプリケートされるまで使用できず、Microsoftのキー作成手順ではドメインコントローラーがgMSAの作成を許可する前に最大10時間待機するため、本番環境ではその時間を考慮してください。
4. 各ホストにgMSAをインストールしてテストします
サービスのホストコンピューターアカウント用に専用のセキュリティグループを作成し、次に New-ADServiceAccount で gMSA を作成し、DNS ホスト名とセキュリティグループを PrincipalsAllowedToRetrieveManagedPassword に指定します。Microsoft は gMSA 名がドメインではなくフォレスト全体で一意であることを要求しています。
キーを作成する前に、フォレストに既にKDSルートキーがあるか確認してください。このキーはフォレストレベルで一度だけ必要な前提条件です。Windows Server 2012以降のドメインコントローラーで Add-KdsRootKey -EffectiveImmediately を実行し、その後イベントID 4004 がKDSイベントログに記録されていることを確認してください。
5. サービスをgMSAとして実行するように構成します
デプロイに必要な場合は、作成時に -ManagedPasswordIntervalInDays でカスタムパスワード間隔を設定します。間隔は作成時にのみ設定可能です。アカウントのアプリケーション所有者と対象ホストをデプロイ構成と共に記録し、「Limit who can retrieve the password」で説明されているように、一般的なサーバー管理グループおよび通常のユーザーを含むグループは取得パラメーターから除外してください。
各メンバーサーバーを個別にテストしてください。あるサーバーで成功しても、別のサーバーのグループメンバーシップや接続状況については何も示しません。本番サービスのログオンIDを変更する前に、検証失敗を解決してください。
サービスのログオンIDをService Control Manager、IISアプリケーションプールのID設定、またはスケジュールされたタスクの構成で設定し、パスワードは空欄のままにします。Windowsが管理された資格情報を取得します。
攻撃者がgMSAパスワードを悪用する方法
アカウントに必要なアプリケーションの権限を付与し、サービスの起動と依存リソースへのアクセスの両方を確認してください。アカウントテストの合格は資格情報の準備ができていることのみを証明するため、ワークロードには引き続きファイル、データベース、その他のリソース権限が必要です。
各ホストのコンピューターアカウントをセキュリティグループに追加し、次に Install-ADServiceAccount を実行し、その後 Test-ADServiceAccount をすべての承認されたホストで実行します。Test-ADServiceAccount はホストがパスワードを取得できることを検証します。
以下のラボでは、notadminという通常のアカウントと、誤って構成された特権付きgMSAを使用しています。ドメイン名とアカウント名はその例の環境に属します。
gMSA とそれを読める人を見つける
攻撃者は許可された経路または安全でないActive Directoryの権限を通じてgMSAパスワードを取得し、そのアカウントの既存の権限で認証できます。gMSAの悪用は、管理された資格情報に対して異なるルートを取るGolden gMSA攻撃を含む、より広範な攻撃クラスをカバーします。
- Active Directory PowerShell モジュールが利用可能な場合、攻撃者は次のコマンドで管理対象サービスアカウントを列挙します
Get-ADServiceAccount -Filter *.
特権付きの gMSA と侵入経路を見つける
- プロパティ
PrincipalsAllowedToRetrieveManagedPasswordを要求すると、各アカウントのパスワードを読み取れるプリンシパルが表示されます。
ラボの結果では、管理アカウントが1つだけパスワードを照会できるため、notadmin はまだそれらを読むことができません。攻撃者がgMSAオブジェクトを変更できるユーザーを調べる際に、この構成が重要になります。
- 攻撃者はサービスアカウントが特権グループに属しているかどうかを
memberOfプロパティを照会して確認します。
ラボのgMSAはDomain Adminsに属しているため、攻撃者はそれを選択します。既存のメンバーシップが後のステップに必要な権限を提供します。
パスワードを取得して復号化する
- オブジェクトの権限を確認すると、パスワード取得承認属性に対してフルコントロール、すべてのプロパティの書き込み、またはプロパティの書き込みアクセス権を持つプリンシパルが特定されます。これは、Microsoft LAPSの投稿で説明された方法を適用したスクリプトを使用しています。以下の「Find and audit every gMSA」の権限スクリプトも同じチェックを実行します。
- ラボでは、
notadminは gMSA オブジェクトに対してフルコントロール権限を持っており、Set-ADServiceAccountを使って自分自身をPrincipalsAllowedToRetrieveManagedPasswordに追加できます。
エスカレーションにパスワードを使用する
- この属性はパスワード自体ではなくパスワードデータを含むBLOBを保持しているため、攻撃者はこれをDSInternalsでデコードし、現在および以前のパスワード値を公開し、現在のパスワードをNTハッシュに変換できます。
- 攻撃者はフィッシングなどの手法で
notadminを侵害します。このアカウントは最小限のActive Directory権限を持っていますが、local administrator rightsを侵害されたマシンで保持しています。 - 変更後、
notadminはmsDS-ManagedPassword属性をクエリして返されたオブジェクトを保存できます。
gMSAを保護する方法
1つの過度に広範な権限、gMSAオブジェクトに対するFull Controlが、通常の侵害されたアカウントからドメイン全体の資格情報偽造への攻撃をもたらしました。
Golden gMSA攻撃は異なる経路でgMSAのパスワードに到達し、gMSA exploitation ページで説明されています。
gMSAの取得許可、オブジェクト権限、およびサービス特権をまとめて保護します。
- 回復した資格情報を使って、攻撃者は pass-the-hash によりgMSAとして認証し、サービスIDの下でプロセスを開始し、そのIDが持つ権限をすべて継承します。
パスワードを取得できるユーザーを制限する
gMSAを変更できるユーザーを制限する
- ラボのgMSAがDomain Adminsに属しているため、攻撃者はその複製権限を使ってDCSync攻撃を
krbtgtアカウントに対して実行できます。そのアカウントの資格情報はドメイン内のすべてのKerberosチケットに署名しているため、これを回収すると攻撃者は任意のユーザーのチケットを偽造できます。
gMSAを特権グループから除外する
サービスを実行するコンピューターアカウントのみが通常、そのgMSAパスワードを取得する必要があります。マルチサーバー展開の場合は、それらのコンピューターアカウントを含む専用のセキュリティグループを使用し、PrincipalsAllowedToRetrieveManagedPasswordを介して設定し、サービスのホストリストが変更されるたびにメンバーシップを確認してください。
アカウントを管理する必要がある管理者にのみ書き込みアクセスを許可し、すべてのgMSAに対してフルコントロール、すべてのプロパティの書き込み、および属性固有の書き込み権限を確認してください。 msDS-GroupMSAMembershipを変更する権限を持つプリンシパルは、自身のパスワード取得を許可でき、これは上記の手順が悪用する誤設定そのものです。
各gMSAには、そのサービスに必要な権限のみを付与してください。gMSAはDomain Adminsに属することがありますが、そのメンバーシップは資格情報を取得した者にドメイン全体の管理者権限を与え、Microsoftの緩和ガイダンスではサービスアカウントの権限を見直し、過剰なアクセスを削除することを推奨しています。
AES暗号化を適用する
両方の権限パスを通じてアカウントを保護します。属性 msDS-GroupMSAMembership が表すプリンシパルを制限し、特にアカウントの変更や取得権限を含むgMSAオブジェクト自体へのディレクトリアクセスを制限します。
直接のグループメンバーシップとネストされたグループが付与する有効な権限を確認し、権限を削除する前にアプリケーションに必要なアクセスを文書化して、サービス所有者が修正された構成を検証できるようにしてください。
Windows Server 2025を実行するドメインコントローラーは、RC4のチケット発行を一切行わなくなるため、RC4に依存するレガシーデバイスは認証できません。
すべての gMSA を検索して監査する
MicrosoftはデフォルトでRC4 Kerberos暗号化を段階的に廃止しています。単に推奨しないだけでなく、2022年のアップデートで明示的な暗号化タイプが設定されていないアカウントのデフォルト暗号化タイプがAdvanced Encryption Standard (AES)-SHA1に変更されました。
各 gMSA の msDS-SupportedEncryptionTypes 属性を確認し、ドメインのフォールバックのデフォルトに依存せずに AES が含まれていることを確認してください。Microsoft が削除しようとしているのはまさにそのフォールバックです。
AESサポートを有効にして新しいキーを生成した後、アカウントのパスワードをリセットし、その後認証をテストしてください。RC4のみを使用しているgMSAは、単に弱い暗号で動作するのではなく、Kerberos認証を完全に失う可能性があります。
パスワード読み取りを監視する
元のスクリプト: gMSA_Permissions_Collection.ps1.
結果のイベントは、対象アカウント、ターゲットディレクトリオブジェクト、およびアクセスされたプロパティを特定します。
以下の権限スクリプトは、gMSAのmsDS-GroupMSAMembership 属性に対してフルコントロールまたはプロパティ書き込みアクセス権を持つアカウントを報告します。上記の手順5のチェックは攻撃者側から実行されます。管理者は、権利を保持すべきユーザーを決定する際に、継承、グループメンバーシップ、および実効アクセスを確認する必要があります。
次のコマンドで管理対象サービスアカウントを列挙します Get-ADServiceAccount -Filter *、次に ObjectClass が msDS-GroupManagedServiceAccount のオブジェクトにフィルターして、gMSAとスタンドアロンの管理サービスアカウントを区別します。
使用しなくなったgMSAを削除してください
監査ディレクトリサービスアクセス ポリシーを有効にし、gMSA にシステムアクセス制御リスト (SACL) を構成して監視すると、イベント ID 4662 がプリンシパルによって msDS-ManagedPassword を読み取るたびに生成されます。
プロパティ識別子はイベント内でスキーマGUIDとして表示され、ADSI Editは関連するGUIDを解決して、それが msDS-ManagedPassword に対応していることを確認できます。
ドメインコントローラのログをセキュリティ情報およびイベント管理（SIEM）システムに転送し、アカウントの承認されたサービスホストとパスワード読み取りを比較し、予期しないユーザーやコンピューターによる取得を調査します。
NetwrixがgMSAのセキュリティを支援する方法
gMSA 管理を保護する
環境に数個以上のgMSAがある場合、手動で取得権限や監査ログを確認するのはスケールしません。これら3つのNetwrix製品は、アカウントの管理アクセスをカバーし、資格情報の不正使用を検出し、過剰な権限を持つアカウントを継続的に可視化します。
未使用のgMSAを以前のホストから Uninstall-ADServiceAccount で削除します。ホストのアンインストールとディレクトリアカウントの削除は別々のライフサイクル操作です。ADオブジェクトを削除する前に、すべての依存ワークロードが移行または廃止されていることを確認し、同じ変更の一環として不要なホストの承認と関連リソースの権限を削除してください。
異常なサービスアカウントの動作を検出する
Netwrix Privilege Secureを使用して、地区は作業完了後に削除される一時アカウントを介して即時アクセスを付与し、重要システムに対して数か月ではなく数日でPrivileged Access Managementを導入しました。
Netwrix Privilege Secure は、gMSAなどの特権オブジェクトへの常時アクセスを、一時的なタスクスコープのアカウントに置き換えます。 Eastern Carver County Schools は、Red Teamsが過剰かつ不必要な特権アクセスを通じて重要なシステムに繰り返しアクセスするのを目撃しました。
権限が過剰で期限切れのサービスアカウントを見つける
Netwrix Threat Managerはハイブリッド環境全体での資格情報の窃盗、横移動、権限昇格を検出します。攻撃者が盗まれた管理パスワードで認証し、gMSAなどのサービスIDの既存の権利を行使しているかどうかを調査してください。
自動ローテーションと厳格な取得権限を組み合わせる
Netwrix Access Analyzerはネストされたグループメンバーシップを解決し、Active Directoryオブジェクトの有効な権限を分析します。また、レポートでは古くなったトラスティアカウントもフラグ付けします。これらの結果を使用して、gMSAの取得とオブジェクト権限を確認し、クリーンアップ候補を特定してください。
自動パスワードローテーションと厳格な取得権限は別々の制御であり、gMSAは両方が有効な場合にのみ安全です。上記の説明は、権限の一つだけが漏れた場合に何が起こるかを示しています。通常の侵害されたアカウントがDomain Adminの資格情報を継承し、パスワードを解読または推測されることなくドメイン全体のチケットを偽造します。
権限レビューは一度きりの設定作業ではなく、定期的な作業として扱ってください。新しいホスト、グループメンバーシップの変更、サービスの移行のたびに同じ経路が再び開かれる可能性があるためです。
デモをリクエストして、Netwrix Privilege Secureが特権アカウントへの常時アクセスを削除し、Netwrix Threat Managerがサービスアカウントの悪用を検出し、Netwrix Access Analyzerが過剰権限のアカウントを特定する方法をご覧ください。
グループ管理サービスアカウントのセキュリティに関するよくある質問
共有する
もっと詳しく
著者について
