在 Active Directory 环境下，Kerberos 委派（Delegation）是一种为了让服务能够代表用户去访问后端资源而设计的重要机制。其中，**无约束委派（Unconstrained Delegation）**  由于其对目标服务不加任何限制的特性，一旦被攻击者利用，往往可以直接完成从普通服务账户到域控（DC）的横向跃迁，是红队渗透和蓝队防御双方都必须重点关注的攻击面。

然而，很多读者在实际实验环境中会遇到这样一个问题：**用户账户默认没有 Delegation 选项卡，无法直接配置委派**；同时，为了后续通过远程会话导出内存中的 TGT，还需要正确配置 WinRM 信道并验证连接效果。只有把这些前置条件全部打通，才能真正复现无约束委派的攻击链路。

本篇作为《AD 域攻防权威指南》系列的第八十七篇，将聚焦"**配置无约束委派账户**"这一实战环节，按照 **配置服务账户 → 配置 WinRM → 远程连接与票据导出 → 权限验证** 的顺序，完整演示从环境准备到票据 PTT（Pass The Ticket）利用的全过程，并在文末给出常见踩坑点和防御建议，帮助读者在实验环境中一次跑通、在生产环境中有据可查。

##### 1. 配置账户

**1.1 将用户账户配置为服务账户**

由于机器账户默认带有 `Delegation`​ 选项卡，而普通用户账户没有该选项卡，因此需要先通过 `setspn`​ 命令为用户账户注册一个 SPN（Service Principal Name），使其成为"服务账户"，随后 ADUC 中该账户对象上才会显示 `Delegation` 选项卡，从而可以进行委派相关的配置。

在拥有权限的机器上执行以下命令，将用户 `user3` 注册为服务账户，如图1-1所示。

```powershell
setspn -U -A dm/test user3
```

:::center  
​![图1-1 配置用户账户为服务账户](https://developer.qcloudimg.com/http-save/yehe-1277458/71a96ef087b2e0c7bfcee5ffaf334c06.jpg)

图1-1 配置用户账户为服务账户  
:::

> **注意**：机器账户默认拥有 Delegation 选项卡，而用户账户默认没有；需要通过 `setspn` 将用户账户注册为服务账户后，才能在 ADUC 中看到并配置 Delegation。

##### 2. 配置 WinRM

为了后续从远程主机上导出内存中的 Kerberos 票据，需要在服务端与客户端之间打通 WinRM 通道。整体配置分为**服务端开启并放宽认证策略**、**客户端设置信任主机**、**远程连接验证**三个步骤。

**2.1 服务端配置**

在服务端的 `cmd` 中依次执行以下命令，开启 WinRM 服务并允许 Basic 认证与未加密传输（仅限实验环境使用）：

```powershell
winrm quickconfig
winrm set winrm/config/service/auth @{Basic="true"}
winrm set winrm/config/service @{AllowUnencrypted="true"}
```

**2.2 客户端配置**

在客户端的 `PowerShell` 中执行以下命令，将信任主机设置为任意，并重启 WinRM 服务使配置生效：

```powershell
winrm set winrm/config/client '@{TrustedHosts="*"}'
Restart-Service WinRM
```

**2.3 使用高权限账户连接服务端**

在客户端 `PowerShell`​ 中使用高权限账户，通过 `Enter-PSSession`​ 建立到目标服务端 `lab-test` 的远程会话，如图1-2所示。

```powershell
Enter-PSSession -ComputerName lab-test
```

:::center  
​![图1-2 使用高权限账户连接服务端](https://developer.qcloudimg.com/http-save/yehe-1277458/775524b826666ef790ca71b80583a05b.jpg)

图1-2 使用高权限账户连接服务端  
:::

##### 3. 导出服务端内存中的票据

连接成功后，在远程会话中调用 Mimikatz，将服务端内存中缓存的 Kerberos 票据（包括 TGT）导出到本地文件，为后续 PTT 攻击做准备，如图1-3所示。

```powershell
privilege::debug
sekurlsa::tickets /export
```

:::center  
​![图1-3 导出服务端内存中的 Ticket](https://developer.qcloudimg.com/http-save/yehe-1277458/306b7661991dee38945ba511c27f85e0.jpg)

图1-3 导出服务端内存中的 Ticket  
:::

导出后会在当前目录生成一系列 `.kirbi` 文件，其中包含高权限用户（如域管理员）通过无约束委派转发到本机的 TGT。

##### 4. 验证权限

**4.1 导入前的权限确认**

在将高权限 TGT 导入内存之前，先以当前普通账户身份尝试访问域控 `dc01`​ 的 C 盘共享，会看到 **拒绝访问** 的提示，说明当前会话不具备域管理员权限，如图1-4所示。

```powershell
dir \\dc01\c$
```

:::center  
​![图1-4 导入 TGT 前访问 DC C$ 被拒绝](https://developer.qcloudimg.com/http-save/yehe-1277458/4806dcda82cc6d8b5ba8c00d2ef8a9fd.jpg)

图1-4 导入 TGT 前访问 DC 的 C$ 被拒绝  
:::

**4.2 使用 Mimikatz 导入高权限 TGT**

在 Mimikatz 中执行 `kerberos::ptt` 命令，将上一步导出的域管理员 TGT 注入当前会话内存，如图1-5所示。

```powershell
kerberos::ptt [0;3e03c]-2-0-60a10000-Administrator@krbtgt-DM.ORG.kirbi
```

:::center  
​![图1-5 将高权限 TGT 导入内存](https://developer.qcloudimg.com/http-save/yehe-1277458/fa47e00be0beaa8ca4d8250bc75ee5b1.jpg)

图1-5 将高权限 TGT 导入内存  
:::

**4.3 再次访问域控验证权限**

TGT 导入成功后，再次执行 `dir \\dc01\c$`，此时可以正常列出 DC 的 C 盘目录，说明当前会话已经获得域管理员权限，无约束委派利用链条完整跑通。

```powershell
dir \\dc01\c$
```

##### 5. 常见问题与注意事项

在实际验证过程中，有几个容易踩坑的地方需要特别注意：

1. **必须使用 FQDN 访问 DC**：验证时连接域控（如 `dir \\dc01.dm.org\c$`​）必须使用 FQDN；如果直接使用 IP，Kerberos 将回退到 NTLM 认证，票据不生效，会提示 **拒绝访问**。
2. **用户账户与机器账户的差异**：机器账户默认拥有 `Delegation`​ 选项卡，而用户账户需要通过 `setspn -A` 注册 SPN 后才会出现该选项卡。
3. **WinRM 明文传输仅限实验**：生产环境中开启 `AllowUnencrypted="true"`​ 和 `TrustedHosts="*"` 存在明显的安全风险，正式部署应使用 HTTPS 监听器 + 证书认证。
4. **导出的**  **​`.kirbi`​**​ **文件名**：Mimikatz 导出的票据文件名会包含票据序号、加密类型、票据标志、用户名等信息，实际操作时应根据自己环境的输出文件名替换 PTT 命令中的路径。
5. **权限前提**：整个流程需要在服务端具备本地管理员或 SYSTEM 权限（`privilege::debug`​ + `sekurlsa::tickets`），否则无法读取 LSASS 中的票据缓存。

##### 6. 小结与防御建议

本篇围绕"配置无约束委派账户"这一实战场景，完整演示了从**用户账户 SPN 注册 → WinRM 通道配置 → 远程会话建立 → LSASS 票据导出 → PTT 权限验证**的全过程。可以看到，一旦某台服务器被配置为无约束委派、并且有高权限用户对其进行过 Kerberos 认证，攻击者只要拿下该服务器的本地管理员权限，就能通过导出内存中的 TGT 直接跃迁至域管理员。

从**防御视角**，建议在生产环境中重点关注以下几点：

1. **最小化无约束委派账户数量**：定期审计域内启用了 `TrustedForDelegation` 属性的账户，非必要不启用。
2. **优先使用受约束委派或 RBCD**：能用 Constrained Delegation / Resource-Based Constrained Delegation 解决的场景，绝不使用 Unconstrained Delegation。
3. **保护特权账户**：为域管等特权账户开启"**Account is sensitive and cannot be delegated**"或加入 Protected Users 组，避免其 TGT 被转发缓存到普通服务器。
4. **加固 WinRM 与 LSASS**：启用 WinRM HTTPS、限制 TrustedHosts；对关键服务器开启 LSA 保护（RunAsPPL）和 Credential Guard，降低 Mimikatz 抓票风险。
5. **持续监控异常登录与票据行为**：结合 4624/4769/4770 等事件与 EDR 的凭据访问告警，及时发现异常的委派利用行为。

在下一篇中，将继续深入委派攻击链，进一步介绍 **无约束委派的滥用手法与结合打印机漏洞（Printer Bug）强制认证** 的完整利用思路，敬请期待。


在 Active Directory 环境下，Kerberos 委派（Delegation）是一种为了让服务能够代表用户去访问后端资源而设计的重要机制。其中，无约束委派（Unconstrained Delegation） 由于其对目标服务不加任何限制的特性，一旦被攻击者利用，往往可以直接完成从普通服务账户到域控（DC）的横向跃迁，是红队渗透和蓝队防御双方都必须重点关注的攻击面。 然而，很多读者在实

AD域攻防权威指南.八十七. 配置无约束委派账户

技术经理

安全

操作系统

网络与通信

Active Directory无约束委派漏洞详解：从服务账户配置到Kerberos票据攻击全流程。文章详细演示如何通过SPN注册、WinRM配置、远程会话建立、票据导出及PTT攻击，实现从普通账户到域控的权限提升。包含实战操作步骤、常见问题解决方案及防御建议，帮助安全人员深入理解无约束委派风险。

服务器

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

cadc

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

AD域攻防权威指南.八十七. 配置无约束委派账户-腾讯云开发者社区-腾讯云

AD域攻防权威指南.八十七. 配置无约束委派账户

AD域攻防权威指南.八十七. 配置无约束委派账户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐