Windows Server 2025 引入了委派托管服务账户 (dMSA) 功能，旨在解决传统服务账户在安全性方面的潜在风险。本文将概述 dMSA，介绍其特性，并提供账户迁移指南。
服务账户类型概览
在深入探讨 dMSA 之前，让我们先来回顾一下 Windows Server 的不同类型服务账户，这有助于管理员更好地理解整体概念。
传统服务账户
传统 Windows 服务账户（SA）是一种用户账户，用于 Windows 服务与操作系统及网络资源之间的交互。这些账户为服务提供必要的权限和安全上下文，使其能够在无需管理员直接干预的情况下运行并完成预定任务。
然而，传统服务账户存在以下几个主要问题：
- 需要手动管理密码。
- Windows 管理员可能会设置「密码永不过期」来简化管理，但这会带来较大的安全隐患。
- 更改服务账户的密码可能会导致依赖该账户的服务停止运行，需要及时更新服务中的密码设置。
- 容易受到凭证收割攻击，如 Kerberoasting。攻击者可以向密钥分发中心 (KDC) 请求票据授予服务 (TGS) 票据，进而尝试离线破解票据中的会话密钥，或冒充服务账户访问其他网络资源。
托管服务账户
托管服务账户 (MSA)，也被称为独立托管服务账户 (sMSA)，是在 Active Directory 中管理的账户，用于在特定的服务器上运行服务。它通过自动管理密码降低了维护负担，但由于无法在多台服务器间共享，仍然会给管理员带来运维挑战。
组托管服务账户
组托管服务账户 (gMSA) 也是一种 AD 管理的账户，它将 MSA 的功能扩展到了多台服务器。非常适合负载均衡或集群环境，因为服务可能需要在多台服务器之间进行故障转移或分布。
尽管 MSA 和 gMSA 比传统服务账户更安全，但它们仍然无法完全抵御凭证收割攻击。
委派托管服务账户 (dMSA)
委派托管服务账户 (dMSA) 能帮助组织从传统服务账户过渡到更安全的 gMSA 系账户。dMSA 具有以下几个关键特性：
- 支持多台服务器。
- 自动管理密码。
- 密钥与机器身份绑定，并通过凭证保护器提供强有力的保护，有效抵御凭证收割攻击。
- 密钥仅通过 Kerberos 获取，密码不会传递给客户端，也不会在使用 dMSA 的本地存储。
- 协助管理员从传统服务账户迁移。
- 使用传统服务账户的目标服务无需进行任何更改，因为所有事务均由域控制器处理。
使用 dMSA 的前提条件
在开始使用委派托管服务账户 (dMSA) 之前，需要满足以下条件：
- 管理员权限： 拥有域管理员权限。
- 服务器要求：
- 目前只有 Windows Server 2025 支持创建 dMSA。
- Active Directory 中至少需要一台 Windows Server 2025 域控制器。
- 兼容性说明： 目前只有 Windows 11 24H2 和 Windows Server 2025 支持 dMSA 登录。其他 Windows 版本暂不支持此功能。
- 客户端设置： 在客户端设备上，需要启用「计算机配置」>「管理模板」>「系统」>「Kerberos」>「启用委派的托管服务账户登录」组策略设置。
启用委派的托管服务账户登录策略
启用 Kerberos 日志记录（可选步骤）
启用 Kerberos 日志记录可以帮助你更好地理解在配置 dMSA 过程中发生了什么。请在使用 dMSA 的服务器或客户端上执行：
1使用Windows + R快捷键打开「运行」对话框，输入eventvwr打开「事件查看器」。
2展开「应用程序和服务日志」>「Microsoft」>「Windows」>「Security-Kerberos」。
3右键点击「Operational」，选择「启用日志」。
启用 Kerberos 安全操作日志
如何迁移到 dMSA
从传统服务账户迁移到委派托管服务账户 (dMSA) 的过程如下：
成员服务器准备工作
1以管理员权限启动 PowerShell 并安装 Active Directory 远程服务器管理工具 (RSAT)：
Install-WindowsFeature -Name RSAT-AD-Tools
2检查并设置密钥分发服务 (KDS) 根密钥，确保机器身份信息的安全：
- 检查是否存在根密钥：
Get-KdsRootKey
- 如果返回为空，创建新的根密钥：
Add-KdsRootKey -EffectiveImmediately
创建 dMSA
3使用以下命令创建一个新的 dMSA，用于替代现有的传统服务账户：
New-ADServiceAccount -Name -DNSHostName -CreateDelegatedServiceAccount -KerberosEncryptionType AES256
创建一个新的 dMSA 账户
初始状态下，msDS-DelegatedMSAState值为0表示未链接状态，PrincipalsAllowedToRetrieveManagedPassword为空。
查看 dMSA 链接状态
启动服务账户迁移
4使用以下命令，启动服务账户的迁移程序，服务账户会尝试刷新票据授予票据 (TGT)：
Start-ADServiceAccountMigration -Identity -SupersededAccount "Superseded-Service-Distinguished-Name"
开始服务账户迁移
这个请求会被重定向到本地安全机构 (LSA)，LSA 负责将服务账户映射到新创建的 dMSA。我们可以看到 dMSA 属性变化：
msDS-DelegatedMSAState变为1。msDS-ManagedAccountPrecededByLink指向原服务账户。
查看 dMSA 链接状态变化和指向
- 原服务账户的
msDS-SupersededManagedAccountLink和msDS-ManagedAccountPrecededByLinkBL指向了新的 dMSA。
查看原服务账户指向
重启服务并完成迁移
5手动重启目标服务，系统会将机器身份添加到 dMSA 的PrincipalsAllowedToRetrieveManagedPassword属性中，这样 dMSA 就能继承原服务账户的所有访问权限和权限设置。管理员可以通过以下命令查看 dMSA 的属性：
Get-ADServiceAccount -Identity -Properties PrincipalsAllowedToRetrieveManagedPassword
查看 dMSA 属性
6执行以下命令确认并完成迁移：
Complete-ADServiceAccountMigration -Identity -SupersededAccount
确认并完成迁移
迁移完成后，原服务账户将被禁用，目标服务将继续正常运行，无需额外更改。
迁移完成后，原服务账户会被禁用
迁移完成后，目标服务正常运行
其他有用命令
- 在确认完成迁移前，可撤销操作：
Undo-ADServiceAccountMigration -Identity -SupersededAccount - 或重置到未链接状态：
Reset-ADServiceAccountMigration -Identity -SupersededAccount 查看事件日志
我们还可以通过 Event Log 中的 Kerberos 日志来了解 dMSA 迁移事件，其中：
- 事件 ID 307：表示 dMSA 迁移开始。
- 事件 ID 308：表示机器已添加到 PrincipalsAllowedToRetrieveManagedPassword 属性。
- 事件 ID 309：表示 Kerberos 客户端从域控制器获取了 dMSA 密钥。
