Skip to content

约束性委派

因为之前的非约束性委派造成的问题，所以在这里需要引入一个约束性委派的方式。

约束性委派主要为在设置当中 设置某个用户访问某个服务的时候能够被委派 20211014233246

在这里就是 当用户访问 qiyou的时候能够委派到 dm08的cifs服务

约束性委派包括S4U 协议扩展

S4U当中包括 S4USELF 和 S4U2PROXY

20211014233308

s4u2self

服务代表以用户的名义去请求针对自身的票据

1. 用户向service1发出请求。用户已通过身份验证，但service1没有用户的授权数据。通常，这是由于身份验证是通过Kerberos以外的其他方式验证的。

2. 通过S4U2self扩展以用户的名义向KDC请求用于访问service1的ST1。

3. KDC返回给Service1一个用于用户验证Service1的ST1，该ST1可能包含用户的授权数据。

4. service1可以使用ST中的授权数据来满足用户的请求，然后响应用户。
5. 
注：尽管S4U2self向service1提供有关用户的信息，但S4U2self不允许service1代表用户发出其他服务的请求，这时候就轮到S4U2proxy发挥作用了

作用

s4u2self 代替用户请求了一个访问service1 的ticket，将该ticket给了用户。

20211014233434

s4u2self

1、请求一个可转发的票据，使得

不需要用户提供任何的认证，

PA_FOR_USER

标识符指示用户的身份，唯一标识符由用户名和域名组成

service1 不需要提供TGT，但是需要通过服务的某些验证，比如web，已经通过了认证，但是service1没有用户的认证信息(一般是因为没有使用kerberos协议)

service1 向kdc请求了可转发的用户访问service1的ticket，这个ticket的pa-for-user结构体当中表明了用户，这个ticket也不能使用到其地方

s4u2proxy

service1 使用 st1 向kdc 请求了 msds-allowedtodelegateto的ticket2

service1 使用st2 以用户的名义向service2 请求，判定用户是否由kdc进行身份验证

s4u2proxy

以用户的名义请求其他服务的st

约束委派即限制s4u2proxy的范围 

5. 用户向service1发出请求，service1需要以用户身份访问service2上的资源。

6. service1带上st1以用户的名义向KDC请求用户访问service2的ST2

7. 如果请求中包含PAC，则KDC通过检查PAC的签名数据来验证PAC ，如果PAC有效或不存在，则KDC返回ST2给service1，但存储在ST2的cname和crealm字段中的客户端身份是用户的身份，而不是service1的身份。

8. service1使用ST2以用户的名义向service2发送请求，并判定用户已由KDC进行身份验证。

9. service2响应步骤8的请求。

10. service1响应用户对步骤5中的请求。

20211014233520

漏洞在于第6个步骤，如果攻击者是中间服务器，即可以向KDC伪造高权限用户访问自身的请求，并且可以利用这个伪造的请求

只能访问设置好的特定服务

寻找方式

AdFind.exe -b "DC=adc,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

Referer

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/1fb9caca-449f-4183-8f7a-1a5fc7e7290a?redirectedfrom=MSDN

Back to top