委派（Delegation） 是一种允许服务代表用户去访问其他后端服务的机制。

非约束委派:

而非约束委派（Unconstrained Delegation, UCD） 是 Kerberos 委派机制中权限最宽泛、安全风险最高的一种形式。
为了解决双跳问题，微软引入了非约束委派。非约束委派可以作用在服务账号和机器账号上。

非约束委派的流程图如下

image.png

存在安全问题的点在于，有非约束委派属性的机器，会存有发起委派操作账号的TGT，如果诱导或者迫使高权限账户向非约束委派机器发起委派，并且攻击者控制了非约束委派机器，就相当于获取了高权限账户的权限。

约束委派

非约束委派机器可以被控制去访问任何服务，但是约束委派只能去访问特定的服务，这个是在活动目录中被规定死的。因为非约束委派的中间服务器拿到的是客户端的 TGT。而约束委派的中间服务器手里没有客户端的 TGT，它必须依赖 Kerberos 扩展（S4U2proxy）向 KDC 申请后台服务的 ST。

Kerberos的两个拓展：

S4U2proxy：约束委派的核心，允许中间服务器用客户端发来的ST1向服务器请求一张目标服务的ST2。具体的实现流程如下

image.png

S4U2self：
在企业真实业务场景中，很多前端用户访问 Web 服务时，并不使用 Kerberos 协议，例如：
用户通过公网提交网页表单（账号密码）登录；
用户通过移动端、API Token、OAuth/SAML 认证登录；
用户通过 NTLM 身份验证登录。
用户已经在中间服务器证明了自己的权限，但是中间服务器没有拿到ST，无法进行下一步的认证。为了解决这个问题，微软就允许中间服务凭着自己的身份，替这个用户要一张，流程如下
image.png

基于资源的约束委派

首先基于资源的约束委派是完全基于约束委派的。并且如果开启了基于资源的约束委派，那么久默认开启了S4U2self拓展，(不是强制走S4U2self)。和前面的委派最大的不同就是，KDC多了一步对中间服务的校验，在中间服务向KDC请求ST2的时候，KDC判断中间服务的SID是否在目标服务的接受名单内，如果SID在被允许的资源当中，那么才会进行发放票据。

流程如下
image.png

标签: none