‍

在 Kerberos 委派体系中，S4U（Service for User）扩展是理解「约束委派」的核心钥匙。前文已经介绍过 S4U2self 如何让服务代表任意用户获取一张指向自身的服务票据（ST），本篇将聚焦紧随其后的另一半——S4U2proxy。它决定了服务能否携着「用户身份」进一步跨服务访问后端资源，也正因如此，它同时构成了约束委派（Constrained Delegation）与基于资源的约束委派（RBCD）能够被攻击者滥用、实现横向移动与权限提升的技术根基。本文将从概念定义、协议流程、字段含义与常见误解四个方面，系统梳理 S4U2proxy 的运行机制，并结合约束委派整体流程图，逐步拆解 S4U2self 与 S4U2proxy 是如何协同完成一次完整的「代用户请求」的，为后续章节的委派攻击利用与检测防御打下基础。

# 1 S4U2proxy 介绍及原理

## 1.1 S4U2proxy 基本概念

当 Service1 通过 S4U2self 获得代表用户访问自身的 ST 之后，Kerberos 协议允许该服务继续使用这张「可转发（Forwardable）」的 ST，向 KDC 申请一张用于访问其他后端服务的新 ST，这一过程就是 **S4U2proxy**。相较于 S4U2self 仅能获取「指向自身」的票据，S4U2proxy 的作用范围更广，它使得前端服务能够以用户身份继续访问后端服务，从而实现真正意义上的「跨服务委派」。

需要特别注意的是，S4U2proxy 并非可以任意访问任何服务，它受到以下两条硬性约束：

- 目标服务的 SPN 必须存在于委派账户的 `msDS-AllowedToDelegateTo` 属性列表中；
- 整个 S4U2proxy 交互只会发生在 Kerberos 的 **TGS_REQ / TGS_REP** 阶段，不会触碰 AS 阶段。

> **提示**：S4U2self 的核心目的是**验证用户身份的合法性**（Protocol Transition），而 S4U2proxy 的核心目的是**允许服务以该用户身份请求其他服务**（Constrained Delegation）。二者共同构成了「协议转换 + 约束委派」的完整能力，缺一不可。

## 1.2 S4U2proxy 与 S4U2self 的关系对比

为便于对比理解，将两者的关键差异整理如下表所示。

:::center  
表1-1 S4U2self 与 S4U2proxy 关键差异对比  
:::

|对比维度|S4U2self|S4U2proxy|
| ------------------| ---------------------------------| ------------------------------------|
|主要用途|协议转换（Protocol Transition）|约束委派（Constrained Delegation）|
|请求阶段|TGS_REQ / TGS_REP|TGS_REQ / TGS_REP|
|输出票据|指向服务自身的 ST|指向后端目标服务的 ST|
|关键属性|`TrustedToAuthForDelegation`|`msDS-AllowedToDelegateTo`|
|是否需要用户密码|否|否|
|票据要求|无特殊要求|输入的 ST 必须为 Forwardable|
|目标范围|仅限自身 SPN|受 `msDS-AllowedToDelegateTo` 限定的 SPN 集合|

# 2 约束委派原理

## 2.1 整体流程概览

约束委派的完整工作原理如图1-1所示，整体分为 **S4U2self 阶段** 与 **S4U2proxy 阶段** 两大部分，前者解决「用户是谁」的问题，后者解决「以该用户身份访问什么」的问题。

:::center  
​![](https://developer.qcloudimg.com/http-save/yehe-1277458/c245f8ebced376370836ee42797e12e9.jpg)

图1-1 约束委派原理  
:::

## 2.2 S4U2self 阶段

S4U2self 阶段的主要任务是让 Service1 在**未持有用户 TGT** 的情况下，也能获得一张「代表用户访问自己」的 ST，为下一步 S4U2proxy 提供合法输入。具体流程如下：

1. user1 向 Service1 发出请求。此时 user1 通常通过 Kerberos 以外的方式（如表单登录、证书等）完成身份验证，因此 Service1 手上并没有 user1 的 Kerberos 授权数据。
2. Service1 通过 S4U2self 代表指定用户向 KDC 请求一张访问 Service1 自身的 ST。KDC 会检查 user1 是否为该服务的合法用户，并核对发起请求的服务账户是否设置了 `TrustedToAuthForDelegation` 属性。
3. KDC 的 TGS 服务代表 user1 返回一张 **Forwardable 的 ST**，票据中包含用户的身份认证信息（PAC）。
4. Service1 使用该 ST 中的身份认证信息来满足用户的请求，随后向用户返回响应。

## 2.3 S4U2proxy 阶段

在 S4U2self 阶段完成后，Service1 已经握有一张「代表 user1 访问自己」的 Forwardable ST，接下来的 S4U2proxy 阶段会以这张票据为凭据，进一步向后端 Service2 申请访问票据。流程如下：

1. 用户向 Service1 发出请求，Service1 需要以用户身份访问 Service2 的资源。要进入 S4U2proxy 流程，必须同时满足两个先决条件：一是 Service2 的 SPN 位于委派账户的 `msDS-AllowedToDelegateTo` 属性中；二是 Service1 手上持有一张「用户访问 Service1」的 Forwardable ST1（由 S4U2self 阶段获得）。
2. Service1 代表指定用户向 KDC 请求访问 Service2 的 ST，请求中通过 ST1 中的身份认证信息来标识目标用户。
3. KDC 校验请求中的 PAC 签名，只有在 PAC 有效或 PAC 不存在的情况下才继续处理。校验通过后，KDC 返回一张指向 Service2 的 ST，其中 `cname`​、`crealm` 字段填写的是「用户」的身份认证信息，而非 Service1 自身。
4. Service1 携带该 ST 向 Service2 发起访问请求，Service2 会将该请求视为「用户」发起，并认为用户已由 KDC 完成身份验证。
5. Service2 根据请求内容返回响应结果。
6. Service1 将从 Service2 得到的数据组合后，响应用户在第 1 步发起的资源请求。

## 2.4 关键字段与属性说明

在整个约束委派流程中，有几个字段和属性是判定行为是否合法、以及攻击者能否利用的关键，理解它们对后续调试与检测至关重要。

- **​`msDS-AllowedToDelegateTo`​**：定义在委派账户上，其值为一组 SPN，限定该账户在 S4U2proxy 阶段能够为用户申请票据的目标服务集合，是「约束」二字的直接体现。
- **​`TrustedToAuthForDelegation`​**​（UAC 位 `T2A4D`​）：定义在服务账户上，表示该账户允许执行 **Protocol Transition**，即无需用户凭据即可通过 S4U2self 获得可转发 ST；未设置该属性时，S4U2self 返回的 ST 通常不可转发，S4U2proxy 会因此失败。
- **ST 的** **​`Forwardable`​**​ **标志位**：位于票据的 `flags` 字段中，只有该位为 1，票据才允许被 S4U2proxy 复用，向 KDC 换取指向其他服务的 ST。
- **​`PA-FOR-USER`​**​  **/**  **​`PA-S4U-X509-USER`​**​ **预认证数据**：分别用于传统 S4U2self 与基于证书的 S4U2self，其中携带了「被模拟用户」的身份信息，KDC 会以此为依据签发对应的 ST。
- **PAC 签名**：S4U2proxy 请求携带的 ST 必须通过 KDC 的 PAC 签名校验，这一机制在一定程度上防止了对票据 PAC 的随意篡改（也是后续 CVE-2020-17049 Bronze Bit 等漏洞的核心攻击面）。


‍ 在 Kerberos 委派体系中，S4U（Service for User）扩展是理解「约束委派」的核心钥匙。前文已经介绍过 S4U2self 如何让服务代表任意用户获取一张指向自身的服务票据（ST），本篇将聚焦紧随其后的另一半——S4U2proxy。它决定了服务能否携着「用户身份」进一步跨服务访问后端资源，也正因如此，它同时构成了约束委派（Constrained Delegation）与基于

AD域攻防权威指南.九十二.S4U2proxy介绍及原理

技术经理

安全

网络与通信

数据库

深入解析Kerberos委派中的S4U2proxy机制，揭示约束委派工作原理及安全风险。S4U2proxy允许服务以用户身份访问后端资源，需满足msDS-AllowedToDelegateTo属性限制。文章详细剖析S4U2self与S4U2proxy协同工作流程，为理解委派攻击与防御奠定基础。

2026上云采购 | AI焕新·智启新局

cadc

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AD域攻防权威指南.九十二.S4U2proxy介绍及原理-腾讯云开发者社区-腾讯云

AD域攻防权威指南.九十二.S4U2proxy介绍及原理

AD域攻防权威指南.九十二.S4U2proxy介绍及原理

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐