服务账号的口令困境
Windows 服务常以某个域账号运行，而静态服务口令面临两个现实问题：很少有人定期轮换，且口令必须存放在某处供服务读取。组托管服务账号（gMSA）把这件事交给 AD：口令由域控自动生成并周期轮换，服务在启动时直接向域控读取，管理员无需保管也不需要知道口令。前提是服务支持读取托管口令，且请求方主机已被授权。
基本信息
| 适用平台 | Windows Server（Active Directory 2012 及以后） |
|---|---|
| 创建命令 | New-ADServiceAccount、Install-ADServiceAccount、Test-ADServiceAccount |
| 授权方式 | PrincipalsAllowedToRetrieveManagedPassword 指定可读取口令的主机或组 |
| 替代方案 | 非域场景可用 LAPS 管理本地服务账号口令 |
| 风险等级 | 中 |
典型使用场景
- Web 与中间件服务：把运行账号从静态口令迁移到 gMSA
- 数据库服务账号：减少口令人工维护与轮换遗漏
- 批量任务与计划任务：以 gMSA 身份运行，避免口令写在脚本里
- 合规整改：针对“服务账号口令未定期更换”的整改项
- 审计准备：证明服务账号口令由系统自动轮换
创建与盘点
创建与盘点
New-ADServiceAccount -Name 'svc-web' -DNSHostName 'svc-web.corp.example.com' -PrincipalsAllowedToRetrieveManagedPassword 'WebServers$'
Install-ADServiceAccount -Identity 'svc-web' # 在需要运行服务的主机上安装
Test-ADServiceAccount -Identity 'svc-web' # 验证本机可读取托管口令
Get-ADServiceAccount -Filter * | Select-Object Name, DNSHostName, Enabled
Get-CimInstance Win32_Service | Where-Object {$_.StartName -like '*\*'} | Select-Object Name, StartName, StartMode | Sort-Object StartName核查项读法
| 项 | 含义 | 正常与异常 |
|---|---|---|
| StartName | 服务运行身份 | 普通域账号=静态口令风险；gMSA 结尾带 $ |
| StartMode | 启动方式 | Automatic 但身份为普通账号需重点核查 |
| PrincipalsAllowedToRetrieveManagedPassword | 允许读取口令的主机 | 范围过宽等于口令面扩大 |
| Test-ADServiceAccount 结果 | 主机是否能读取口令 | 失败说明授权或部署有误 |
| 口令轮换周期 | 由 AD 自动管理 | 无需人工介入，避免忘记轮换 |
域外场景或应用不支持读取托管口令时不适用 gMSA：可退化用 LAPS 管理本地服务账号口令，并制定轮换流程。
落地要点
- 迁移前先确认应用是否支持以托管账号运行，部分老程序只接受账号加口令的输入方式
- 授权主机范围最小化：只给确实需要运行服务的主机读取权限
- 先在测试环境验证服务可正常启动，再迁移生产
- 把服务账号清单纳入台账：哪些仍是静态口令、轮换周期如何
- 域控备份还原后验证 gMSA 服务可用性，避免同步问题导致服务启动失败
备份还原域控可能带来托管口令的同步问题：恢复后要逐个验证使用 gMSA 的服务能否正常启动。