写在最前

如果你是信息安全爱好者，如果你想考一些证书来提升自己的能力，那么欢迎大家来我的 Discord 频道 Northern Bay。邀请链接在这里：

https://discord.gg/9XvvuFq9Wb

我会提供备考过程中尽可能多的帮助，并分享学习和实践过程中的资源和心得，大家一起进步，一起 NB~

---

背景

这篇文章，我会写一下 Active Directory 中的三种 Delegation（委派），同时会讲到 Protocol Transition 对于 Delegation 影响。

强烈建议先阅读我的上一篇文章，Active Directory 02 - Windows Kerberos Authentication（Kerberos 协议鉴权），先对 Kerberos 鉴权机制有一个了解，再继续深入到本章。

Active Directory Delegation

Active Directory Delegation 分为三种。

1. Unconstrained Delegation（无约束委派）
2. Constrained Delegation（约束委派）
3. Resource-Based Constrained Delegation（基于资源的约束委派）

我们先看一下 Delegation 为什么会存在。

为什么需要 Delegation

回答这个问题，我们需要知道 Active Directory 中的 double-hop scenario（双跳问题）。

考虑如下场景，有一个用户，两个服务（Web - Service 1，MSSQL Server - Service 2）。用户访问 Service 1，Service 1 需要访问 Service 2 来获取数据。这种情况下，因为用户是不能直接访问到 Service 2（MSSQL Server 是绝对不会暴露给公网）的，所以 Service 1 必须代表该用户来向 KDC 获取 Service 2 的访问权限。

回想上一篇文章，用户想要访问一个服务，必须向 KDC 拿到这个服务的 TGS（解剖获取 Ticket Granting Service（TGS）的过程），这个过程需要用户向 KDC 出示他的 TGT。

回到这个场景，当用户访问 Service 1 的时候，出示了加密的时间戳，用户名，以及 TGS，其中没有用户的 TGT。因此，当 Service 1 需要访问 Service 2 的时候，没有用户的 TGT，它无法代表该用户向 KDC 申请 Service 2 的使用权（TGS）。

这就是 double-hop scenario。

而 Delegation 就是微软为了解决这个问题而添加的特性。

Delegation 能让 Service 1 代表该用户申请 Service 2 的使用权并访问 Service 2。

Delegation 的设置非常简单，在 Active Directory Users and Computers 界面中，双击打开任一服务，选择 Delegation 标签，就能为这个服务配置 Delegation 的各个选项。

接下来，我们就一一讨论一下。

Unconstrained Delegation

从安全角度来说，在非绝对必要的情况下，都不要使用 Unconstrained Delegation。

因为当一个服务被配置成 Unconstrained Delegation，用户向 KDC 申请该服务的 TGS 时，KDC 会将用户的 TGT 会嵌入到其 TGS。当用户访问服务时，TGT 就会随 TGS 一起发送给该服务。这个服务会取出这个 TGT，放入 LSASS 保存。在这个 TGT 过期之前，这个服务就可以代表整个用户，访问任意他可以访问的服务。

对于 Unconstrained Delegation 的危险，Jake Karnes 提到了 Will Schroeder 和 Sean Metcalf 的研究，可以进一步学习。

利用 Unconstrained Delegation

如果你拿下了一个 Unconstrained Delegation 服务，你可以等待（或者社工，钓鱼，发挥想象） Domain Admin 用户访问这个服务。那么你就有了 Domain Admin 的 TGT，也就拿下了整个域。

另外，也可以尝试规避检测，利用 Printer Spooler 拿到 Domain Controller 的 TGT，然后 DCSync。

Constrained Delegation

由于 Unconstrained Delegation 太危险，从 Windows Server 2003 开始，微软增加了 Constrained Delegation。

Constrained Delegation 会让管理员限制当前服务，只能代表用户，申请并访问指定的服务。这些目标服务会出现在该服务的 msDS-AllowedToDelegateTo 属性当中。

当用户访问 Constrained Delegation 服务的时候，他的 TGT 不会出现在他的 TGS 中一起发送。

那既然整个服务没有了用户的 TGT，它怎么跟 KDC 申请其他服务的 TGS 呢？

S4U（MS-SFU） 规范

为了解决上述问题，微软加入了 MS-SFU 规范 。整个规范推出了两个协议，S4U2Proxy，以及 S4U2Self。

S4U2Proxy 协议

有了 S4U2Proxy，一个服务只需要获取用户的 TGS（用户在访问服务的时候即会发送），即可代表该用户（因为 TGS 中有该用户的用户名）向 KDC 申请其他服务的使用权。

整个过程如下图。

上图中，Service 1 被配置成 Constrained Delegation，目标是 Service 2，并且用户已经访问了 Service 1。Service 1 现在持有用户的 Service Ticket。

步骤说明：

1. Service 1 将 用户的 Service Ticket 以及 自己的 TGT 发送给 KDC，代表用户申请 Service 2 的 TGS；
2. KDC 校验 Service 1 发送来的数据，校验通过，发送 用户的 Service Ticket（用于访问Service 2） 给 Service 1；
3. Service 1 代表用户向 Service 2 发起 Application Request（AP_REQ），发送刚才获取的 TGS；
4. Service 1 现在可以访问和使用 Service 2；

这就是 S4U2Proxy 协议的作用。

我们举例说明：

Web 服务器被配制成 Constrained Delegation；Use Kerberos only，委派目标是 MSSQL Server。

张三使用 Kerberos 协议对 Web 服务器发起访问，将张三的 TGS 发送给 Web 服务器。Web 服务器使用张三的 TGS，代表张三向 KDC 发起请求，试图获取张三对于 MSSQL Server 的使用权；KDC 对信息进行校验，交验通过，KDC 将张三可访问 MSSQL Server 的 TGS 发送给 Web 服务器。那么这时，Web 服务器就可以代表张三，和 MSSQL Server 交互了。

说完了 S4U2Proxy，上文还提到了另一个协议，叫 S4U2Self。

这个是干什么用的呢？这就要引出另一个概念： Protocol Transition。

Protocol Transition

再借用一下上文的图片。

可以看到下方大粗红框中的两个 Protocol Transition 选项，是只有在 Constrained Delegation 时才能勾选。

第一个选项叫做 Use Kerberos only，第二个选项叫做 Use any authentication protocol。

在解释他们的作用前，我们先简单介绍下域环境的鉴权方式。

Active Directory Authentication Method

域环境的鉴权方式有两种。主要的鉴权方式，当然是 Kerberos V5 协议。但是，就像微软官方文档所说，AD 环境，仍然允许使用 NTLM 方式（或者任意被允许的鉴权方式）做鉴权。

我们以 NTLM 鉴权为例，那么两种鉴权方式有什么不同呢？

很简单，Kerberos 鉴权，像上一篇文章中提及的，鉴权双方会交换票据（TGT，或者 TGS），而 NTLM 鉴权不会。

那么我们回顾一下，上文写到 S4U2Proxy 的使用过程时，我们默认是使用 Kerberos 协议做鉴权，所以用户会将他的 TGS 发送给 Service 1。接着，Service 1 可以使用该用户的 TGS 来向 KDC 申请 Service 2 的使用权。整个过程都使用 Kerberos，第一个服务只需要使用 S4U2Proxy 协议完成第二服务的鉴权。

如果用户使用 NTLM 方式和 Service 1 做鉴权呢？那么 Service 1 就不会有用户的 TGS。这时，就要使用上文提及的第二个协议，S4U2Self 来完成鉴权过程。像这样可以使用多协议（Kerberos，NTLM）进行鉴权，就是 Protocol Transition。

我们先总结一下什么是 Protocol Transition，然后继续对 S4U2Self 过程的探索：

Protocol Transition，就是允许使用多种方式进行鉴权，第一服务可以使用 S4U2Self 协议，代表用户向 KDC 请求该用户对于自身的 TGS；然后再使用该 TGS，通过 S4U2Proxy 协议，完成对第二服务的鉴权

这里的鉴权，就理解成主体（用户或者服务）请求其他服务的访问权限的过程。

因此

• Use Kerberos only 选项，就是限制整个鉴权过程，全部都使用 Kerberos 协议。服务只接受 Kerberos 鉴权，只能依赖 S4U2Proxy 协议 完成对第二服务的访问请求；我们称这种单一鉴权方式为 Constrained Delegation without Protocol Transition；
• Use any authentication protocol 选项，就是允许用户使用 NTLM（或者任何可以使用的鉴权技术） 与第一个服务做鉴权。第一服务可以使用 S4U2Self 协议 代表用户先获取对于自身的 TGS。 我们称这种混合鉴权方式为 Constrained Delegation with Protocol Transition；

回忆上文第一个具体例子，Web 服务器的配置就是 Constrained Delegation without Protocol Transition，只使用 Kerberos 进行鉴权。

下面我们看一下，在 Constrained Delegation with Protocol Transition 情况下，S4U2Self 协议的原理。

S4U2Self 协议

有了 S4U2Self ，第一服务可以将自己的 TGT，加密的时间戳，以及用户名（访问该服务的用户），发送给 KDC，如果校验成功，KDC 会返回一张带有用户名的 TGS；第一服务再使用 S4U2Proxy 协议，完成对第二服务的鉴权

步骤说明：

1. 第一服务使用 logon session key（紫色） 加密当前时间戳；
2. 第一服务向 KDC 发送时间戳，自己的 TGT，以及用户名（访问第一服务的用户）；
3. KDC 用 KDC Key（灰色） 解密 TGT；
4. KDC 取出 TGT 中第一服务的 logon session key（紫色）；
5. KDC 用 logon session key（紫色） 解密时间戳，做校验；
6. 校验成功，KDC 生成一个随机的 service session key（黄色）；
7. KDC 将用户的 TGS 发送给第一服务；

这就使用 S4U2Self 鉴权的过程。

我们再举例说明：

Web 服务被配置成了 Constrained Delegation； Use any authentication method，也就是 Unconstrained Delegation with Ptotocol Transition，委派目标仍就是 MSSQL Server。张三使用 NTLM 访问 Web 服务器。Web 服务器没有张三的 TGS，但是由于服务器配置成 with Ptotocol Transition，所以 Web 服务器就使用 S4U2Self，使用自己的 TGT，向 KDC 索取张三访问 Web 服务器自身的 TGS。KDC 校验通过，将张三访问 Web 服务器的 TGS 发送给 Web 服务器。此时，情况就和上一个例子相同了。Web 服务器继而使用 S4U2Proxy 协议，向 KDC 索取张三访问 MSSQL Server 的 TGS。KDC 校验通过，将张三可以访问 MSSQL Server 的 TGS 返回给 Web 服务器。此时，Web 服务器就可以代表张三，和 MSSQL Server 交互了。

这就是 Constrained Delegation 自身以及涉及的其他重要概念。

Resouce-Based Constrained Delegation（RBCD）

Resouce-Based Constrained Delegation（以下简称 RBCD），是自 Windows Server 2012 起，微软对于 Constrained Delegation 的改进。主要目的还是为了标齐最小权限原则。

为了可以配置 Constrained Delegation，操作账户必须有 SeEnableDelegationPrivilege权限（通常只会出现在 Domain Admin 身上）。想象一下如果一个普通账户拥有 SeEnableDelegationPrivilege 权限并且被攻破，那么黑客就可以任意为主体配置 Delegation，后果会相当严重。

为了限制这个敏感权限的使用，微软将委派的主动权交到了后方服务的手里。后方服务现在有能力接受指定服务的委派，不再需要 **SeEnableDelegationPrivilege ** 权限。RBCD 中配置的前端服务的 SID，都将出现在后方服务主体的 msDS-AllowedToActOnBehalfOfOtherIdentity property 属性当中。

这个改变可以用下图来说明。一句话概括，就是 Constrained Delegation 是一对多，而 RBCD 转变为了多对一。

RBCD 其本质也是 Constrained Delegation，所有涉及 S4U 协议的交互都是一样。

不同的是：

1. 在 RBCD 中，KDC 会检查第一服务的 SID，是否存在于第二服务的 msDS-AllowedToActOnBehalfOfOtherIdentity property 属性当中；
2. 前端服务必须在域中配置 SPN；

至此，关于 3 种 Delegation 我们就讲完了。今后会视情况而定，总结一下 3 种 Delegation 的利用。

总结

这片文章，我们写到了 Active Directory 中的 3 种不同的 Delegation 模式，他们各自的特性，涉及的概念。

在清楚了 Kerberos 鉴权过程和 Delegation 之后，下一篇文章，我们就可以基于对这些概念的理解，探讨一下 Bronze Bit Attack（CVE-2020-17049）。

附录

Constrained Delegation 概念一览

概念	解释
with Protocol Transition	即 Use any authentication protocol；只适用于 Constrained Delegation；被配置主体接受其他主体使用不同的方式进行鉴权，包括 Kerberos，NTLMv2 等；委派过程中，可以使用 S4U2Self 和 S4U2Proxy 协议对目标主体进行鉴权
without Protocol Transition	即 Use Kerberos only；只适用于 Constrained Delegation；被配置主体只接受其他主体使用 Kerberos 方式进行鉴权；委派过程中，只能使用 S4U2Proxy 协议对目标主体进行鉴权
Use Kerberos only	即 without Protocol Transition；只适用于 Constrained Delegation；被配置主体只接受其他主体使用 Kerberos 方式进行鉴权；委派过程中，只能使用 S4U2Proxy 协议对目标主体进行鉴权
Use any authentication protocol	即 with Protocol Transition；只适用于 Constrained Delegation；被配置主体接受其他主体使用不同的方式进行鉴权，包括 Kerberos，NTLMv2 等；委派过程中，可以使用 S4U2Self 和 S4U2Proxy 协议对目标主体进行鉴权
S4U2Proxy	只适用于 Constrained Delegation；主体使用该协议，通过用户的 TGS 向 KDC 发起第二服务的鉴权
S4U2Self	只适用于 Constrained Delegation with Protocol Transition；主体使用该协议，先向 KDC 获取用户对于自身的 TGS；然后使用该 TGS，使用 S4U2Proxy 协议，向 KDC 发起第二服务的鉴权
SeEnableDelegationPrivilege	配置 Constrained Delegation时，管理账户必须拥有的权限；在 RBCD 中无须具备；

参考链接

• https://www.netspi.com/blog/technical/network-penetration-testing/cve-2020-17049-kerberos-bronze-bit-theory/
• https://harmj0y.medium.com/s4u2pwnage-36efe1a2777c
• https://adsecurity.org/?p=1667
• https://adsecurity.org/?p=4056
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/3bff5864-8135-400e-bdd9-33b552051d94
• https://learn.microsoft.com/en-us/windows-server/security/kerberos/ntlm-overview
• https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-nlmp/5e550938-91d4-459f-b67d-75d70009e3f3
• https://learn.microsoft.com/en-us/archive/msdn-magazine/2007/january/security-using-protocol-transition-tips-from-the-trenches
• https://learn.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/enable-computer-and-user-accounts-to-be-trusted-for-delegation
• https://www.elastic.co/guide/en/security/master/sensitive-privilege-seenabledelegationprivilege-assigned-to-a-user.html