前言
上一节讲的非约束委派，这一次我们来看一下约束委派。在 Windows Server 2003 中引入了约束委派，对 Kerberos 协议进行拓展，引入了 S4U (S4U2Self / S4U2proxy), 运行服务代表用户向 KDC 请求票据。
正文
S4U2self (Service for User to S4U2Self) :
可以代表自身请求针对其自身的 Kerberos 服务票据(ST)；如果一个服务账户的 userAccountControl 标志为 TRUSTED_TO_AUTH_FOR_DELEGATION, 则其可以代表任何其他用户获取自身服务的 TGS/ST。
具体流程:
(1) 用户向 service1 发送请求。用户已通过身份验证，但 service1 没有用户的授权数据。通常，这是由于身份验证是通过 Kerberos 以外的其他方式验证的。(2) 通过 S4U2self 扩展以用户的名义向 KDC 请求用于访问 service1 的 ST1。（这里就是请求自身的）(3) KDC 返回给 service1 一个用于用户验证 service1 的 ST1，该 ST1 可能包含用户的授权数据。(4) service1 可以使用 ST 中的授权数据来满足用户的请求，然后响应用户。尽管 S4U2self 向 service1 提供有关用户的信息，但 S4U2self 不允许 service1 代表用户发出其他服务的请求，这时候就轮到 S4U2proxy 发挥作用了。
S4U2proxy(Service for User to Proxy) ：
可以以用户的名义请求其它服务的 ST，限制了 S4U2proxy 扩展的范围。服务帐户可以代表任何用户获取在 msDS-AllowedToDelegateTo 中设置的服务的 TGS/ST，首先需要从该用户到其本身的 TGS/ST，但它可以在请求另一个 TGS 之前使用 S4U2self 获得此 TGS/ST。
具体流程：
(1) 用户向 service1 发送请求。用户已通过身份验证，但 service1 没有用户的授权数据。通常，这是由于身份验证是通过 Kerberos 以外的其他方式验证的。(2) 通过 S4U2self 扩展以用户的名义向 KDC 请求用于访问 service1 的 ST1。（这里就是请求自身的）(3) KDC 返回给 service1 一个用于用户验证 service1 的 ST1，该 ST1 可能包含用户的授权数据。(4) service1 可以使用 ST 中的授权数据来满足用户的请求，然后响应用户。尽管 S4U2self 向 service1 提供有关用户的信息，但 S4U2self 不允许 service1 代表用户发出其他服务的请求，这时候就轮到 S4U2proxy 发挥作用了。
约束委派利用条件:
添加可以被委派的服务
adfind查找约束委派
利用keko申请TGT，利用这张TGT去伪造s4u以administrator的身份去访问域控（OWA）的ST。
mimikatz导入ST2票据
访问成功
还有一种特殊的是服务账号变成krbtgt，这个危害就大了，原理同上。
参考:星期五实验室
原文始发于微信公众号（Th0r安全）：带你认识约束委派
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论