RBCD (Resource-Based Constrained Delegation) 是一种允许资源所有者（服务）自主决定谁可以委派给它的安全机制。其核心在于目标计算机对象的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性。如果计算机 A 的该属性中包含了账户 B 的 SID，那么账户 B 就可以代表任意域用户向计算机 A 申请服务票据。
1. 核心原理
与传统委派不同，RBCD 将控制权从“前端服务”转移到了“后端资源”。
- 配置位置：目标机器（资源）的属性上，而非发起委派的用户上。
- 鉴权逻辑：当一个用户尝试访问服务 A 时，如果 A 拥有目标机器 B 的 RBCD 配置权限，A 就可以通过 S4U2self 和 S4U2proxy 协议流程，代表任意域用户（包括域管）获取访问 B 的 Service Ticket。
- 权限需求：修改该属性需要对目标计算机对象拥有
GenericAll、GenericWrite或WriteProperty权限。
2. 利用细节分析
A. 常规打法：利用 MachineAccountQuota (MAQ)
这是最通用的路径。
- 原理：默认情况下，普通域用户可以将最多 10 台机器（
MAQ默认值为 10）加入域。 - 细节：
- 利用现有权限创建一个伪造的机器账户（具有 SPN）。
- 利用对目标机器的
WriteProperty权限，将该伪造机器账户的 SID 写入目标机器的msDS-AllowedToActOnBehalfOfOtherIdentity。 - 使用伪造机器账户发起 S4U 请求。
B. 有 SPN 修改权限：绕过 MAQ 限制
当 MAQ=0 时，无法新建机器账户，此时需寻找“现成”账户。
- 原理：RBCD 要求发起委派的对象必须拥有 ServicePrincipalName (SPN)。
- 细节：
- 如果你对某个普通域用户有
Validated write to service principal name权限。 - 手动为其添加一个任意 SPN，使其在逻辑上具备“服务账户”的特征。
- 将其 SID 写入目标机器的 RBCD 属性，从而完成委派。
- 如果你对某个普通域用户有
C. 有密码修改权限 (SetNTLMHash)：S4U + U2U
这是一种高级利用方式，通常配合 Shadow Credentials 或 GenericAll 权限。
- 原理：利用 U2U (User-to-User) 身份验证获取初始凭据，再通过 S4U (Service for User) 协议完成转换。
- 细节：
- 当你拥有
SetNTLMHash权限时，可以直接同步或修改该用户的哈希。 - 利用该账户的哈希，通过 S4U2self 模拟高权限用户。
- 由于普通用户没有 SPN 无法直接执行
S4U2proxy，通过 U2U 封装票据，可以强制目标资源接受该委派请求。
- 当你拥有
3. 关键属性对比
| 利用点 | 核心前提 | 目标属性 |
|---|---|---|
| MAQ 路径 | MAQ > 0 |
目标机器的 msDS-AllowedToActOnBehalfOfOtherIdentity |
| SPN 路径 | WriteProperty (SPN) |
使普通用户具备 Service 身份 |
| U2U 路径 | SetNTLMHash / GenericAll |
解决普通用户（无 SPN）的身份模拟问题 |
提示：RBCD 的防御重点在于监控域内计算机对象的属性变更，以及严格控制
MachineAccountQuota的值（建议设为 0）。
原文 https://blog.csdn.net/2301_79518550/article/details/159885099