具体认证流程：
1、用户机器向KDC请求可转发的TGT1
2、KDC在消息中给返回TGT1（访问服务1使用）
3、用户通过TGT1请求转发TGT2（访问服务2使用）
4、KDC返回消息TGT2
5、用户使用TGT1向KDC申请访问服务1
6、TGS 返回 ST 给用户
7、用户发送AP_REQ请求服务1，包含了TGT1、TGT2、TGT2的sessionkey
8、服务1使用用户发送过来的TGT2去请求KDC，并以用户的身份请求服务2的ST
9、KDC返回服务2的ST给服务1（这里ST将来源请求标记为用户机器，而不是服务1）
10、服务1以用户的名义请求服务2
11、服务2回应服务1请求
12、服务1回应用户机器请求
13、服务1能够向KDC请求其他服务ST
14、KDC返回其他服务ST
15、服务1以用户名义请求其他服务
16、其他服务回应服务1

原理：

机器A（域控）访问具有非约束委派权限的机器B的服务，会把当前认证用户（域管用户）的的TGT放在ST票据中，一起发送给机器B，机器B会把TGT存储在lsass进程中以备下次重用。从而机器B就能使用这个TGT模拟认证用户（域管用户）访问服务。

利用场景

攻击者拿到了一台配置非约束委派的机器权限，可以诱导域管来访问该机器，然后得到管理员的TGT，从而模拟域管用户。

复现配置：

参考：https://developer.aliyun.com/article/1228233

1、信任此计算机来委派任何服务

2、setspn -U -A MSSQLSvc/mssql.hack.com:1433 test2

开启服务账号test2的委派设置：

设置机器账号为委派：

注意：只有服务账号和主机账号能设置委派

当设置成功后，账号的userAccountControl属性会包含TRUSTED_FOR_DELEGATION

判断查询：

查询域内设置了非约束委派的服务账户：

AdFind -b “DC=god,DC=org” -f “(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))” dn

查询域内设置了非约束委派的机器账户:

AdFind -b “DC=god,DC=org” -f “(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))” dn

利用思路1：诱使域管理员访问机器

利用条件：

1、需要Administrator权限

2、域内主机的机器账户开启非约束委派

3、域控管理员远程访问（主动或被动）

利用过程：参考https://forum.butian.net/share/1591

约束委派

原理：

由于非约束委派的不安全性，微软在windows server 2003中引入了约束委派，对Kerberos协议进行了拓展，引入了SService for User to Self (S4U2Self)和 Service for User to Proxy (S4U2proxy)。

S4U2self：

当服务账户开启了约束性委派时，那么该服务就可以代表访问到该服务的用户请求针对其自身的服务票据(ST)，也就是说当user1访问到了服务1，服务1以s4u2self的方式向KDC请求一张可以以user1身份访问自身服务1的、可用于转发的票据，实际还是访问的服务1，但是借助了user1的身份，目的就是拿到user1的授权数据，如果user1是以其他认证方式对服务1进行认证的（web、ntlm等），是获取不到访问服务1自身的st票据的，所以s4u2self就是用来解决这个问题的。

S4U2proxy：

服务1可以以用户的名义请求其它服务的ST，和self最大的区别就是self是请求自身服务，当需要以user1的身份访问其他服务，就需要s4u2proxy上场了，而约束委派就是限制了S4U2proxy扩展的访问范围

流程

（1）用户向 Service1 发出请求，用户已通过身份验证，但 Service1 没有用户的授权数据，这通常是由于用户的身份验证是通过 Kerberos 以外(基于表单的 web 认证、NTLM 认证等)的其他方式验证的。
（2）Service1 已经通过 KDC 进行了身份验证，并获得了 TGT 认购权证。它通过S4U2self 协议代表用户向 KDC 请求一张访问自身 Service1 服务的可转发 ST 服务票据。
（3）KDC 返回给 Service1 一张访问 Service1 自身服务的可转发 ST1 服务票据，就像是用户使用自己的 TGT 认购权证请求的一样，该可转发的 ST1 服务票据可能包含用户的授权数据。
（4）Service1 可以使用 ST1 服务票据中的授权数据来满足用户的请求，然后响应用户。
（5）用户向 Service1 发出请求，请求访问 Service2 上的资源。
（6）Service1 利用 S4U4Proxy 协议以用户的名义向 KDC 请求访问 Service2 的ST2 服务票据，该请求中带上了可转发的 ST1 服务票据
（7）如果请求中存在 PAC 特权属性证书，则 KDC 通过检查 PAC 结构的签名数据来验证 PAC。如果 PAC 有效或不存在，KDC 返回 Service2 的可转发 ST2 服务票据，并且存储在 ST2 服务票据中的 cname 和 crealm 字段中的客户端标识是用户，而不是 Service1。
（8）Service1 以用户身份使用可转发 ST2 服务票据向 Service2 发起请求。
（9）Service2 响应步骤 8 的请求。
（10）Service1 响应用户对步骤 5 中的请求。

利用场景：

如果攻击者控制了服务A的账号，并且服务A配置了到域控的CIFS服务的约束性委派。

则攻击者可以先使用S4u2seflt申请域管用户（administrator）访问A服务的ST1，然后使用S4u2Proxy以administrator身份访问域控的CIFS服务，即相当于控制了域控。

复现配置：参考https://developer.aliyun.com/article/1228237?spm=a2c6h.24874632.expert-profile.7.2fe45662aTMdZv

1、机器设置仅信任此计算机指定服务-cifs

2、用户设置仅信任此计算机指定服务-cifs

配置服务账户test2对域控机器PANDA的特定服务cifs的约束性委派

不过在实际环境中，基本不会有企业会这么配置的，所以约束性委派用的也不是很多

当服务账号或者主机被设置为约束性委派时，其userAccountControl属性会包含TRUSTED_TO_AUTH_FOR_DELEGATION

而且msDS-AllowedToDelegateTo属性会包含被约束的特定服务

利用思路：使用机器账户票据

利用条件：

kekeo Rubeus getST

1、需要Administrator权限

2、目标机器账户配置了约束性委派

判断查询：

查询机器用户（主机）配置约束委派

AdFind -b “DC=god,DC=org” -f “(&(samAccountType=805306369)(msds-allowedtodelegateto=*))” msds-allowedtodelegateto

查询服务账户（主机）配置约束委派

AdFind -b “DC=god,DC=org” -f “(&(samAccountType=805306368)(msds-allowedtodelegateto=*))” msds-allowedtodelegateto

kekeo利用步骤：参考https://forum.butian.net/share/1591

基于资源的约束委派

基于资源的约束委派(RBCD)是在Windows Server 2012中新加入的功能，与传统的约束委派相比，它不再需要域管理员权限去设置相关属性。RBCD把设置委派的权限赋予了机器自身，既机器自己可以决定谁可以被委派来控制我。也就是说机器自身可以直接在自己账户上配置msDS-AllowedToActOnBehalfOfOtherIdentity属性来设置RBCD。

所以核心就是谁或什么权限能修改msDS-AllowedToActOnBehalfOfOtherIdentity

简单的讲，也就是如果攻击者能够在data的机器上设置msDS-AllowedToActOnBehalfOfOtherIdentity属性为ServiceA，

也就允许ServiceA利用s4u2self协议代表其他用户身份来访问data的话，那我们就可以做到横向移动及提权等操作。

以下这些拥有配置msDS-AllowedToActOnBehalfOfOtherIdentity属性的权限：1.将某机器加入域的域用户2.机器自身3.域管理员

流程

1）服务A使用自己的服务账户和密码向KDC申请一个可转发的TGT
2）服务A利用S4u2Self协议代表用户申请一个访问自身的ST。这一步区别于传统的约束性委派。在S4uSelf协议中提到，返回的ST可转发的一个条件是服务A配置了传统的约束性委派。KDC会检查服务A的msDS-AllowedToDelegateTo字段，如果这个字段被赋值了，则KDC返回可转发的ST。但是由于这里是基于资源的约束性委派，是在服务B上配置的，服务B的msDS-AllowedToActOnBehalfOfOtherIdentity属性配置了服务A的SID，服务A并没有配置msDS-AllowedToDelegateTo字段，因此KDC返回的ST是不可转发的
3）服务A利用S4u2Proxy协议以用户身份向KDC请求访问服务B的可转发ST（上一步获得的不可转发ST放在请求包的AddtionTicket中）。KDC返回访问服务B的可转发ST。
4）服务A用上一步获得可转发ST访问服务B

我们可以利用域用户添加一个机器账户作为服务1，注意是机器账户，不是普通账户，普通账户没有SPN，因为S4U2self协议会用到SPN，而且通过S4U2Self得到的ST服务票证是不可被转发的，而S4U2Proxy的作用就是将可转发的ST票据转发到其他服务进行委派认证的，但是在基于资源的约束委派过程中，不可转发的ST仍可以通过S4U2Proxy转发到其他服务进行委派认证，并且最后还会返回一张可转发的ST服务票证，如果我们可以在服务2上配置允许服务1的资源约束委派，就可以通过服务1利用S4U2self向KDC请求用于访问自身的票据，在使用S4U2Proxy转发此票据去请求访问服务2的票据，最终就可以模拟任何用户去访问服务2了

通过资源约束委派可以通过普通域用户权限以管理员的身份去访问特定主机的服务(cifs等)，可以实现本地权限提升，但是不能完全具有域管的所有权限(如进行dcsync等)，或者利用资源约束委派横向拿下所有被该普通域用户拉进域内的机器权限

复现配置：参考https://developer.aliyun.com/article/1228243?spm=a2c6h.24874632.expert-profile.6.2fe45662aTMdZv

用一个域用户test2将机器加入域中

去查看机器用户的mS-DS-CreatorSID属性，域用户拉进来的都有这个属性，如果没有说明是被域管理员拉进来到域内中的

利用条件：

1.机器账户：是由某个域用户创建的主机，只要拿下这个域账户，那么就能拿下这个域用户所创建的所有机器账户的最高权限（默认每个域用户能创10个机器账户）

2.拥有一个有权修改msDS-AllowedToActOnBehalfOfOtherIdentity属性的域用户账号密码(将机器拉进域的域用户)、或者在account operators组内的域用户

3.域控需要是server2012和2012 R2以上的（因为2008及以下没有msDS-AllowedToActOnBehalfOfOtherIdentity属性）

4.任意用户对该主机的属性具有写权限，那么这个用户就可以对该主机进行攻击，所以可以枚举域内ACL策略，查看哪些对主机有GenericAll权限，GenericWrite、WriteProperty、WriteDacl等等权限，都是可以的

判断是否有利用条件：

查询被域用户创建的机器账户列表:

shell AdFind.exe -b “DC=xiaodi,DC=local” -f “(&(samAccountType=805306369))” cn mS-DS-CreatorSID

根据查询出来的sid找出对应的用户名：

shell AdFind.exe -b “DC=xiaodi,DC=local” -f “(&(objectsid=S-1-5-21-1695257952-3088263962-2055235443-1104))” objectclass cn dn