服务主体名称（Service Principal Names，SPNs）是 Active Directory 中用于将服务实例映射到服务账户，以实现 Kerberos 身份验证的唯一标识符。本文将解释 SPN 的结构、注册方式、唯一性要求、工具（例如 setspn）以及安全影响。本文还涵盖诸如 Kerberoasting 之类的攻击、最佳实践、检测方法，以及混合、云和容器化环境中的高级用例。
服务主体名称（Service Principal Names，SPNs）简介
什么是 SPN？即使是对 Active Directory 有一定经验的 Windows 管理员，也可能不了解 Service Principal Names 在域环境中的作用。安全主体名称（security principal name，SPN）是一种唯一标识符，用于将特定服务实例与运行该服务的帐户关联起来，从而使客户端能够对 Active Directory (AD) 中的正确服务进行身份验证并建立连接。这在大型企业环境中特别重要，因为同一服务的多个实例可能运行在不同服务器上。本文将讨论什么是 Active Directory SPN，它对安全性的贡献是什么，以及在当今现代网络中它的用途如何持续扩大。
SPN 在 Kerberos 身份验证中的作用
就像乘坐飞机或进入电影院需要票一样，要访问 Active Directory (AD) 内的资源，也需要“票证”。当客户端请求访问托管在 AD 上的服务时，流程如下：
- 尝试使用某个服务的客户端为该服务创建 SPN
- 客户端使用该 SPN 向域控制器请求票证
- 域控制器会在 Active Directory 中搜索该 SPN
- 找到后，域控制器会颁发服务票据
- 客户端使用此票据来对服务进行身份验证，而无需密码
拆解基础概念
SPN 的组成部分
SPN 由多个组件构成，组合在一起后可为特定服务提供完整的标识：
- 服务类别：这是服务实例的名称，例如 Microsoft SQL Server 使用 “MSSQLSvc”，Web 服务使用 “www”。
- 主机名：指定运行该服务的服务器或主机。这可以是 Windows 机器的 NetBIOS 名称（例如 “FilerServer”），也可以是类似 “fileserver.company.com” 的完全限定域名。
- 帐户：与该服务关联的 Active Directory 帐户。它不属于 SPN 字符串本身，而是注册服务主体名称（service principal name）的帐户。
- 端口 （可选）：如果服务运行在非标准端口上，则可以在 SPN 中指定该端口。
Active Directory 中常见 SPN 示例
- Web 服务 – HTTP/webserver.netwrix.com
- SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
- 文件共享 – CIFS/fileserver.contoso.com
- 远程桌面服务 – TERMSRV/rdserver.abcdomain.com
- LDAP 身份验证 – LDAP/domaincontroller.fabricam.com
SPN 与 Active Directory：连接关系
SPN 如何与 Active Directory 对象集成
SPN 是与 AD 对象（如用户帐户、服务帐户或计算机对象）关联的属性。它们充当标签，用于标识哪些服务在由哪些帐户运行。该关联使计算机能够使用 Kerberos 进行安全身份验证，而无需在网络上传送密码。服务安装或配置时，会注册一个 SPN，从而让 Kerberos 将身份验证请求映射到正确的帐户。如果未正确配置 SPN，Kerberos 身份验证将失败，可能导致身份验证错误以及服务中断。
SPN 存储在 servicePrincipalName 属性中
SPN 作为对象的 servicePrincipalName 属性的一部分存储在 Active Directory 中。该属性存在于计算机帐户和服务帐户中。你可以使用 Active Directory Users and Computers 在对象的高级属性中查看此属性，如下截图所示。
该属性保存了已分配给该对象的 SPN 列表。每个 SPN 条目都遵循结构化格式，包含服务类型、主机和可选端口号。
你可以使用以下命令查看 AD 对象的 SPN：setspn –L hostname。下面的示例中，该命令用于查看名为 ABCDomain.com 的域由域控制器生成的 SPN 列表。
AD 林中 SPN 唯一性的重要性
每个服务主体名称（service principal name）必须在整个 Active Directory 林中保持唯一。此唯一性可确保 Kerberos 能够将服务请求正确路由到相应帐户。不同帐户上的重复 SPN 会导致身份验证冲突，从而造成不可预测的行为，甚至直接导致身份验证失败。
配置 SPN：分步指南
SPN 配置所需工具
SPN 配置的主要工具是 setspn.exe，它内置于 Windows Server 操作系统中。该命令行工具允许管理员读取、修改和删除 Active Directory 服务帐户的服务主体名称。
在之前的示例中，我们使用 setspn -L 查看计算机对象的 SPN。你也可以使用 setspn -S 添加 SPN。例如，要向名为 webserver1 的计算机添加一个 HTTP SPN，命令如下：
setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount
请注意，setspn -S 命令会在创建新的 SPN 之前自动检查是否存在相同的现有 SPN，以防止出现重复条目。
要移除 SPN，请使用 setspn -D 命令。您还可以用多种方式使用 PowerShell 来处理 SPN。比如，下面这个 PowerShell cmdlet 将查找 Active Directory 中注册的所有 SPN：
Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName
而此命令将检测所有重复的 SPN。
$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |
Select-Object -ExpandProperty servicePrincipalName
SPN 注册的最佳实践
- 为用于 SPN 注册的服务帐户授予最少必要权限
- 使用 PowerShell 在注册新的 SPN 之前检查是否存在重复项：
- 定期审计 SPN，以识别并移除不必要或已过时的条目
- 添加 SPN 时使用标准化的 SPN 命名格式
排查常见的 SPN 问题
重复的 SPN 可能导致身份验证失败，必须解决。留意用户报告的间歇性访问问题，因为这可能表明 SPN 冲突。您可以使用 setspn -x 命令在单个域内查找重复项，如下方截图所示。
使用 setspn -F 命令搜索整个林。要解决重复的 SPN：
- 确定持有重复 SPN 的账户。
- 确定哪个帐户应当合法持有该 SPN。
- 使用 setspn -D <SPN> <AccountName> 从不正确的帐户中移除该 SPN8。
- 使用 setspn -S <SPN> <AccountName> 将该 SPN 添加到正确的帐户
除重复项外，还有一些其他常见的 SPN 配置错误包括：
- 服务的 SPN 缺失
- 注册到不正确帐户的 SPN
- 服务器名称更改后的过时 SPN
（无需在此再次列出我们已经在前面涵盖过的相同工具）
高级 SPN 概念
SPN 在多服务和多主机环境中的作用
服务帐户是为在 Windows Server 上运行的服务而创建的专用用户帐户。它们有助于在 Internet Information Services (IIS) 等关键应用中隔离并保护域帐户。在复杂环境中，多个服务往往会在同一台机器上运行，每个服务都需要为正确身份验证配置不同的 Service Principal Names (SPNs)。
一个常见的例子是，托管 Web 应用的服务器可能同时运行 SQL Server 和 IIS。每个服务都需要自己的 SPN，以确保正确的 Kerberos 身份验证：
- 适用于 IIS：HTTP/servername.domain.com
- 适用于 SQL Server：MSSQLSvc/servername.domain.com:1433
在多主机环境中，当服务为实现负载均衡或故障转移而跨多台服务器运行时，SPN 配置会变得更加复杂。以在共享 DNS 名称下由多台服务器（Web01、Web02、Web03）共同托管的 Web 应用为例。在这种情况下，必须将 SPN 注册到同一个服务帐户上，以便在所有主机之间实现无缝身份验证：
特殊情况：HOST SPN 及其独特行为
HOST SPN 是一种特殊类型的 SPN，会在 Active Directory 的计算机对象上自动注册。它们充当运行在计算机本地系统或网络服务帐户下的服务的通用标识。这样可以简化许多标准 Windows 服务的管理，并减少对手动 SPN 配置的需求。
下表汇总了何时应使用 HOST SPN，而何时应使用 Custom SPN：
|
Running a service as Local System |
YES |
NO |
|
Running a service as Network Service |
YES |
NO |
|
Running a service under a Domain User Account |
NO |
YES |
|
Multi-host service or Load Balancing |
NO |
YES |
提示：切勿手动修改 HOST SPN，因为它们由 AD 管理。
SPN 及其安全影响
为什么在 AD 环境中保护 SPN 至关重要
SPN 之所以必须重视安全性，原因很简单。服务帐户往往拥有更高的权限。它们还能够持续访问网络中的关键系统，并且在创建之后经常被忽视。所有这些因素都会使它们成为攻击者的高价值目标。攻破某个 SPN 可能导致对关键服务的未授权访问，并可能使攻击者能够在网络中横向移动以及升级他们的权限
弱配置的 SPN 如何被利用
当 SPN 配置较为薄弱时，它们可能会被 Kerberoasting 等攻击所利用。下面是攻击者如何实施此类攻击：
- 权限极低的攻击者可以为任何 SPN 请求服务票据：Requests service tickets for these SPNs
- 该服务票据使用服务账户的密码哈希进行加密，可以被提取出来并离线用于破解。
- 对这些票据进行离线密码破解；如果密码较弱，攻击者可能会成功破解并获得对服务账户的访问权限，且往往具有更高的权限。
一旦攻击者破解了服务账户的密码，并且该账户具有高权限，他们就可以在网络中横向移动或提升其访问权限。
保护 SPN 和服务账户的最佳实践
以下是用于缓解与 SPN 相关的安全风险的最佳实践列表：
- 为具有 SPN 的账户使用长且复杂的密码，并定期轮换
- 避免将 SPN 分配给具有高权限的账户，例如 Domain Admins
- 将服务账户的权限限制为仅满足其功能所需的权限
- 禁用服务账户的交互式登录
- 监控在 PowerShell 中是否出现与 SPN 相关的命令被意外使用的情况。
- 由于任何具有域身份验证的用户都可以搜索 SPN，您应通过更改 Active Directory 中的权限来限制谁可以执行这些查询。
检测与缓解 SPN 滥用
监控和审计与 SPN 相关的活动
持续监控您的 AD 环境，并审计与 Kerberos 相关的事件，有助于在很大程度上防止 SPN 滥用。您应检测的内容包括：
- 异常的 SPN 枚举请求，因为攻击者可能会使用 LDAP 工具向 AD 查询 SPN。
- 频繁的 Kerberos 票据请求，因为服务票据请求的任何突然激增都可能表明攻击正在进行。
- 服务帐户从非通常指定位置登录，而是从意外位置登录。
- 认证失败尝试，因为反复失败表明可能是 password spraying 或暴力破解(brute-force)攻击尝试。
实施针对基于 SPN 的攻击的缓解策略
如果您的组织在 Windows Active Directory 环境中运行，您应考虑以下预防性安全控制，以最大限度降低 SPN 滥用和 Kerberoasting 攻击的风险。
- 为服务帐户使用长且复杂的密码（绝对最低 14 个字符）
- 防止跨不同帐户重复使用密码，并定期更换密码
- 应用 最小特权原则 来限制帐户权限。
- 强制缩短 Kerberos 票据的有效期，以尽量减小攻击窗口
- 定期检查并移除过时或不必要的 SPN
- 采用多层防御策略，结合强有力的服务帐户管理、精细的监控以及定期的培训计划。
使用组托管服务帐户和强加密方法
部署组托管服务帐户（Group Managed Service Accounts，gMSAs），以便受益于自动化的密码管理。组托管服务帐户（Group Managed Service Accounts，gMSAs）是 Active Directory 中的专用服务帐户，相较于传统服务帐户提供了增强的安全功能。它们尤其适用于运行 SQL Server、IIS Web 应用程序、计划任务以及其他需要在特定权限的安全上下文中运行的服务的加入域服务器。使用 gMSAs 将消除手动分配密码的需求，并降低凭据被盗的风险。关于加密，请在 Active Directory 中禁用较弱的 DES 和 RC4 加密类型，同时强制使用强 AES128/AES256 Kerberos 加密。
实际应用与使用案例
如前所述，SPN 用于 Kerberos 身份验证，适用于 Web 应用程序和数据库。IIS 使用格式为“HTTP/ServerName”的 SPN，并将其映射到运行应用程序池的域帐户；而“MSSQLSvc/host.domain.com:1433”则是一个 SQL 服务帐户的示例。然而，随着企业越来越多地采用混合网络架构，Service Principal Names (SPNs) 的作用正在超越传统用例而演变。如今，我们甚至看到 SPN 能够促进本地资源与云原生应用之间进行安全身份验证。其他示例包括：
- SPN 正在被用于管理部署在容器化环境中的容器化应用程序和服务的身份与访问权限。
- 边缘环境使用 SPN，以促进边缘设备与集中式云资源之间的安全通信。
- Azure AD Connect 使用 SPN 来在本地 AD 和 Azure AD 之间提供同步服务。
如今，在企业环境中对 SPN 的使用也在不断增加。例如，安全团队会监控 SPN 使用日志，以检测未经授权的访问尝试或 Kerberos 失败。其他示例包括：
- 单点登录（Single Sign-On，SSO）：SPN 使基于 Kerberos 的单点登录能够覆盖多个应用和服务。
- 应用集成：SPN 便于在不同的企业应用和服务之间进行安全通信。
- 委托式身份验证：SPN 允许服务在多层应用中代表用户进行身份验证。
结论
服务主体名称（Service Principal Names，SPN）自 Active Directory 诞生之初起就一直是 Kerberos 身份验证的基石。它们是网络用户所依赖的许多经典服务中的常见组成部分，而 SPN 在确保众多后台服务能够安全、顺畅地运行方面发挥着至关重要的作用。随着组织持续扩展与演进，SPN 的应用也在拓展到云集成和物联网（IoT）等领域。鉴于当今企业对安全的重视不断增强，SPN 很可能会在未来发挥更大的作用，以适应新的技术以及在不断扩大的数字化环境中出现的安全挑战。
分享到
了解更多
关于作者
Joe Dibley
安全研究员
Netwrix 的安全研究员，并且是 Netwrix Security Research Team 的成员。Joe 是 Active Directory、Windows 以及各类企业软件平台与技术方面的专家；他/她研究新的安全风险、复杂的攻击技术，以及相应的缓解措施与检测方法。