SPN及其在Active Directory和安全中的作用
Sep 4, 2026
Service Principal Names (SPN) 是 Active Directory 中的唯一标识符，将服务实例映射到用于 Kerberos 认证的服务帐户。任何注册到用户帐户而非托管服务帐户的 SPN 都会直接导致 Kerberoasting 攻击，攻击者可离线破解该帐户密码。通过 Event ID 4769 检测，并使用 Group Managed Service Accounts、强密码和仅 AES 的 Kerberos 加密进行防护。
服务主体名称（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：
提示：切勿手动修改 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 很可能会在未来发挥更大的作用，以适应新的技术以及在不断扩大的数字化环境中出现的安全挑战。
什么是SPN？
Service Principal Name（SPN）是将特定服务实例链接到运行该实例的Active Directory帐户的唯一标识符。SPN必须在整个Active Directory林中唯一。
如果两个帐户拥有相同的SPN，域控制器无法确定向哪个帐户发放票证，认证将失败。如果没有帐户拥有该SPN，请求将完全失败，客户端通常会回退到NTLM，这本身也存在风险。
将SPN注册到个人用户账户而非托管服务账户会使该攻击成为可能。防御措施是服务账户卫生。使用Group Managed Service Accounts。对仍持有SPN的任何账户强制使用长且随机生成的密码。监控事件ID 4769，以发现暴露攻击的票据请求激增。
SPN在Kerberos身份验证中的作用
它们也是Kerberoasting的攻击面。任何经过域认证的用户都可以请求带有SPN的账户的Kerberos服务票据，并离线破解以获取该账户的密码，而不会触发锁定阈值。
- 客户端为其想要访问的服务构建一个SPN。
运行 SQL Server、IIS、Exchange 和自定义应用程序的 Active Directory 环境需要每个服务能够在不提示用户输入凭据或在配置文件中嵌入密码的情况下进行身份验证。Service Principal Names 使这成为可能。
当客户端请求访问服务时，Kerberos身份验证流程遵循定义的顺序：
SPN存在于计算机对象和服务帐户中，作为名为servicePrincipalName的多值属性。该属性中的每个条目代表一个已注册的服务。运行多个服务的帐户，或通过多个主机名访问的服务，具有多个SPN条目。
- 客户端使用该SPN向域控制器请求服务票证。
- 客户端向服务出示票据进行身份验证，密码不会通过网络传输。
- 域控制器在Active Directory中查找SPN。
- 一旦找到，域控制器会发出用服务帐户凭据加密的服务票证。
SPN 结构和组件
此序列说明了SPN准确性的重要性。缺失、重复或配置错误的SPN会在第3步中断查找，导致身份验证失败或回退到NTLM。
SPN的组成部分
SPN不是单一值，而是由多个组件组成的结构化字符串。理解该结构对于正确注册、故障排除和安全审查至关重要。
每个SPN遵循一个定义的格式，用于识别服务、运行它的主机，以及可选使用的端口。组成部分包括：
Active Directory 中常见的 SPN 格式
- 账户： 与服务关联的Active Directory账户。这不是SPN字符串本身的一部分，而是SPN注册的对象。
- 端口（可选）： 当服务运行在非标准端口时包含（例如，
MSSQLSvc/host.domain.com:1433）。 - 服务类别： 服务类型的名称，例如
MSSQLSvc用于 Microsoft SQL Server，或HTTP用于网络服务。 - 主机名： 运行服务的服务器或主机，表示为 NetBIOS 名称（例如，
FileServer）或完全限定域名（例如，fileserver.company.com）。
格式 ServiceClass/Hostname: Port 在各种服务类型中生成可预测且易识别的字符串。常见示例包括：
- 网络服务：
HTTP/webserver.netwrix.com - SQL Server：
MSSQLSvc/myhost.redmond.microsoft.com:1433 - 文件共享：
CIFS/fileserver.contoso.com - 远程桌面服务：
TERMSRV/rdserver.abcdomain.com
Active Directory 如何存储和解析 SPN
Netwrix Threat Manager 映射本地 Active Directory 和 Entra ID 中的凭据盗窃、横向移动和权限提升。获取演示。
- LDAP 认证：
LDAP/domaincontroller.fabrikam.com
servicePrincipalName 属性
SPN 是与 AD 对象（如用户帐户、服务帐户或计算机对象）关联的属性。它们作为标签，指示哪些服务在哪些帐户下运行。此连接允许计算机使用 Kerberos 进行安全身份验证，而无需通过网络发送密码。
当您安装或配置服务时，它会注册一个SPN，使Kerberos能够将身份验证请求映射到正确的帐户。没有正确配置的SPN，Kerberos身份验证将失败，可能导致身份验证错误和服务中断。
当客户端请求访问某服务时，会为该服务构建一个SPN，提交给域控制器，DC会在目录中查找该SPN。如找到，则颁发Kerberos服务票据。密码不会通过网络传输。
SPN 唯一性如何实现正确的服务解析
您可以使用命令 setspn –L hostname 查看 AD 对象的 SPN。下面的示例中，使用该命令查看了域控制器为名为 ABCDomain.com 的域生成的 SPN 列表。
SPN作为对象的servicePrincipalName属性的一部分存储在Active Directory中。此属性存在于计算机帐户和服务帐户中，包含注册到该对象的所有SPN的列表。您可以通过对象属性中的选项卡查看它，位于Active Directory Users and Computers，如下图所示。
HOST SPNs 以及 AD 何时自动管理它们
下表总结了何时使用 HOST SPNs 与自定义 SPNs：
HOST SPN 是 Active Directory 自动在计算机对象上注册的一类特殊 SPN。它们作为在本地系统或网络服务帐户下运行的服务的通用标识符，涵盖了许多标准 Windows 服务，无需手动添加 SPN 条目。
在排查身份验证问题时，重复的SPN应是首先检查的内容之一。使用 setspn -X 来检测域内重复项，使用 setspn -F 来搜索整个林。
每个SPN必须在整个Active Directory林中唯一。此唯一性使得Kerberos authentication能够将服务请求路由到正确的帐户。如果两个帐户拥有相同的SPN，域控制器无法确定使用哪一个，导致身份验证失败、间歇性登录错误和服务连接中断。
切勿手动修改 HOST SPN。Active Directory 会自动管理它们，修改可能会中断核心服务。
如何配置和管理SPN
步骤1：识别服务和目标账户
步骤2：检查现有或重复的SPN
正确配置SPN是Kerberos身份验证正常工作的前提。无论服务类型如何，该过程都遵循一致的顺序，跳过步骤是SPN相关问题最常见的原因。
注册前，请确认该 SPN 不存在于其他账户中。使用以下命令查询目录：
注册重复的SPN可能导致身份验证失败，并且事后难以诊断。
步骤3：使用setspn注册SPN
在注册SPN之前，请确定两件事：所需的服务类别和格式，以及将运行该服务的Active Directory帐户。对于标准服务（SQL Server、IIS、Exchange），服务类别有详细文档。对于帐户，优先使用专用的Active Directory service account，或者在可能的情况下，使用Group Managed Service Account（gMSA），而不是共享或个人帐户。
对于在非标准端口运行的 SQL Server：
使用 setspn -S（安全添加）来注册SPN。-S标志会在创建条目之前自动检查重复，使其比旧的-A标志更安全：
步骤4：验证注册
您也可以通过PowerShell使用Set-ADUser或Set-ADComputer cmdlet注册SPN，这对于脚本部署或批量注册非常有用。
您也可以使用 PowerShell 进行验证：
注册后，确认SPN显示在正确的账户上：
输出应列出新注册的SPN以及已分配给该帐户的其他SPN。
步骤5：测试Kerberos身份验证
修复常见的SPN配置错误
大多数SPN问题属于少数几类。每类都需要针对性的解决方案：
在 Windows 事件查看器中，成功的 Kerberos 服务票证请求显示为事件 ID 4769。如果身份验证回退到 NTLM，SPN 可能缺失、格式错误或注册在错误的帐户上。
注册SPN后，测试Kerberos认证是否成功。使用域凭据连接到服务，然后运行 klist 以确认DC已签发Kerberos服务票据（而非NTLM票据）。
SPN 注册最佳实践
- 重复的SPN： 使用
setspn -D从错误的账户中移除SPN，然后确认它仍保留在正确的账户中。服务器重命名或账户迁移后常出现重复项。 - 服务器重命名后的过时SPN：必须删除引用之前主机名的旧SPN，并在当前名称下注册新的SPN。
- 缺失的SPN： 如果Kerberos失败并回退到NTLM，请使用
setspn -Q检查SPN是否存在。如不存在，请注册。 - 注册在错误账户上的SPN： 使用
setspn -D删除并重新注册到正确的服务账户。
建立一致的SPN管理实践可减少运营故障和安全风险：
- 定期运行PowerShell审计，以识别注册到不当账户的SPN。
- 将SPN分配给专用服务帐户，而不是个人用户帐户或Domain Admin帐户。
- 注册时使用
setspn -S（不是 -A），以防止意外重复。 - 在整个环境中使用标准化的命名格式以简化审计。
配置错误的SPN的安全风险
Kerberoasting
- 授予账户所需的最低权限。SPN 注册需要对
servicePrincipalName属性的写入权限，不应广泛授予。
与SPN关联的服务账户是Active Directory中最常被攻击的身份之一。与标准用户账户不同，它们通常拥有较高权限，持续访问关键系统，并且创建后很少被审查。这种组合导致了与配置错误的SPN相关的安全风险。
银票攻击
攻击者可以请求票据，提取它，并执行离线密码破解，而不会触发锁定或产生显著的网络噪音。
Kerberoasting 是最常见的基于SPN的攻击技术。任何经过域认证的用户，包括低权限账户，都可以请求目录中任何SPN的Kerberos服务票据。该票据使用服务账户的密码哈希进行加密。
RC4加密使此攻击显著加快，因为RC4加密的Kerberos票据比现代AES保护的更易破解，这也是Microsoft积极在AD环境中弃用RC4的原因。
如果服务账户使用弱密码或重复密码，攻击者可以恢复明文凭据并获得对服务的访问权限，通常具有提升的权限。
通过被攻破的服务账户进行横向移动
如何防御基于SPN的攻击
通过高权限SPN进行权限提升
在权限过高的账户上注册的SPN，尤其是具有Domain Admin权限或对关键系统无限制访问的账户，代表了最高风险的配置。针对这些账户之一的成功Kerberoasting攻击不仅会破坏服务，还可能使攻击者获得域级控制权。
检测Kerberoasting和SPN枚举
Kerberoasting的自然后续是silver ticket攻击。一旦攻击者破解了服务账户的密码哈希，就可以完全离线伪造Kerberos服务票据，无需与域控制器进一步交互。这些silver ticket授予对目标服务的持久访问权限，且特别难以检测，因为它们完全绕过了DC。
服务账户通常拥有对多个系统的访问权限。当攻击者攻破其中一个时，他们获得了一个立足点，能够实现横向移动整个环境。由于服务账户通常被排除在标准监控和异常检测规则之外，这种移动可能长时间未被发现。
对您的AD环境进行持续监控是第一道防线。需要关注的指标包括：
针对基于SPN的攻击的防御涵盖三个方面：及早检测滥用、在发生时有效响应，以及强化环境以在事件发生前减少攻击面。
- 异常的SPN枚举查询。攻击者通常使用LDAP工具在侦察期间列出域中的所有SPN。
- 来自意外主机或异常时间的服务账户登录。
通过修改Active Directory中的权限来限制谁可以查询SPN，可以减少低权限攻击者可用的侦察时间窗口。
遏制和应对SPN滥用
- 事件ID 4769（Kerberos服务票据请求）突然激增，尤其是使用RC4加密（加密类型0x17）的情况，强烈表明Kerberoasting，因为攻击者偏好RC4票据以加快破解速度。
- 重复的身份验证失败尝试，可能表示暴力破解或 password-spraying 攻击 针对被泄露的凭据。
检测到基于SPN的滥用时，首要任务是限制攻击者使用被泄露凭据的能力：
- 立即使用长且随机生成的凭据重置受影响的服务账户密码。
- 检查账户是否拥有超过其功能所需的权限，并减少这些权限。
- 检查服务帐户可访问的所有系统，并审计最近的活动以查找横向移动的迹象。
强化启用 SPN 的服务帐户
主动加固消除了许多使基于SPN的攻击可行的条件：
- 对服务账户使用长度较长、随机生成的密码（至少25个字符），并按既定计划定期更换。
- 通过重置账户的Kerberos加密密钥，撤销发给该账户的所有有效Kerberos票据（silver ticket缓解不需要重置krbtgt；重置服务账户密码会使伪造的票据失效）。
- 禁用服务账户的交互式登录，以限制其在被攻破时的用途。
- 应用最小权限原则。服务账户应仅访问其功能所需的系统和数据。
使用gMSA和AES加密消除持续风险
- 尽可能迁移到 Group Managed Service Accounts，因为它们自动化密码管理，并使Kerberoasting变得更加困难。
Group Managed Service Accounts (gMSA) 是专门的服务账户，完全消除了手动密码管理的需求。Active Directory 会自动管理 gMSA 密码，按照预定计划轮换密码，使用服务和域管理员从未直接看到或处理的长且随机生成的凭据。
混合和现代环境中的SPN
默认情况下，Windows每30天轮换一次gMSA密码，间隔由msDS‑ManagedPasswordInterval属性（或创建gMSA时的ManagedPasswordIntervalInDays参数）控制，该参数只能在创建时设置。
对于不支持gMSA的服务，强制使用AES-128或AES-256 Kerberos加密，并在Active Directory中显式禁用较弱的RC4和DES加密类型。RC4加密是Kerberoasting攻击中使用的默认加密；移除它将强制请求使用AES，这对离线破解有显著更强的抵抗力。
- 切勿将 SPN 分配给具有 Domain Admin 或其他高权限组成员身份的帐户。
SPN 和 Microsoft Entra Connect
随着组织采用混合架构和容器化工作负载，SPN的角色已超越传统的本地Active Directory。只要使用Kerberos身份验证，SPN依然相关，在某些新环境中，它们支持原始AD设计中不存在的身份验证模式。
容器化环境中的SPN
多层应用中的委托认证
Microsoft Entra Connect 使用 SPN 来实现本地 Active Directory 与 Entra ID（前称 Azure AD）之间的同步服务。同步服务账户需要正确配置的 SPN 以认证两个目录。配置错误或缺失的 SPN 可能会悄无声息地中断目录同步，导致混合环境中的身份数据过时。
Kerberos 委派 允许服务代表用户对下游资源进行身份验证。这在多层应用程序中很常见，其中 Web 前端需要将用户身份传递给后端数据库。
运行在Windows Server上的容器化工作负载可以使用gMSA，并且扩展使用SPN，用于Active Directory security。可将加入域的主机上的Kubernetes和Docker部署配置为请求gMSA凭据，使容器化服务能够使用Kerberos认证AD集成资源，而无需将凭据嵌入容器镜像中。
SPN对此至关重要：委派配置在持有SPN的服务账户上，认证链中的每一步都依赖于正确注册的SPN。
SPN 是基础且日益成为攻击目标
无约束委托，即服务可以模拟任何用户访问任何资源，构成了显著的攻击面，应尽可能替换为受限委托或基于资源的受限委托。
Service Principal Names 自 Active Directory 诞生以来一直是 Kerberos 认证的基石。它们在企业环境中实现安全的无密码服务认证，但前提是正确配置、定期审计并严格管理。
Netwrix 提供专为两大最高优先级 SPN 安全挑战打造的工具：检测正在进行的攻击以及保持对引入风险的 AD 变更的可见性。
Netwrix如何提供帮助
随着组织扩展到混合基础设施、容器和云集成的Identity系统，SPN出现在更多地方，并绑定到拥有比以往更广泛访问权限的账户。
威胁计算因此发生了变化。Kerberoasting已成为企业安全事件中最常见的横向移动技术之一，正因为SPN既普遍存在又监控不足。曾经导致身份验证失败的错误配置现在成为攻击面的一部分。
了解SPN的结构、AD如何解析它们以及攻击者如何利用弱配置，是保护它们的第一步。本文涵盖的操作步骤提供了基础。在此基础上，持续监控、定期SPN审计以及在可能的情况下迁移到gMSA，有助于组织领先于威胁。
Netwrix Threat Manager 检测基于身份的攻击，包括 Kerberoasting、SPN 枚举查询以及跨本地 Active Directory 和 Entra ID 的可疑服务票证请求。
它与账户级别的异常活动相关联。当低权限用户突然请求50个服务工单时，安全团队将其视为单一的综合警报，而非孤立的日志条目。
请求演示，了解 Netwrix 如何帮助您检测 SPN 滥用，实时审核 AD 变更，并在攻击者利用之前减少攻击面。
Netwrix Auditor 跟踪您整个 AD 环境中 servicePrincipalName 属性的每一次更改，包含更改前后的值及负责该更改的账户。当 SPN 注册到高权限账户或意外从服务账户中移除时，Auditor 会立即显示该更改。
关于SPN及其在Active Directory和安全中的作用的常见问题。
分享到
了解更多
关于作者
Joe Dibley
安全研究员
Netwrix 的安全研究员，并且是 Netwrix Security Research Team 的成员。Joe 是 Active Directory、Windows 以及各类企业软件平台与技术方面的专家；他/她研究新的安全风险、复杂的攻击技术，以及相应的缓解措施与检测方法。