Kerberos委派分三种：非约束委派允许服务账户代表用户访问任意服务，风险最高；约束委派需显式指定可访问的后端SPN；基于资源的约束委派由后端资源定义策略，更安全可控。
windows域环境中，kerberos委派用于让服务账户代表用户向其他服务发起认证请求，常见于iis+sql、exchange+ad fs等多层应用架构。配置不当会极大扩大攻击面，必须在明确业务需求前提下谨慎启用。
非约束委派（Unconstrained Delegation）
这是最宽松的委派模式，目标服务账户（如Web服务器计算机账户或服务账户）被允许接收用户的TGT，并用它访问任意其他服务。一旦该账户被攻陷，攻击者可直接提取用户TGT，冒充用户访问域内所有支持Kerberos的服务。
- 仅在极老系统或无法升级的场景中使用，现代环境应避免
- 启用方式：在AD用户和计算机中，右键服务账户 → 属性 → 委派选项卡 → 勾选“信任此计算机用于委派”
- 可通过PowerShell快速识别：
Get-ADComputer -Filter {TrustedForDelegation -eq $true}
约束委派（Constrained Delegation）
管理员需显式指定该服务能代表用户访问哪些后端服务（SPN），大幅缩小权限范围。依赖传统Kerberos协议，不支持基于资源的约束委派中的某些新特性，但兼容性好。
- 配置前确保服务账户为用户或计算机账户，且已注册对应SPN（如
HTTP/web01.contoso.com） - 通过PowerShell设置示例：
Set-ADUser -Identity "svc-webapp" -PrincipalsAllowedToDelegateToAccount "sql01$"
或更精确地指定SPN：Set-ADUser -Identity "svc-webapp" -AllowedToDelegateTo "MSSQLSvc/sql01.contoso.com:1433" - 验证是否生效：抓包查看Kerberos TGS-REQ中是否携带
FORWARDED标志及正确的S4U2Proxy请求
基于资源的约束委派（Resource-based Constrained Delegation）
委派策略由后端资源（如SQL服务器）主动定义，而非由前端服务账户控制，权限模型更清晰、管理更集中，是Windows Server 2012 R2起推荐的方式。
- 关键字段是
msDS-AllowedToActOnBehalfOfOtherIdentity，需用AD模块或LDP工具设置 - PowerShell配置示例：
$acl = Get-Acl "AD:\CN=sql01,CN=Computers,DC=contoso,DC=com"<br> $identity = New-Object System.Security.Principal.IdentityReference "CONTOSO\svc-webapp"<br> $ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $identity,"ExtendedRight","Allow","00000000-0000-0000-0000-000000000000","All"
（实际中建议用Set-ADComputer -PrincipalsAllowedToDelegateToAccount简化操作） - 要求前端账户启用
Trust this user for delegation to specified services only（即约束委派），后端资源才接受S4U2Self+S4U2Proxy流程
典型风险与加固建议
Kerberos委派本身不是漏洞，但配置失误会将服务账户变成“跳板”。真实攻防中，Golden Ticket、DCSync常配合委派滥用实现横向移动。
- 禁用所有非必要账户的委派权限，尤其是Domain Admins、Enterprise Admins成员
- 避免对计算机账户启用委派；优先使用专用服务账户，并设强密码+密码永不过期
- 定期审计：
Get-ADObject -Filter {(msDS-AllowedToDelegateTo -like "*") -or (TrustedForDelegation -eq $true)} - 启用Kerberos策略日志（审核Kerberos身份验证服务）并监控事件ID 4769（TGT发放）和4768（TGS请求）中的异常委托行为
