委托托管服务帐户概述
Windows Server 2025 引入了一种名为委托托管服务帐户 (dMSA) 的新帐户类型，它支持从传统服务帐户迁移到具有托管与完全随机密钥的计算机帐户，同时禁用原始服务帐户密码。 针对 dMSA 的身份验证已链接到设备标识，因此只有 Active Directory (AD) 中已映射的指定计算机标识才能访问该帐户。 使用 dMSA 有助于阻止使用泄露的帐户 (kerberoasting) 来获取凭据，而这是传统服务帐户中存在的常见问题。
dMSA 与 gMSA 比较
dMSA 和 gMSA 是两种托管服务帐户，它们可用于在 Windows Server 中运行服务和应用程序。 dMSA 由管理员进行管理，并用于在特定服务器上运行服务或应用程序。 gMSA 由 AD 进行管理，并用于在多个服务器上运行服务或应用程序。 两者均可提高安全性并简化密码管理。 dMSA 的不同之处在于：
- 利用 gMSA 概念来限制使用 Credential Guard 以绑定计算机身份验证的使用范围。
- CG 可用于通过自动轮换密码并绑定所有服务帐户票证来增强 dMSA 的安全性。 然后，禁用旧帐户可进一步提高安全性。
- 虽然 gMSA 使用计算机生成并自动轮换的密码进行保护，但这些密码仍未绑定到计算机，且可能被盗。
dMSA 的功能
dMSA 允许用户将自身创建为独立帐户，或是替换现有的标准服务帐户。 当 dMSA 取代现有帐户时，会阻止使用现有帐户的密码对现有帐户进行身份验证。 该请求会重定向到本地安全机构 (LSA) 以使用 dMSA 进行身份验证，而该 dMSA 有权访问上一帐户可在 AD 中访问的所有内容。
迁移期间，dMSA 会自动获悉要在其上使用该服务帐户的设备，然后使用该帐户从所有现有服务帐户进行迁移。
dMSA 使用域控制器 (DC) 所持有的随机密钥（派生自计算机帐户凭据）来加密票证。 启用 CG 可进一步保护此密钥。 虽然 dMSA 使用的密钥会在 gMSA 等时期定期更新，但其中的关键区别在于，无法在 DC 以外的任何位置检索或发现 dMSA 的密钥。
dMSA 的迁移流程
dMSA 迁移流程的简略概念涉及以下步骤：
- 可配置 CG 策略以保护计算机标识。
- 管理员启动并完成服务帐户迁移。
- 服务帐户刷新票证授予服务器 (TGT)。
- 服务帐户添加计算机标识以允许执行原则。
- 原始服务帐户变为禁用状态。
迁移 dMSA 时，请注意以下事项：
- 无法从托管服务帐户或 gMSA 迁移到 dMSA。
- 完成 dMSA 迁移之前，在修改安全描述符 (SD) 后，请至少等待两个票证生存期（相当于 14 天）。 建议将服务的启动状态保持 4 个票证生存期（28 天）。 如果在载入期间要对 DC 进行分区或是复制中断，则请推迟此迁移。
- 请注意复制延迟时间超过默认票证续订时间（10 小时）的站点。 每次票证续订时，均会检查并更新 groupMSAMembership 属性；而每次原始服务帐户在“开始迁移”状态期间登录时，均会将此计算机帐户添加到 dMSA 的 groupMSAMembership。
- 例如，两个站点使用相同的服务帐户；而针对每个票证生存期，每个复制周期均需 10 小时以上。 在此场景中，组成员身份会在初始复制周期内丢失。
- 迁移时需访问读写域控制器 (RWDC) 以查询和修改 SD。
- 如果旧服务帐户正在使用不受约束的委派，则它会在迁移完成后停止工作。 如果使用的是受 CG 保护的 dMSA，不受约束的委派则会停止工作。 若要了解详细信息，请参阅使用 Credential Guard 时的注意事项和已知问题。
警告
若要迁移到 dMSA，则需更新使用此服务帐户的所有计算机以支持 dMSA。 如果并非如此，则此帐户在迁移期间变为禁用状态后，不支持 dMSA 的计算机将无法使用现有服务帐户进行身份验证。
dMSA 的帐户属性
本部分介绍 dMSA 的属性如何在 AD 架构中变化。 可使用 Active Directory 用户和计算机 管理单元或在 DC 上运行 ADSI Edit 来查看这些属性。
注意
为此帐户设置的数字属性表示：
- 1 - 帐户迁移已开始。
- 2 - 帐户迁移已完成。
运行 Start-ADServiceAccountMigration 将执行以下更改：
- 向服务帐户授予对 dMSA 上所有属性的泛型读取
- 为此服务帐户授予对 msDS-groupMSAMembership 的写属性
- msDS-DelegatedMSAState 变为 1
- msDS-ManagedAccountPrecededByLink 被设为服务帐户
- msDS-SupersedAccountState 变为 1
- msDS-SupersedManagedServiceAccountLink 被设为 dMSA
运行 Complete-ADServiceAccountMigration 将执行以下更改：
- 从服务帐户删除对 dMSA 上所有属性的泛型读取
- 服务帐户将从针对 msDS-GroupMSAMembership 属性的写属性中删除
- msDS-DelegatedMSAState 被设为 2
- 服务主体名称 (SPNs) 会从服务帐户复制到 dMSA 帐户
- 如果适用，则会复制 msDS-AllowedToDelegateTo
- 如果适用，则会复制安全描述符 msDS-AllowedToActOnBehalfOfOtherIdentity
- 复制服务帐户的已分配 AuthN 策略 msDS-AssignedAuthnPolicy
- 将 dMSA 添加到服务帐户所属的所有 AuthN 策略接收器
- 如果对服务帐户设置了受信任的“委派身份验证”用户帐户控制 (UAC) 位，则会复制该位
- msDS-SupersededServiceAccountState 被设为 2
- 通过 UAC 禁用位禁用此服务帐户
- 从帐户中删除 SPNs
dMSA 领域
领域充当定义身份验证边界的逻辑分组，通常在跨域或林集成不同版本的 AD 时使用。 它们在混合域环境中尤为重要，在这种环境中，某些域可能无法完全支持 dMSA 的所有功能。 通过指定领域，dMSA 可以确保域之间的正确通信和身份验证流。
管理员可以使用领域来指定哪些域或目录组件可以对 dMSA 帐户进行身份验证和访问。 这确保了即使是可能不支持 dMSA 功能的较旧子域，也可以在保持安全边界的同时与帐户进行交互。 通过在混合环境中实现更平滑的功能转换和共存，领域有助于确保兼容性，同时又不损害安全性。
例如，如果你在 Windows Server 2025 上运行一个名为 corp.contoso.com 的主域，在 Windows Server 2022 上运行一个名为 legacy.corp.contoso.com 的子域，则可以将领域指定为 legacy.corp.contoso.com。
要为环境编辑此组策略设置，请导航到以下路径：
Computer Configuration\Administrative Templates\System\Kerberos\Enable Delegated Managed Service Account logons
