组托管服务帐户概览
传统做法是将普通用户帐户用作服务帐户，这会把密码管理的负担加到用户身上。结果是，帐户密码往往会多年保持不变——从而使其高度容易受到暴力破解攻击和滥用的影响。组托管服务帐户（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 密码有两条途径：
- 确保只有必要的对象获得查询密码的权限，并且这些对象存在于 msDS-GroupMSAMembership 中。
- 确保只有需要访问的管理员用户以及安装了 gMSA 的计算机帐户才有权限读取该属性。此外，还要确保只有管理员具备修改 gMSA 及其属性的能力，以便任何人都无法将自己添加到 msDS-GroupMSAMembership 属性中。
理想情况下，你应该通过两条途径同时对 gMSA 进行加固，以阻止攻击者具备利用上述任一情景的可能性。下面我们将说明：gMSA 上权限或配置管理不当，可能会导致该账号被攻破，并且 权限提升 或横向移动。
滥用 gMSA 密码
滥用 gMSA 从概念上来说相对简单。首先，可以使用类似 Mimikatz 的工具获取其密码，或者由于 Active Directory 中存在不安全的配置而直接查询它。由于 gMSA 是服务账号，它们通常拥有相对较高的权限，因此接下来你往往就能够进行横向移动或权限提升。
精心挑选的相关内容：
让我们通过一个示例场景来说明。
1. 首先，我们通过诸如钓鱼（phishing）之类的技术来攻破普通的 Windows 用户账户“notadmin”。该账户在 Active Directory 中的权限很有限，但在我们已入侵到的那台机器上却是本地管理员。
2. 接下来，我们将尝试查明是否存在任何 gMSA。如果你有权限访问 Windows PowerShell cmdlet，就很容易做到。运行一个简单的脚本即可获取 Active Directory 中的所有托管服务账户：
Get-ADServiceAccount -Filter *
3. 对脚本做一些轻微的修改后，我们就可以确定谁有权限查询 gMSA 密码：
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword
正如我们所看到的，只有 Kevin Joyce 账户能够查询这些服务账户的密码：
4. 我们可以通过检查这些服务账户是否属于任何特权组来缩小我们要锁定的目标范围；然后再进一步深入查看其中某个对象上配置了哪些权限：
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 服务帐户身份运行的 shell，那么我们就可以随心所欲地入侵并破坏 Active Directory。我们可以采用的最快方法之一，但可能也是最“惹眼/最吵”的方式，就是执行 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 编辑，我们可以看到，高亮显示的 GUID 对应的是 msDS-ManagedPasssword 属性。
假设你可能具备某种形式的事件日志转发，或 SIEM 解决方案，那么这些日志对于确定是谁在访问这些属性将极其有价值。
Netwrix StealthDEFEND
另一个选项是类似 Netwrix StealthDEFEND 的工具。Netwrix StealthDEFEND 不依赖原生事件日志，并且可以开箱即用地检测 gMSA 密码访问以及高风险权限分配。例如，当 ‘notadmin’ 帐户查询密码时，上述场景将生成以下威胁：
此外，借助 Netwrix StealthDEFEND，您可以轻松构建一个播放本（playbook），用于在检测到 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，gMSAs）是用于帮助保护服务和进行访问管理的托管域帐户。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 cmdlet 创建组托管服务帐户（Group managed service accounts）。
gMSA 的对象权限决定该自动化是否保持安全。当普通账户拥有对控制密码检索的属性的写入权限时，它可以授予自己读取凭据的权限，然后以服务身份的现有权限操作，包括该账户拥有的任何特权组成员身份。
那个权限往往是坚固部署与整个域被攻破之间的唯一屏障。
服务账户是非人类身份，根据Netwrix 2026 Data and Identity Security Report，76%的组织未能完全管理或监控它们。组管理的服务账户将密码从人工手中移除，但任何能够重写哪些主体可以检索密码的人仍然可以接管该身份。
什么是组管理服务帐户（gMSA）？
gMSA 的工作原理
gMSA 的密码在每个使用它的主机上都遵循相同的序列。
- 每个域控制器上的Key Distribution Service (KDS)保存用于计算域中每个gMSA密码的密钥。
组管理服务帐户是一个托管的Active Directory domain帐户，用于运行服务、应用程序和计划任务。Windows 会生成随机密码并自动轮换，授权主机在运行时从 Active Directory 获取凭据，因此管理员无需知道密码或将其存储在文件中。
- 主机还会检索之前的密码，在轮换传播的短暂窗口期间保持身份验证正常工作。
gMSA不适用于Windows Server 2012之前的Windows操作系统，因此运行gMSA的每台主机都需要Windows Server 2012或更高版本。gMSA支持跨多台计算机的单一服务身份，而独立托管服务帐户支持单台计算机，普通用户帐户则将密码管理留给管理员。
- 由于每个授权主机都以相同的域主体进行身份验证，gMSA 还简化了跨主机共享身份的服务的 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)，它将传统的服务账户迁移到具有托管随机密钥的机器账户，并将认证绑定到设备身份。
无人需要管理的强密码
将普通用户账户用作服务账户，会将密码的生成、分发和轮换交给管理员，密码保持不变，直到有人进行轮换。gMSA 用域管理的生成和检索取代了这种手动生命周期。
密码仍需传达到每个主机，因此主机授权和主机安全成为凭据保护的一部分。
跨服务器群的统一身份
支持相互认证的身份验证协议（如Kerberos）要求农场托管服务的每个实例使用相同的主体。gMSA为所有成员主机提供一个域主体，管理员可集中管理其权限，无需在主机间同步密码。
减少暴力破解和滥用的风险
gMSA 使用 Windows 每30天更改的随机生成的240字节密码，防止暴力破解或字典攻击导致的风险。管理员配置账户及其授权主机，且从不处理密码，因此服务可以获得强大的凭据，而无需任何人将其复制到脚本、部署说明或配置文件中。
Windows 服务、IIS 应用程序池和计划任务可以作为 gMSA 运行，微软的 Kerberoasting 指南中也提到了 SQL Server。应用程序支持仍然是部署要求，因此在投入生产前，请在 gMSA 下测试每个服务。
针对Kerberoasting的更安全默认设置
自动生成消除了人工选择密码的步骤，自动轮换消除了在每个服务主机上更新静态凭据的重复任务。除非服务无法使用，否则微软建议在本地服务中使用gMSA。
剩余的责任是访问治理，因为能够更改密码检索授权的人可以在从未参与密码生成的情况下获取凭据。
Kerberoasting 允许拥有任何域账户的攻击者请求服务票证并离线破解服务账户的密码，因此密码强度决定攻击是否成功。
Microsoft的Kerberoasting指南 将弱密码账户列为最脆弱，并建议尽可能使用gMSA或dMSA，因为生成的密码消除了该技术依赖的人为弱点。
如何安全地设置 gMSA
Netwrix Threat Manager检测混合环境中的凭证盗窃、横向移动和权限提升。请求演示。
1. 检查要求
在部署gMSA之前，请确认域、主机、管理和应用程序的要求。
使用明确的授权主机列表创建账户，然后在每个主机上安装并验证它。
- 域和林功能级别设置为Windows Server 2012或更高版本，微软表示支持所有设备的gMSA功能。
- 运行 Windows Server 2012 或更高版本的主机。
- 管理系统上的Active Directory PowerShell模块，运行gMSA cmdlets需要64位架构。
- 可供域控制器使用的 KDS 根密钥。
- Domain Admins 或 Enterprise Admins 成员资格，或委派权限以创建
msDS-GroupManagedServiceAccount对象。 - 支持gMSA的服务，例如Windows服务、IIS应用程序池或计划任务。
将 gMSA 的创建委托给专门的管理组，并将服务身份本身排除在管理组之外。
2. 创建 KDS 根密钥
3. 使用 New-ADServiceAccount 创建 gMSA
故障转移群集不支持gMSA，但运行在Cluster服务上的服务如果是Windows服务、应用程序池或计划任务，或本身支持gMSA，则可以使用gMSA。Kerberos也必须端到端工作，因此请为每个服务注册SPN，保持DNS记录和时钟准确，并允许相关系统之间的Kerberos流量。
尽管参数名称为 -EffectiveImmediately，但不会跳过复制。其他域控制器在复制完成前无法使用该密钥，且微软的密钥创建流程要求域控制器在允许创建gMSA前最多等待10小时，因此在生产环境中请预留此时间窗口。
4. 在每个主机上安装并测试gMSA
为服务的主机计算机帐户创建专用安全组，然后使用 New-ADServiceAccount 创建 gMSA，并在 PrincipalsAllowedToRetrieveManagedPassword 中命名其 DNS 主机名和安全组。Microsoft 要求 gMSA 名称在整个林中唯一，而不仅仅是在域中。
在创建之前，请检查林中是否已有KDS根密钥，因为该密钥是一次性的林级先决条件。请在Windows Server 2012或更高版本的域控制器上使用 Add-KdsRootKey -EffectiveImmediately，然后确认KDS事件日志中的事件ID 4004。
5. 配置服务以作为 gMSA 运行
如果部署需要，请在创建时使用 -ManagedPasswordIntervalInDays 设置自定义密码间隔，因为该间隔只能在创建时设置。记录账户的应用所有者和预期主机以及部署配置，并按照“Limit who can retrieve the password”说明，排除一般服务器管理组和包含普通用户的组。
请单独测试每个成员服务器，因为一个服务器的成功结果并不代表另一个服务器的组成员身份或连接性。在更改生产服务的登录身份之前，请先解决验证失败的问题。
通过服务控制管理器、IIS 应用程序池身份设置或计划任务配置设置服务的登录身份，并将密码留空。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显示哪些主体可以读取每个账户的密码。
在实验室结果中，只有一个管理账户可以查询密码，因此 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
一个过于宽泛的权限，即对一个gMSA对象的Full Control，使攻击从一个普通被攻破的账户扩展到了整个域的凭据伪造。
Golden gMSA 攻击通过不同路径访问 gMSA 的密码，相关内容见 gMSA exploitation 页面。
同时保护gMSA的检索授权、对象权限和服务权限。
- 使用恢复的凭据，攻击者通过 pass-the-hash 认证为 gMSA，并以该服务身份启动进程，继承该身份拥有的所有权限。
限制谁可以检索密码
限制谁可以更改gMSA
- 由于实验室的gMSA属于Domain Admins，攻击者可以利用其复制权限对DCSync攻击
krbtgt账户执行操作。该账户的凭据材料为域内所有Kerberos票据签名，因此恢复它后，攻击者可以伪造任何用户的票据。
将gMSA排除在特权组之外
通常，只有运行该服务的计算机账户应检索其 gMSA 密码。对于多服务器部署，请使用包含这些计算机账户的专用安全组，通过 PrincipalsAllowedToRetrieveManagedPassword 进行配置，并在服务的主机列表更改时审查其成员资格。
仅向需要管理账户的管理员授予写入权限，并检查每个gMSA上的完全控制、写入所有属性以及特定属性的写入权限。具有修改 msDS-GroupMSAMembership 权限的主体可以授权其自身密码的检索，这正是上述操作指南所利用的错误配置。
仅授予每个gMSA其服务所需的权限。gMSA可以属于Domain Admins，但该成员身份会使任何获得其凭据的人拥有整个域的管理员权限，微软的缓解指南建议审查服务账户权限并移除过度访问。
强制执行AES加密
通过两条权限路径保护账户。限制 msDS-GroupMSAMembership 属性所代表的主体，并限制对 gMSA 对象本身的目录访问，特别是修改账户或其检索授权的权限。
检查直接的组成员资格及嵌套组授予的有效权限，并在移除权限前记录应用程序所需的访问权限，以便服务所有者验证修订后的配置。
运行 Windows Server 2025 的域控制器将不再发放 RC4 票据授权票据，因此依赖 RC4 的旧设备无法进行身份验证。
查找并审核每个 gMSA
Microsoft 正在默认逐步淘汰 RC4 Kerberos 加密，不仅仅是建议不要使用。2022 年的更新已经将任何未明确配置加密类型的账户的默认加密类型更改为 Advanced Encryption Standard (AES)-SHA1。
检查每个 gMSA 的 msDS-SupportedEncryptionTypes 属性，并确认它包含 AES，而不是依赖域的回退默认值，因为微软正是要移除该回退。
启用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，手动审查检索权限和审计日志就无法扩展。这三款Netwrix产品涵盖了账户的管理访问，检测凭证滥用，并持续提供哪些账户仍持有过度权限的可见性。
使用 Uninstall-ADServiceAccount 从其以前的主机中删除未使用的 gMSA。主机卸载和目录帐户的删除是独立的生命周期操作。删除 AD 对象之前，请确认所有依赖的工作负载已迁移或退役，并作为同一变更的一部分，删除过时的主机授权和相关资源权限。
检测异常的服务账户行为
通过Netwrix Privilege Secure，该地区通过临时账户即时授予访问权限，任务完成后即被移除，并在几天内而非数月内为其关键系统实施了Privileged Access Management。
Netwrix Privilege Secure 用临时的任务范围账户替代对特权对象（如gMSA）的持续访问。 Eastern Carver County Schools 发现红队通过过度且不必要的特权访问反复进入关键系统。
查找权限过多且过期的服务账户
Netwrix Threat Manager检测混合环境中的凭据盗窃、横向移动和权限提升。调查这些检测，以发现对服务身份（如gMSA）的滥用，其中攻击者使用被盗的托管密码进行身份验证，并行使该身份的现有权限。
将自动轮换与严格的检索权限配对
Netwrix Access Analyzer 解析嵌套组成员身份并分析Active Directory对象的有效权限，其报告还标记了过时的受托账户。利用这些发现审查gMSA检索和对象权限，识别清理候选项。
自动密码轮换和严格的检索权限是两个独立的控制，gMSA只有在两者都有效时才安全。上面的演示显示了当只有一个权限失效时会发生什么：一个普通的被攻破账户继承了Domain Admin凭证，并伪造整个域的票据，且密码从未被破解或猜测。
将权限审查视为定期工作，而非一次性设置步骤，因为每个新主机、每次组成员变更和每次服务迁移都可能重新打开相同的路径。
请求演示，了解 Netwrix Privilege Secure 如何移除对特权账户的持续访问，Netwrix Threat Manager 如何检测服务账户滥用，以及 Netwrix Access Analyzer 如何识别权限过高的账户。
关于保护您的组管理服务帐户的常见问题
分享到
了解更多
关于作者
