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」,选择「启用日志」。
如何迁移到 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 密钥。
最新评论
需要管理员权限
直接降级 Windows10 一次性永久解决问题
我按照作者的方法成功了
使用PowerShell修改失败,禁止访问