Kerberos 认证过程详细分析（二）

 8 分钟

此文于2022年1月28日更新。

被设置委派的账户必须拥有SPN

#非约束委派

#基本概念

Microsoft 在Windows 2000中实现了Kerberos 不受约束的委派。

服务1被配置了非约束委派，那么服务1可以接受任何用户的委派去请求其他任意服务。

例如：某个用户委托服务1访问某个服务，那么这个用户会将 TGT（可转发的）发送到服务1并缓存到服务1的LSASS中。 然后服务1利用此TGT 代表用户去请求服务。

分析非约束委派的请求前，解决上篇文章留的问题：为什么请求域控的CIFS 服务，会发两次TGS 请求？

因为域控机器账户默认情况下就已经被配置了非约束委派，所以用户请求配置了非约束委派的主机就会多请求一次forwarded TGT。

下图为请求域控CIFS 服务后，缓存的票据。

#请求流程分析

从上图的缓存票据就可以看到：#0 是forwarded TGT 票据，#1 是TGT票据，#2 就是服务票据。所以和正常的Kerberos 请求相比，就多出来一个请求已转发的TGT 票据。

  1. 用户通过AS_REQ请求TGT，认证成功后KDC 返回TGT。
  2. 用户带着TGT 请求服务票据（ST），KDC 返回服务票据。

到目前为止，1、2步骤和与请求未配置非约束委派的服务发送的内容都是相同的。（请求配置或未配置非约束委派的服务）它的AS_REQ 和TGS_REQ中 kdc-options字段的forwardable都为true）

  1. 用户带着步骤1请求的TGT，设置kdc-options 中Forwarded 字段为True并向KDC 发送TGS 请求。

    响应包中返回 forwarded TGT。

  2. 用户带着ST、forwarded TGT 请求域控的SMB 服务。

    在之前的SMB 请求的分析中，忽略了authenticator中的cksum字段。而forwarded TGT 就放在cksum字段下的krb-cred中。

    下图为Ticket 字段中的forwared TGT。

    除此之外，在enc-part 部分还有forwarded TGT 的一些基本信息。

  3. 这样域控上就会缓存这个forwarded TGT。

    如果这里不是域控，而是一个配置了非约束委派的普通账户，它就可以利用forwarded TGT 代表该TGT 中的用户去请求任意服务。（域控对服务账户非约束委派配置的检查应该在此账户带着forwared TGT 去请求服务的过程中）

#约束委派

微软在Windows 2003上发布了约束委派。 其中包括一组 Kerberos 协议扩展（S4U2Self 和 S4U2Proxy）。需要SeEnableDelegation特权才能配置约束和非约束委派。

#基本概念

约束委派会用到两个扩展 S4U2Self 和 S4U2Proxy。约束委派在配置的时候需要指定允许委派到某个服务。

例如: 服务1 只配置了到某个服务的约束委派，那么服务1可以模拟任何用户去请求该服务且仅能请求该服务。

收到用户的请求后，首先代表用户获得针对服务自身的可转发的kerberos服务票据(S4U2SELF)。拿着这个票据向KDC请求访问特定服务的可转发的TGS(S4U2PROXY)并代表用户访问特定服务。

整体流程

  1. 服务1以服务1账号hash加密时间戳并设置可转发的字段，再向KDC申请可转发的TGT。（不仅是约束委派，正常的TGT 申请都会带上可转发字段，并且返回的TGT 也是可转发的）
  2. 服务1携带可转发的TGT并使用S4U2self 扩展名代表用户（例如：Administrator）获得针对服务1本身的ST 票据（获得可转发的服务票据）。 S4U2Self (此阶段服务1不需要administrator的凭据)
  3. 服务1携带步骤1申请到的TGT和步骤2获取的可转发的ST 票据发送给KDC。请求代表用户访问服务2的ST 票据。 S4U2Proxy
  4. 服务1拿着步骤3获取的ST 票据代表用户administrator向服务2发起请求。

首先创建域用户test，设置SPN:setspn -A HOST/test test ，并配置test 到OWA2013.rootkit.org的CIFS服务的约束委派。

1
2

Rubeus.exe s4u /user:test /rc4:754234c8f5bf1f736099b0beed55b052 /impersonateuser:administrator /msdsspn:cifs/OWA2013.rootkit.org /ptt
dir \\OWA2013.rootkit.org\c$

Wireshark 抓包

#S4U2SELF

S4U2SELF 的作用其实是协议转换。例如任意用户通过其他协议（NTLM 或Web表单的身份验证等情况下）进行认证时，服务1来模拟（代表）用户对服务2完成身份验证。并且服务1是不需要模拟用户的账号密码等信息的。

上图中AS-REQ 与 AS-REQ 就是以test用户凭据去申请TGT，和之前的内容一样就不细说了。

第一个 TGS 请求就是利用S4U2SELF 协议，代表administrator 用户获取test服务的ST 票据。

TGS-REQ

  • 整体请求内容

    整体结构还是老样子

  • padata

    1
2

    PA-DATA pA-TGS-REQ: 这部分包含了test用户的TGT，和Login Session Key加密的时间戳等信息
PA-DATA pA-FOR-USER: 此结构标识模拟的用户（administrator）以及域名。

  • req-body

    可以看到发起请求的用户名是test，请求的服务也是test。

TGS-REP

任意服务账户都可以发起S4U2SELF请求。KDC 检查test 账户User-Account-Control属性的TrustedToAuthForDelegation 位，如果存在，则返回可转发（forwardable）的ST。如果不存在，也会返回ST ，只是没有可转发（forwardable）标志。

  • 整体响应内容

    可以看到cname 已经变成了administrator。ticket 则是test 服务的ST 票据。enc-part 不多说了，里面是Login Session Key 加密的Server Session Key。

如果administrator 被配置了敏感账户不能被委派，那么返回的ST 票据是不可转发的。导致后面的S4U2PROXY 会失败，并返回KDC_ERR_BADOPTION 错误。

#S4U2PROXY

只要用户被配置了敏感账户不能被委派，那么以此账户请求所有的TGT 和 ST 票据都是不可转发的。如果没有被配置此选项，那么默认在设置了kdc-option forwardable字段为true的情况下，返回的所有票据都是可转发的（forwardable）。约束委派中 S4U2PROXY 阶段需要的ST票据必须是可转发的。（基于资源的约束委派中S4U2PROXY 阶段需要的ST票据可转发或不可转发）

这一步代表administrator 用户（并使用test用户的TGT）去申请访问域控 CIFS 服务的ST 票据。S4U2SELF 阶段获取的test服务的ST 票据将作为此阶段的AddtionTicket，一起发送给KDC。

  • 整体请求内容

  • padata

    这块这之前一样，没什么多的东西。只是要注意这里的ticket是test用户的TGT。

  • req-body

    可以看到多出来了一个additional-tickets字段。这个字段的ticket就是S4U2SELF获取到的ST票据（必须是有可转发字段的）。并且kdc-option字段中要设置constrained-delegation: True 。

在S4U2PROXY阶段，KDC 会检查test 服务msDS-AllowedToDelegateTo属性，检查域控OWA2013.rootkit.org是否在该属性中。验证成功，则返回域控的服务票据。

#基于资源的约束委派

基于资源的约束委派只能在运行Windows Server 2012 R2和Windows Server 2012的域控制器上配置，但可以在混合模式林中使用。约束委派不能跨域进行委派，基于资源的约束委派可以跨域和林。约束与非约束委派需要域管理员才能设置，而基于资源的约束委派则不需要域管理员权限，把设置属性的权限赋给了机器自身。

基于资源的约束委派与传统约束委派配置相反。服务1到服务2的约束委派在服务1账户的msDS-AllowedToDelegateTo属性中配置，定义从服务1到服务2的传出信任。基于资源的约束委派是在服务2的msDS-AllowedToActOnBehalfOfOtherIdentity属性中配置，定义从服务1到服务2的传入信任。只要拥有服务2的权限就可以配置服务2的基于资源的约束委派。

DC 上配置PC-MICLE-KIT$账号到Srv-Web-Kit$机器账号的基于资源的约束委派。

1
2
3
4

Set-ADComputer Srv-Web-Kit -PrincipalsAllowedToDelegateToAccount PC-MICLE-KIT$
Get-ADComputer Srv-Web-Kit -Properties PrincipalsAllowedToDelegateToAccount
#以test账号模拟administrator用户的约束委派请求
Rubeus.exe s4u /user:PC-MICLE-KIT$ /rc4:a15bc42b9f1f1daa812a0b75a4c775c4 /impersonateuser:administrator /msdsspn:cifs/Srv-Web-Kit.rootkit.org /ptt

基于资源的约束委派还是用的是S4U2SELF和S4U2PROXY 协议。只是变成了从服务1账号属性配置允许哪些服务账号能对服务1进行约束委派。

归根结底还是约束委派：首先以PC-MICLE-KIT$账号申请TGT，再模拟administrator 用户申请访问PC-MICLE-KIT$的ST票据。并带着此ST 票据向KDC 申请访问Srv-Web-Kit.rootkit.org 服务的ST 票据。

说一下不同点:

  1. S4U2SELF 阶段

    和常规约束委派不通的是，此阶段返回的ST 票据是不可转发的。

  2. S4U2PROXY 阶段（此阶段发的内容和传统约束委派基本是一样的）

    • 指定resource-based-constrained-delegation: True 。
    • 和传统约束委派一样，在additional-tickets 字段中添加上一步获取的不可转发的ST票据。
    • KDC 会检查Srv-Web-Kit服务的msDS-AllowedToActOnBehalfOfOtherIdentity属性是否配置了PC-MICLE-KIT$ 账号的sid。

相关文章：

加载评论