Kerberos 委派是 Windows 活动目录中一项允许服务代表用户去访问其他服务的认证机制。在多层应用架构里，前端服务经常需要把登录用户的身份传递给后端数据库或文件服务，这时就必须依赖委派能力。如果不理解其底层逻辑，直接开启完全委派，域控制器会把用户的原始票据交给前端服务，该服务就能以用户身份访问任意资源，带来极大安全隐患。约束委派正是为解决这个问题而生，它限定了服务只能代用户访问预先登记的后端服务，从机制上收窄了滥用可能。
非约束委派与约束委派的核心差异
非约束委派（Unconstrained Delegation）是最早出现的委派模式。当某个服务账户被标记为可信赖用于委派时，用户通过它认证后，域控会把用户的 TGT（票据授予票据）一同缓存到该服务的内存中。这意味着该服务进程一旦被攻破，攻击者可以提取出用户的 TGT，进而用该用户身份访问域内任何允许该用户访问的资源，实现权限横向移动。这种机制在今天的域安全规范里已被视为高风险配置，通常只在极个别遗留系统兼容性需求下才考虑。
约束委派（Constrained Delegation）则引入了明确的目标限制。管理员需要为服务账户设置 msDS-AllowedToDelegateTo 属性，列举该账户可以代表用户访问的后端服务 SPN（服务主体名称）。当用户向前端服务认证后，前端服务只能向域控请求针对这些指定 SPN 的转发票据，无法越界。Windows 还进一步支持基于资源的约束委派（RBCD），将授权决定权放在后端资源账户上，通过 msDS-AllowedToActOnBehalfOfOtherIdentity 属性反向允许哪些前端账户委派过来，更适配现代灵活架构。
从攻击面角度看，非约束委派相当于把家门钥匙交给管家任其配副钥匙，约束委派则是只给管家开储物间的单向权限。实际渗透测试中，红队常扫描域内部署了非约束委派的机器账户，因为这类账户往往能捕获高权限管理员登录时的 TGT。因此新上线的服务应当默认采用约束委派，并在设计阶段就梳理清楚服务间的调用链，避免盲目开放权限。
约束委派的具体配置步骤
在活动目录用户和计算机控制台中，找到运行前端服务的账户（通常是域用户账户或托管服务账户），打开属性页切换到“委派”选项卡。选择“仅信任此用户作为指定服务的 Kerberos 委派”，注意不要勾选“使用任何身份验证协议”，否则会退化为协议过渡并扩大风险。随后在下方添加后端服务实际运行的账户及其 SPN，例如后端为 SQL 服务，则应添加 MSSQLSvc/sqlserver.ipipp.com:1433 这类条目。保存后，域控会在该账户对象上写入 msDS-AllowedToDelegateTo 属性。
如果使用 PowerShell 进行批量或自动化配置，可以借助 ActiveDirectory 模块直接操作属性。下面示例为前端服务账户 appsvc 设置允许委派到后端打印服务 spoolsvc 的 SPN：
# 导入活动目录模块
Import-Module ActiveDirectory
# 定义前端服务账户与允许访问的后端SPN
$frontend = "ipippappsvc"
$spnList = @(
"cifs/backend.ipipp.com",
"ldap/backend.ipipp.com"
)
# 设置约束委派目标
Set-ADAccountControl -Identity $frontend -TrustedForDelegation $false
Set-ADObject -Identity (Get-ADUser -Identity $frontend).DistinguishedName `
-Add @{ "msDS-AllowedToDelegateTo" = $spnList }
Write-Host "约束委派配置已完成"
配置完成后，必须确认前端服务以该账户运行且已注册正确的 SPN，否则 Kerberos 认证会回退到 NTLM 并导致委派失败。后端服务也要支持 Kerberos，且时钟与域控同步误差在五分钟内。很多排错案例显示，SPN 重复或缺失是约束委派不生效的头号原因，可用 setspn -L 账户名 命令检查。基于资源的约束委派则要在后端账户上配置允许前端账户的安全标识符，适合跨域或云混合场景。
约束委派的常见故障与排查思路
当应用报告“无法以用户身份访问后端”时，首先应查看前端服务事件日志中是否有 Kerberos 错误代码。例如 KRB_AP_ERR_MODIFIED 通常意味着 SPN 解析到了错误的账户，可能是重复注册引起。此时需要在域中全局搜索该 SPN，确保只绑定到正确的服务账户。另一类常见问题是用户账户被标记为“敏感且不能被委派”，这类账户即使前端配置正确也会被域控拒绝转发票据，需要在用户属性中取消该限制或改用协议过渡方案。
网络层面也不能忽视。约束委派依赖域控的 KDC 服务签发转发票据，如果前端服务器无法连通域控的 88 端口，或者 DNS 解析域名称出错，都会导致 S4U2Proxy 请求失败。在复杂网络分段中，应放通相关端口并配置正确的 DNS 后缀。以下代码展示如何在 Linux 整合环境用 kinit 模拟检测前端账户能否获取初始票据：
# 使用前端服务密钥表获取初始票据 kinit -k -t /etc/security/keytabs/appsvc.keytab appsvc@IPIPP.COM # 查看当前缓存票据 klist # 若成功则说明基础Kerberos通路正常 # 下一步应在应用层检查S4U2Proxy请求目标SPN是否在允许列表
最后，组策略里“ kerberos 委派信任设置”也可能覆盖单个账户的设定。有些域强制要求仅允许使用约束委派并禁用非约束，这是良好实践，但运维人员需确认策略没有误伤正常业务。建议每次变更后，用域控上的 ldifde 工具导出账户属性核对 msDS-AllowedToDelegateTo 的值，并保留变更记录以便审计。通过规范配置与持续监控，约束委派可以在不牺牲便利性的前提下，把身份转发控制在最小必要范围。