前言
委派一般出现在域环境中。它是一种机制，在kerberos认证的时候会涉及到。不正确的委派的配置，可能使攻击者达到提权的目的。
委派
假设域内用户A需要访问服务器B，并需要以A的身份对服务器的端数据库进行更改。则A就会进行一个kerberos认证，来获取访问B的ticket。这时候就需要用到委派，也就是说，A依旧访问B且只申请一个访问B的ticket，这时候再委托B来代表A对数据库进行一些修改。这个“A委托B做事情”的行为，我们称之为委派，这是一种正常的操作。
一些问题
KDC可以确定A是否有访问服务B的权限，这时候就得有一个方法来让KDC知道A允许B代表自己来“做事情”，这句话可能有点绕，可以多看几遍。这时候S4U2SELF与S4U2PROXY这两个东西就出现了。
S4U2SELF
这个东西在TGS_REQ这个阶段中，S4U2SELF是这个数据包的一部分内容。
S4U2SELF一般是一个值，例如Administrator等。当配置了这个值并且服务器B获得了可转发的TICKET票据后，服务器B就可以代表Administrator进行操作。配置这个值可以自己配置，那么获得可转发的TICKET票据有什么条件呢？
1.一个可转发的服务器B的TGT。
2.当前服务器B配置了约束委派，如下图所示：
3.服务B在TGS_REQ阶段设置了forwardable选项
这些都能自己设置，那岂不是可以伪造任意用户对当前服务B进行操作了？其实不是的，倘若目标用户被设置成敏感账户，不能被委派，则TICKET的FLAG字段肯定没有forwardable，也就是说条件3是无法满足的，于是不能伪装成此用户。
延伸
如果我们能伪装成任意用户，那么就能以任意用户的权限来操作当前服务器B。
S4U2PROXY
S4U2PROXY也是在TGS_REQ阶段的一个参数。S4U2PROXY可以使当前主机代表其他用户来访问其他主机，相比较于S4U2SELF，范围大了很多，当然“代表”肯定也是有限制条件的。大概过程如下：
要想使用S4U2PROXY必须得经过S4U2SELF阶段，需要获得那个可转发的TICKET,这个TICEKT会放在TGS_REQ中的additionTicket中。
假设当前主机为b，接受了administrator的委派。主机B将这个TGS_REQ请求发送给KDC并获得访问其他主机例如主机C的权限。此时主机B可以访问主机C能且只能代表administrator访问主机C。如果想代表administrator访问其他主机，还得重复之前的操作。
上面这些是大概流程，具体需要达成的条件为：
1.S4U2SELF阶段生成的可转发的TICKET
2.在TGS_REQ阶段设置CNAME-IN-ADDL-TKT标志
3.在TGS_REQ阶段设置forwardable标志
4.服务1 有到服务2的非约束委派，将服务2的SPN放在sname里面。
S4U2proxy 必须扩展PAFORUSER结构，指定服务代表某个用户去请求针对服务自身的kerberos服务票据。
PA-PAC-OPTION
类型是 PAPACOPTIONS
值是以下flag的组合
— Claims(0)
— Branch Aware(1)
— Forward to Full DC(2)
— Resource-based Constrained Delegation (3)
如果是基于资源的约束委派，就需要指定Resource-based Constrained Delegation位。
非约束性委派
当前主机可以模仿某个用户去访问任意服务。需要配置如下：
如果admin委派服务器B来代替自己访问其他服务，则admin会先将自己的TGT发送给服务器B存储在lsass中。
约束性委派
约束委派将限制指定的服务器才能代表用户。具体配置如下：
若服务器B被配置了约束性委派，则它可以接受任何用户对于某些特定服务的委派。先经过S4U2SELF阶段拿到一个可转发的TICKET，然后再经过S4U2PROXY阶段，这时候就能代表用户访问特定服务了，这个特定的服务是windows提前定义好的，不像非约束性委派那么自由。配置了约束委派的用户的userAccountControl 属性有个FLAG位 TrustedToAuthForDelegation 。约束的资源委派，除了配置TRUSTEDTOAUTHFORDELEGATION 之外，还有个地方是存储对哪个spn 进行委派的，位于msDS-AllowedToDelegateTo。
确定哪些服务可以通过委派访问一般是域管决定的，具体是拥有SeEnableDelegation权限的人决定，这个人一般是域管。
基于资源的约束性委派
基于资源的约束委派将委派的控制权交给拥有被访问资源的管理员。比如约束性委派中，域管能限制主机A可代表他人访问哪些主机。而基于资源的约束性委派实现跟他相反，假如我是当前主机的管理员，我就可以设定，谁可以被委派访问我的主机。
举个例子如果是服务器C配置了服务器B可以访问其资源。那么如果我们站在服务器B的角度，整个流程如下：
服务器B进行S4U2SELF，但与传统但委派不同，它最终会获得一个无法转发但TICKET，这时候进行S4U2PROXY阶段，需要将PA-PAC-OPTION里面但RBCD标识为设为1即可。
基于委派的攻击
非约束委派攻击
因为如果一个主机可以接受非约束性委派，那么访问这个主机的用户都会将自己的TGT传送给此主机。如果我们找到配置了非约束的委派的账户，并且通过一定手段拿下该账户的权限，然后诱导域管访问该主机，这个时候域管会将自己TGT发送到主机并缓存到LSASS中，那我们就可以从LSASS中导出域管的TGT票据，然后通过PTT，从而拥有域管的权限。
约束委派攻击
如果我们找到配置了约束委派的服务账号，并且通过一定手段拿下该账号所在的主机。我们就可以利用这个服务账号代表任意用户进行s4u2self获得一个可转发的TICKET，然后把获取到的票据用于s4u2proxy(作为AddtionTicket)，从而获得另一个可转发的TICKET，服务利用这个TICKET就可以代替任意用户访问那个被配置为约束委派的服务。
基于资源的约束委派攻击
普通的约束委派的配置需要SeEnableDelegation权限，而这个权限通常仅授予Domain Admins。因此我们对普通的约束委派的利用，往往在于寻找域内已有的约束委派，再利用。但是对于基于资源的约束委派，假如我们已经拥有服务账号1，那么只要我们具备用户2的LDAP权限，这样就可以配置服务1对服务2的约束委派(在服务账户2的用户属性上配置msDS-AllowedToActOnBehalfOfOtherIdentity为1的sid)，服务1就可以控制服务2。
所以基于资源的约束委派的利用，就有一种新的攻击思路
1.我们拥有一个任意的服务账户1 或者计算机账户1
这一步不难，我们我们拥有域内机器，提升到system权限，该计算机用户，用户名为计算机账号$就是服务账号。如果我们只有普通的域内用户，可以滥用MachineAccountQuota，工具Powermad可以实现。
2.我们获得服务账户2 的LDAP权限
这一步可以结合ntlm relay，从其他协议relay 而来，关于这一步，更多的是ntlm relay的过程，限于篇幅原因，这里面会在ntlm篇的relay详细介绍。典型案例就是CVE2019-1040。
3.配置服务1对服务2的约束委派
在服务账户2的用户属性上配置msDS-AllowedToActOnBehalfOfOtherIdentity为服务账户1的sid。
4.发起一个从服务1到服务2的正常的约束委派的流程，从而访问服务2。
这个流程见上面的约束委派，使用rubeus也可以很方便得进行一键访问。