Windows Server 2025：委派托管服务账户（dMSA）简介

Windows Server 2025 引入了委派托管服务账户 (dMSA) 功能，旨在解决传统服务账户在安全性方面的潜在风险。本文将概述 dMSA，介绍其特性，并提供账户迁移指南。

服务账户类型概览

在深入探讨 dMSA 之前，让我们先来回顾一下 Windows Server 的不同类型服务账户，这有助于管理员更好地理解整体概念。

传统服务账户

传统 Windows 服务账户（SA）是一种用户账户，用于 Windows 服务与操作系统及网络资源之间的交互。这些账户为服务提供必要的权限和安全上下文，使其能够在无需管理员直接干预的情况下运行并完成预定任务。

然而，传统服务账户存在以下几个主要问题：

• 需要手动管理密码。
• Windows 管理员可能会设置「密码永不过期」来简化管理，但这会带来较大的安全隐患。
• 更改服务账户的密码可能会导致依赖该账户的服务停止运行，需要及时更新服务中的密码设置。
• 容易受到凭证收割攻击，如 Kerberoasting。攻击者可以向密钥分发中心 (KDC) 请求票据授予服务 (TGS) 票据，进而尝试离线破解票据中的会话密钥，或冒充服务账户访问其他网络资源。

托管服务账户

托管服务账户 (MSA)，也被称为独立托管服务账户 (sMSA)，是在 Active Directory 中管理的账户，用于在特定的服务器上运行服务。它通过自动管理密码降低了维护负担，但由于无法在多台服务器间共享，仍然会给管理员带来运维挑战。

组托管服务账户

组托管服务账户 (gMSA) 也是一种 AD 管理的账户，它将 MSA 的功能扩展到了多台服务器。非常适合负载均衡或集群环境，因为服务可能需要在多台服务器之间进行故障转移或分布。

委派托管服务账户 (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」，选择「启用日志」。

如何迁移到 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 <dMSA-Name> -DNSHostName <dMSA-FQDN> -CreateDelegatedServiceAccount -KerberosEncryptionType AES256

初始状态下，msDS-DelegatedMSAState值为0表示未链接状态，PrincipalsAllowedToRetrieveManagedPassword为空。

启动服务账户迁移

4使用以下命令，启动服务账户的迁移程序，服务账户会尝试刷新票据授予票据 (TGT)：

Start-ADServiceAccountMigration -Identity <dMSA-Name> -SupersededAccount "Superseded-Service-Distinguished-Name"

这个请求会被重定向到本地安全机构 (LSA)，LSA 负责将服务账户映射到新创建的 dMSA。我们可以看到 dMSA 属性变化：

• msDS-DelegatedMSAState变为1 。
• msDS-ManagedAccountPrecededByLink指向原服务账户。

• 原服务账户的msDS-SupersededManagedAccountLink和msDS-ManagedAccountPrecededByLinkBL指向了新的 dMSA。

重启服务并完成迁移

5手动重启目标服务，系统会将机器身份添加到 dMSA 的PrincipalsAllowedToRetrieveManagedPassword属性中，这样 dMSA 就能继承原服务账户的所有访问权限和权限设置。管理员可以通过以下命令查看 dMSA 的属性：

Get-ADServiceAccount -Identity <dMSA-Name> -Properties PrincipalsAllowedToRetrieveManagedPassword

6执行以下命令确认并完成迁移：

Complete-ADServiceAccountMigration -Identity <dMSA-Name> -SupersededAccount <Superseded-Service-Distinguished-Name>

迁移完成后，原服务账户将被禁用，目标服务将继续正常运行，无需额外更改。

其他有用命令

• 在确认完成迁移前，可撤销操作：

Undo-ADServiceAccountMigration -Identity <dMSA-Name> -SupersededAccount <Superseded-Service-Distinguished-Name>

• 或重置到未链接状态：

Reset-ADServiceAccountMigration -Identity <dMSA-Name> -SupersededAccount <Superseded-Service-Distinguished-Name>

查看事件日志

我们还可以通过 Event Log 中的 Kerberos 日志来了解 dMSA 迁移事件，其中：

• 事件 ID 307：表示 dMSA 迁移开始。
• 事件 ID 308：表示机器已添加到 PrincipalsAllowedToRetrieveManagedPassword 属性。
• 事件 ID 309：表示 Kerberos 客户端从域控制器获取了 dMSA 密钥。