Kerberos约束委派是允许前端服务以原始用户身份、仅访问指定SPN后端服务的Kerberos机制，适用于IIS+SQL、SharePoint多跳等场景，需满足域功能级别≥2012 R2、有效SPN、时间同步≤5分钟等前提，推荐用PowerShell配置并验证PrincipalsAllowedToDelegateToAccount属性。
配置 kerberos 约束委派不是“开个开关”就能用，核心在于明确谁代表谁、能访问哪个服务、凭证如何流转。它解决的是多跳场景下用户身份不丢失的问题，但配置错一步，就可能引入高危攻击面。
约束委派到底是什么
它是一种 Kerberos 协议机制，允许某个服务账户（比如 IIS 应用服务器）以**当前登录用户的身份**，向**预先指定的后端服务**（如 SQL Server、HTTP API）发起认证请求。关键限制在于：只能访问列表里写的 SPN（Service Principal Name），不能越界。
这和非约束委派有本质区别——后者相当于把用户的“身份证原件”（TGT）直接交给服务，服务可随意去任何地方冒充；而约束委派只给“限用途介绍信”，写明“仅可用于访问 SQL/srv01.contoso.com”。
哪些场景真正需要它
不是所有跨服务调用都需要约束委派。只有当用户身份必须**逐跳传递、且后端需基于该身份做权限控制**时才适用。
- IIS + SQL Server 架构：用户通过浏览器访问 Web 应用，应用需以用户身份连接数据库执行查询（如行级安全策略依赖 AD 用户组）
- Exchange 或 SharePoint 的多跳集成：前端门户调用后端搜索服务或用户配置服务，且后端需识别原始调用者
- 微服务间可信调用链：API 网关接收用户请求后，需携带其身份调用下游鉴权服务或数据服务
- Power BI 或 SSAS 连接直连数据库：报表服务需模拟最终用户访问底层 SQL 或 Analysis Services，实现动态数据掩码
配置前必须确认的几件事
漏掉任一环节，后续都会报错（比如 KDC_ERR_BADOPTION 或 “无法建立委托会话”）。
- 域功能级别 ≥ Windows Server 2012 R2（推荐 2016+），否则不支持基于资源的委派等现代特性
- 前端服务账户必须是域用户或域计算机账户，不能是本地系统账户（如 NT AUTHORITY\SYSTEM）
- 所有参与节点（客户端、前端服务、后端服务）时间偏差 ≤ 5 分钟，用
w32tm /query /status检查 - 后端服务已注册准确 SPN，例如
MSSQLSvc/sql01.contoso.com:1433或HTTP/api.internal.contoso.com，大小写不敏感，但 FQDN 和端口必须完全匹配 - 前端服务所在主机启用 Kerberos 认证（禁用 NTLM 可提升安全性，但需确保客户端兼容）
两种主流配置方式怎么选
实际部署中主要用两类，选择取决于管理权归属和环境可控性：
-
传统约束委派（Account-based）：由前端服务管理员在 AD 中设置，用
Set-ADUser -PrincipalsAllowedToDelegateToAccount指定后端 SPN。适合单域、前端团队主导的场景，但要求域管理员权限 -
基于资源的约束委派（Resource-based）：由后端服务管理员控制，在 SQL Server 或 Web 服务器计算机对象上设置
msDS-AllowedToActOnBehalfOfOtherIdentity。更安全、权限更聚焦，也支持跨域，是 Windows Server 2012 R2 起官方推荐方式
注意：PowerShell 配置比 GUI 更可靠，GUI 容易遗漏属性或误选“任意协议”选项；验证务必用 Get-ADUser xxx -Properties PrincipalsAllowedToDelegateToAccount 或抓包看 TGS-REQ 是否含 S4U2Proxy 标志。
不复杂，但容易忽略细节。
