保护组托管服务帐户Securing group managed service accounts

组托管服务帐户 (gMSA) 是用于保护服务的托管域帐户。Group managed service accounts (gMSAs) are managed domain accounts that are used for securing services. gMSA 可以在单个服务器上运行,也可以在服务器场中运行,例如网络负载均衡器 (NLB) 后面的系统或 Internet Information Services (IIS) 服务器。gMSAs can run on a single server, or in a server farm, such as systems behind a Network Load Balancer (NLB) or an Internet Information Services (IIS) server. 将服务配置为使用 gMSA 主体后,该帐户的密码管理将由 Windows 处理。Once you configure your services to use a gMSA principal, password management for that account is handled by Windows.

使用 gMSA 的好处Benefits of using gMSAs

gMSA 提供一个单一标识解决方案,该解决方案通过以下方式提高了安全性,同时又降低了管理开销:gMSAs offer a single identity solution with greater security while reducing administrative overhead by:

  • 设置强密码Setting strong passwords. gMSA 使用 240 字节随机生成的复杂密码。gMSAs use 240 byte randomly generated complex passwords. gMSA 密码的复杂性和长度最大程度地降低了服务受到暴力破解或字典攻击的可能性。The complexity and length of gMSA passwords minimizes the likelihood of a service getting compromised by brute force or dictionary attacks.

  • 定期轮换密码Cycling passwords regularly. gMSA 将密码管理工作移交给 Windows,后者每 30 天更改一次密码。gMSAs shift password management to Windows, which changes the password every 30 days. 服务和域管理员不再需要计划密码更改或管理服务中断,以确保服务帐户安全。Service and domain administrators no longer need to schedule password changes or manage service outages to keep service accounts secure.

  • 支持部署到服务器场Supporting deployment to server farms. 通过允许将 gMSA 部署到多个服务器,可支持多个主机运行同一服务的负载均衡解决方案。The ability to deploy gMSAs to multiple servers allows for the support of load balanced solutions where multiple hosts run the same service.

  • 支持简化的服务器主体名称 (SPN) 管理Supporting simplified Server Principal Name (SPN) management. 你可以在创建帐户时使用 PowerShell 设置 SPN。You can set up SPN using PowerShell at the time of account creation. 另外,如果正确设置了 gMSA 权限,那么,支持自动 SPN 注册的服务可能会对 gMSA 执行此操作。In addition, services that support automatic SPN registrations may do so against the gMSA, provided gMSA permissions are correctly set.

何时使用 gMSAWhen to use gMSAs

将 gMSA 用作本地服务的首选帐户类型,除非服务(比如故障转移群集)不支持它。Use gMSAs as the preferred account type for on-premises services unless a service, such as Failover Clustering, doesn't support it.


在部署到生产环境之前,必须使用 gMSA 测试服务。You must test your service with gMSAs prior to deployment into production. 为此,请设置测试环境,确保应用程序可以使用 gMSA 并且可以访问需要访问的资源。To do so, set up a test environment and ensure the application can use the gMSA, and access the resources it needs to access. 有关详细信息,请参阅对组托管服务帐户的支持For more information, see Support for group managed service accounts.

如果某项服务不支持使用 gMSA,那么你的下一个最佳选择是使用独立的托管服务帐户 (sMSA)。If a service doesn't support the use of gMSAs, your next best option is to use a standalone Managed Service Account (sMSA). sMSA 提供与 gMSA 相同的功能,但仅用于单个服务器上的部署。sMSAs provide the same functionality as a gMSA, but are intended for deployment on a single server only.

如果你不能使用 gMSA 或者你的服务支持 sMSA,则必须将服务配置为以标准用户帐户的身份运行。If you can't use a gMSA or sMSA is supported by your service, then the service must be configured to run as a standard user account. 服务和域管理员必须遵守强密码管理流程,以确保帐户安全。Service and domain administrators are required to observe strong password management processes to keep the account secure.

评估 gMSA 的安全状况Assess the security posture of gMSAs

gMSA 本质上比标准用户帐户更安全,因为它需要进行持续的密码管理。gMSAs are inherently more secure than standard user accounts, which require ongoing password management. 但是,在审视 gMSA 的整体安全状况时,必须考虑 gMSA 的访问范围。However, it's important to consider gMSAs' scope of access as you look at their overall security posture.

下表显示了使用 gMSA 的潜在安全问题和缓解措施。The following table shows potential security issues and mitigations for using gMSAs.

安全问题Security issues 缓解措施Mitigations
gMSA 是特权组的成员。gMSA is a member of privileged groups. 评审组成员身份。Review your group memberships. 为此,你可以创建一个 PowerShell 脚本来枚举所有组成员身份,然后按 gMSA 文件的名称筛选生成的 CSV 文件。To do so you can create a PowerShell script to enumerate all group memberships, and then filter a resultant CSV file by the names of your gMSA files.
从特权组中删除 gMSA。Remove the gMSA from privileged groups.
仅向 gMSA 授予运行服务所需的权限(咨询服务供应商)。Grant the gMSA only the rights and permissions it requires to run its service (consult with your service vendor).
gMSA 对敏感资源具有读/写访问权限。gMSA has read/write access to sensitive resources. 审核对敏感资源的访问。Audit access to sensitive resources. 将审核日志存档到 SIEM(例如,Azure Log Analytics 或 Azure Sentinel)进行分析。Archive audit logs to a SIEM, for example Azure Log Analytics or Azure Sentinel, for analysis. 如果检测到不适当级别的访问,请删除不必要的资源权限。Remove unnecessary resource permissions if an undesirable level of access is detected.

查找 gMSAFind gMSAs

你的组织可能已经创建 gMSA。Your organization may already have gMSAs created. 运行以下 PowerShell cmdlet 可检索这些帐户:Run the following PowerShell cmdlet to retrieve these accounts:

为了有效地执行此操作,gMSA 必须位于托管服务帐户组织单位 (OU) 中。To work effectively, gMSAs must be in the Managed Service Accounts organizational unit (OU).

托管服务帐户 OU 的屏幕截图。

若要查找可能不在其中的服务 MSA,请参阅以下命令。To find service MSAs that may not be there, see the following commands.

若要查找所有服务帐户,包括 gMSA 和 sMSA,请运行以下命令:To find all service accounts, including gMSAs and sMSAs:

Get-ADServiceAccount -Filter *

# This PowerShell cmdlet will return all Managed Service Accounts (both gMSAs and sMSAs). An administrator can differentiate between the two by examining the ObjectClass attribute on returned accounts.

# For gMSA accounts, ObjectClass = msDS-GroupManagedServiceAccount

# For sMSA accounts, ObjectClass = msDS-ManagedServiceAccount

# To filter results to only gMSAs:

Get-ADServiceAccount -Filter * | where $_.ObjectClass -eq "msDS-GroupManagedServiceAccount"}

管理 gMSAManage gMSAs

可以使用以下 Active Directory PowerShell cmdlet 来管理 gMSA:You can use the following Active Directory PowerShell cmdlets for managing gMSAs:









从 Windows Server 2012 开始,*-ADServiceAccount cmdlet 默认用于 gMSA。Beginning with Windows Server 2012, the *-ADServiceAccount cmdlets work with gMSAs by default. 有关使用上述 cmdlet 的详细信息,请参阅 组托管服务帐户入门For more information on usage of the above cmdlets, see Getting Started with Group Managed Service Accounts.

迁移到 gMSAMove to a gMSA

gMSA 是可以满足本地需求的最安全的服务帐户类型。gMSAs are the most secure type of service account for on-premises needs. 如果可以迁移到 gMSA,就应该迁移。If you can move to one, you should. 此外,请考虑将服务迁移到 Azure,将服务帐户迁移到 Azure Active Directory。Additionally, consider moving your services to Azure and your service accounts to Azure Active directory.

  1. 确保将 KDS 根密钥部署到林中Ensure that the KDS Root Key is deployed in the forest. 这是一次性操作。This is a one-time operation.

  2. 创建一个新的 gMSACreate a new gMSA.

  3. 在运行服务的每个主机上安装新的 gMSA。Install the new gMSA on each host running the service.


    若要详细了解在将服务配置为使用 gMSA 之前,如何在主机上创建和安装 gMSA,请参阅组托管服务帐户入门For more information on creation and installation of gMSA on a host, prior to configuring your service to use gMSA, see Getting Started with Group Managed Service Accounts

  4. 将服务标识更改为 gMSA 并指定一个空白密码。Change your service identity to gMSA and specify a blank password.

  5. 验证服务是否在新的 gMSA 标识下运行。Validate that your service is working under the new gMSA identity.

  6. 删除旧的服务帐户标识。Delete the old service account identity.

后续步骤Next steps

参阅以下文章,了解如何保护服务帐户See the following articles on securing service accounts