企业官网建设流程全解析

前言

做域安全运维、红队渗透的人，几乎天天和Kerberos委派打交道。圈内绝大多数资料都停留在“攻击利用演示+通用加固清单”的固定套路里，没人真正落地验证：微软官方给出的四条AD委派加固策略，到底能挡住什么攻击、拦不住什么、防护边界在哪里、有没有大量无效配置。

网上流传着大量错误认知：域管账户默认自带不可委派保护、Protected Users组可以替代账户委派标记、RBCD加固能顺带防御影子凭据、委派加固可以缓解Kerberoasting爆破。这些说法没有任何实测依据，却被反复转发，导致大量企业域环境加固流于形式，看似配置齐全，高危攻击链路依旧畅通。

本次我基于 Windows Server 2019 域控、Windows 2016 域功能级别，搭建纯净隔离靶场，搭建 4×4 对照实验矩阵，用约束委派、RBCD、影子凭据、Kerberoasting 四类主流高危攻击，逐一测试微软官方四项委派加固策略的真实防护效果。所有结论均来自变量唯一的对照测试，推翻多个行业流传已久的错误结论，同时整理出可直接落地的优先级加固清单、环境回滚方案与避坑准则。

一、实验前置：理清Kerberos委派攻击与加固底层逻辑

所有AD委派攻击的核心，都依托Kerberos协议的S4U协议扩展，包括S4U2Self和S4U2Proxy两个核心能力。S4U2Self 允许服务账户以自身身份向KDC申请任意用户的本地票据，S4U2Proxy 则可以将该票据转发到目标服务，实现身份冒用。

微软设计四项委派加固的初衷，是从主体、权限、身份三个维度限制S4U协议的滥用，但官方文档从未明确标注每一项加固的作用层级、覆盖范围和失效场景，这也是企业加固普遍踩坑的核心原因。

1.1 四类核心攻击链底层原理

本次实测覆盖域环境中最常被利用的四条Kerberos攻击链路，全部为红队实战高频利用路径，无小众场景。

约束委派攻击：核心前置条件为目标账户/机器配置了指定服务的约束委派权限。攻击者利用被信任的委派主体，通过S4U协议模拟高权用户，获取目标服务票据，进而横向移动、权限提升。攻击全程依托已授权的委派关系，传统权限监控很难溯源。

RBCD攻击（基于资源的约束委派）：核心前置条件为低权限用户拥有机器账户创建权限、可修改目标机器的msDS-AllowedToActOnBehalfOfOtherIdentity属性。普通域用户默认拥有创建10个机器账户的权限，这是绝大多数域环境的默认漏洞，攻击者无需高权初始权限，即可从零搭建委派攻击链路。

影子凭据攻击：核心前置条件为攻击者拥有目标对象的属性写入权限，可修改msDS-KeyCredentialLink属性。写入恶意凭据后，通过PKINIT协议申请TGT票据，直接导出目标机器/用户的NT哈希，权限危害等同于直接拿下目标对象控制权。

Kerberoasting攻击：核心前置条件为域内存在绑定SPN的服务账户。攻击者无需特殊权限，普通域用户即可枚举所有SPN账户，申请RC4加密服务票据，离线暴力破解获取服务账户明文密码，是域内最易触发、最容易被忽视的高危攻击。

1.2 微软四项官方加固策略定义

本次实测的四项加固，均为微软官方公开的AD委派安全加固方案，也是企业域安全基线的标配内容。

D1 账户敏感不可委派：通过设置用户UAC位 AccountNotDelegated（1048576），标记账户为敏感身份，禁止被S4U协议模拟冒用，保护对象为高权限用户账户。

D2 不信任账户委派权限：清空账户/机器的msDS-AllowedToDelegateTo属性，撤销TRUSTED_FOR_DELEGATION标志，直接回收主体的委派信任资格，保护对象为所有具备委派能力的主体。

D3 加入Protected Users组：AD内置高安全保护组，默认禁止组成员被委派冒用、限制票据缓存、屏蔽多种凭证窃取行为，是通用高权账户保护方案。

D4 收紧对象敏感属性ACL权限：通过修改AD对象ACL，禁止普通用户写入msDS-AllowedToActOnBehalfOfOtherIdentity、msDS-KeyCredentialLink两大敏感属性，从权限源头阻断属性篡改类攻击。

1.3 攻击链路流程图

二、实验环境与标准化测试方案

本次实验全程采用纯净基线环境，无任何额外加固、无第三方安全软件干扰，所有实验对象统一前缀，测试完成后完整回滚，保证每一组测试变量唯一，结论真实可复现。

2.1 靶场环境参数

域控系统：Windows Server 2019 Datacenter 10.0.17763

域/林功能级别：Windows2016Domain、Windows2016Forest

辅助主机：Windows Server 2019 已入域主机（诱饵测试机）

机器账户配额：默认10（域环境原生配置，未修改）

测试基线：实验前域内约束委派、RBCD配置为0，仅域控默认自带无约束委派配置，环境干净无残留风险。

2.2 测试工具版本

全程使用稳定版渗透工具，避免版本漏洞导致测试误差：

impacket 0.13.1（委派枚举、票据申请、横向利用核心工具）

Certipy 5.1.0（影子凭据专属利用工具）

WinRM/PowerShell（远程配置、属性修改、权限校验）

2.3 实验对象角色划分

所有对象以D13_为前缀，方便批量回滚清理，覆盖低权用户、高权域管、服务账户、机器账户全场景：

D13_svc_web：带SPN服务账户，Kerberoasting核心测试目标、委派主体

D13_alice：普通低权域用户，模拟内网初始沦陷用户

D13_admin：域管理员账户，高权保护测试对象

D13_svc_admin：Server/Backup Operators高权账户，非域管，核心对照测试对象

D13EVIL/D13TARGET：测试机器账户，承担委派发起、受害角色

D13ATTACK$：低权用户创建的攻击机器账户，RBCD专属测试对象

2.4 4×4完整测试矩阵设计

本次测试严格遵循单一变量原则，每一组测试仅启用一项加固，其余配置保持基线状态，完整覆盖16组组合场景，9组有效实测、6组机制不生效、1组未复现，所有结果均留存日志证据。

测试矩阵核心逻辑：以四项攻击为被测对象，四项加固为变量，逐一验证防护有效性、防护层级、失效场景。

三、实测核心结果：推翻大量通用错误认知

所有结论均经过“加固生效-撤销加固-复测”三次对照验证，排除工具bug、配置静默失败、环境残留干扰，杜绝单一观测误差。

3.1 四项加固分属三个完全不同的防护层级

这是本次实验最核心的结论，也是绝大多数企业加固出错的根源。四项加固并非同级防护，不存在互相替代关系，防护链路完全不同。

断主体层级（D2）：直接清除委派主体的信任权限，从源头切断委派攻击能力。约束委派攻击在该加固下全程无法启动，整条链路直接失效，是彻底的链路级防护。

断写权限层级（D4）：管控AD对象敏感属性写入权限，阻断攻击者篡改RBCD、影子凭据核心属性的行为。RBCD、影子凭据两类攻击全部依赖属性写入，D4可以同时防护这两类攻击，属于底层权限防护。

断身份层级（D1、D3）：不修改任何委派配置、不限制任何攻击操作，仅在攻击者最后一步冒用高权身份时，被KDC拒绝票据签发。攻击者可以完整走完攻击流程，仅特定受保护账户无法被冒用，未保护账户依旧可以正常利用。

3.2 证伪：域管账户无自动委派保护机制

全网流传最广的错误认知：域管理员加入Domain Admins组后，系统会自动开启不可委派保护。本次实测彻底推翻该结论。

新建账户加入Domain Admins组后，即时查询UAC值为66048，AccountNotDelegated 固定为 False，无任何自动标记行为。系统内置Administrator账户，adminCount=1、归属域管组，依旧默认未开启不可委派标记。

AD的AdminSDHolder机制仅每小时重写高权对象的ACL权限，完全不干预userAccountControl属性，不会自动配置不可委派标记。所有高权账户，包括域管、服务器操作员、备份操作员、业务服务账户，全部需要手工批量打标，无任何系统兜底机制。

未打标的高权账户，可直接被S4U协议冒用身份，攻击者无需突破任何权限，即可完成委派提权。

3.3 D1与D3防护范围不重叠、不可替代

多数运维默认将“加入Protected Users组”和“设置账户不可委派标记”视为等效操作，实测两者防护边界存在明显差异。

针对Administrator内置账户测试：开启D1不可委派标记后，KDC直接拒绝身份冒用，攻击失败；将账户加入Protected Users组（D3）后，攻击者依旧可以成功冒用身份、获取服务票据。

核心差异：D1针对账户委派冒用行为做精准拦截，D3是通用凭证保护，无法覆盖所有委派攻击场景。企业仅配置Protected Users组加固，不配置不可委派标记，域管账户依旧存在被委派提权的风险。

3.4 RBCD与影子凭据共享同一防护点

圈内普遍将RBCD和影子凭据分为两类独立攻击，加固时单独配置RBCD权限，忽略影子凭据防护。实测证明两者底层依赖同一漏洞：AD对象敏感属性写入权限。

RBCD攻击依赖修改 msDS-AllowedToActOnBehalfOfOtherIdentity 属性，影子凭据攻击依赖修改 msDS-KeyCredentialLink 属性。收紧这两个属性的ACL写入权限（D4），可以同时阻断两类攻击，攻击者直接卡在属性写入阶段，报错 INSUFF_ACCESS_RIGHTS，整条攻击链路报废。

只加固RBCD不防护KeyCredentialLink，等于完全暴露影子凭据高危攻击面，这是绝大多数企业域环境的加固盲区。

3.5 四项委派加固对Kerberoasting全部无效

这是本次实验最颠覆认知的结论。所有委派类加固策略，完全无法防护Kerberoasting攻击。

Kerberoasting的核心原理是枚举SPN账户、申请服务票据、离线爆破，全程不依赖任何委派机制。无论是否开启账户不可委派、是否撤销委派信任、是否加入保护组、是否收紧属性权限，攻击者都可以正常申请RC4加密票据，离线爆破不受任何影响。

唯一能有效抬高Kerberoasting攻击成本的方式，是强制服务账户启用AES256加密。设置 msDS-SupportedEncryptionTypes=24 后，票据加密类型从etype23（RC4）变为etype18（AES256），爆破成本从分钟级提升至几乎不可行。该配置不属于委派加固，是独立的票据加密加固策略。

3.6 无约束委派攻击的真实前置条件

本次实验完整配置无约束委派环境，但三次不同方式尝试均无法复现TGT票据截获，最终定位真实攻击前置条件。

计划任务密码登录、PSSession远程登录、服务账户登录三种场景测试证明：网络类型登录不会在本地缓存TGT票据，仅交互式登录（Type2）、服务登录（Type5）会缓存TGT。

无约束委派不等于直接沦陷，必须同时满足三个条件：目标主机开启无约束委派、高权用户在主机完成交互式/服务登录、攻击者获取主机本地管理员权限。单纯配置无约束委派，无法直接触发提权攻击。

四、逐类攻击加固效果详细复盘

4.1 约束委派攻击（A2）

基线状态下攻击百分百成功，可正常模拟各类用户获取服务票据。

D2加固效果最优，清空委派主体信任权限后，整条攻击链路直接阻断，无任何利用可能。

D1、D3仅针对特定受保护账户生效，未打标普通用户、低权账户依旧可以被正常模拟，攻击链路未被切断，仅缩小攻击范围，无法彻底防护。

4.2 RBCD攻击（A3）

D4加固从权限源头阻断攻击，攻击者无法写入RBCD核心属性，攻击直接失效。

D1加固仅拦截最后一步身份冒用，攻击者可以正常创建机器账户、写入RBCD属性，攻击前置操作全部完成，仅高权受保护账户无法利用，其余账户依旧存在风险。

4.3 影子凭据攻击（A4）

仅D4加固有效，收紧KeyCredentialLink属性写入权限后，无法植入恶意凭据，不能申请TGT、导出NT哈希。

D1、D2、D3三项加固对影子凭据完全无效，攻击者可正常完成全套攻击流程。

4.4 Kerberoasting攻击（A5）

所有委派加固均无防护效果，票据签发、RC4加密、离线爆破全程不受影响。仅强制AES加密可有效防护，无其他替代方案。

五、可直接落地的优先级加固清单（附完整脚本）

根据实测防护收益、阻断层级、落地难度，整理从高到低的加固顺序，优先配置链路级阻断策略，再补充账户级防护，最后优化加密策略。所有脚本可直接复制批量执行。

5.1 一级加固：收紧敏感属性ACL（阻断RBCD+影子凭据）

最高优先级加固，一次性阻断两类高危攻击，从底层权限封堵漏洞。

# 批量收紧机器账户敏感属性写入权限$domain=(Get-ADDomain).DNSRoot$acl=New-ObjectSystem.DirectoryServices.ActiveDirectoryAccessRule((Get-ADGroup"Domain Users").SID,"WriteProperty","Deny","None",$true,@("msDS-AllowedToActOnBehalfOfOtherIdentity","msDS-KeyCredentialLink"))Get-ADComputer-Filter*|ForEach-Object{$adobj=Get-ADObject$_.DistinguishedName-Properties nTSecurityDescriptor$adobj.nTSecurityDescriptor.AddAccessRule($acl)Set-ADObject-Instance$adobj}# 批量收紧用户账户敏感属性写入权限Get-ADUser-Filter*|ForEach-Object{$adobj=Get-ADObject$_.DistinguishedName-Properties nTSecurityDescriptor$adobj.nTSecurityDescriptor.AddAccessRule($acl)Set-ADObject-Instance$adobj}

5.2 二级加固：清理域内无效委派信任（阻断约束委派）

# 清空所有账户约束委派配置Get-ADUser-Filter{msDS-AllowedToDelegateTo-ne$null}|Set-ADUser-AllowedToDelegateTo @()# 清空所有机器账户约束委派配置Get-ADComputer-Filter{msDS-AllowedToDelegateTo-ne$null}|Set-ADComputer-AllowedToDelegateTo @()# 撤销服务账户委派信任位Get-ADUser-Filter*|Set-ADUser-TrustedForDelegation$false

5.3 三级加固：批量清点高权未打标账户

# 批量查询所有未开启不可委派的高权账户$highGroups= @("Domain Admins","Enterprise Admins","Schema Admins","Server Operators","Backup Operators")$highUsers= @()foreach($groupin$highGroups){$highUsers+=Get-ADGroupMember$group-Recursive|Get-ADUser-Properties AccountNotDelegated}$highUsers|Where-Object{$_.AccountNotDelegated-eq$false}|Select-ObjectName,SamAccountName,DistinguishedName|Export-Csv"C:\AD_Untagged_User.csv"-NoTypeInformation-Encoding UTF8

5.4 四级加固：批量给高权账户开启不可委派标记

# 批量开启高权账户敏感不可委派Import-Csv"C:\AD_Untagged_User.csv"|ForEach-Object{Set-ADUser-Identity$_.SamAccountName-AccountNotDelegated$true}

5.5 五级加固：服务账户强制AES加密（防护Kerberoasting）

# 批量设置服务账户仅AES256加密Get-ADUser-Filter{SPN-ne$null}|Set-ADUser-SupportedEncryptionTypes 24

六、实验避坑准则：纠正加固常见错误操作

本次实验两次推翻自身初始结论，核心问题都是依赖命令执行结果，未校验配置实际生效状态，这是运维加固的高频误区。

第一，PowerShell修改AD权限、属性时，命令无报错不代表配置生效。ACL删除规则需要字段完全匹配，规则细微差异会导致静默失败，必须修改后读取属性校验。

第二，不能通过“加固后攻击失败”判定加固有效，必须做撤销加固对照测试。很多攻击失败是环境bug、参数缺失导致，和加固策略无关，单一观测结果完全不可信。

第三，高权账户清理时，adminCount=1的对象会被AdminSDHolder保护，无法直接删除修改，必须先退出特权组、清空adminCount属性，再执行操作。

第四，Protected Users组不能替代不可委派标记，两类配置必须同时落地，缺一不可。

第五，Kerberoasting防护不要浪费资源在委派加固上，所有委派配置对爆破无效，必须依赖加密算法升级和SPN精简。

七、实验边界与适用范围

本次所有结论仅适用于 Windows Server 2019 域控、Windows 2016 域功能级别，暂不适配2022/2025新版系统，新版系统存在权限机制微调。

未覆盖跨域、跨林委派场景，该场景攻击链路和防护逻辑与单域环境存在差异。未做真实Kerberoasting离线爆破测试，AES加密防护结论基于加密强度推导，符合行业安全共识。

所有测试基于默认机器账户配额（10），配额为0的受限域环境，RBCD攻击初始条件不满足，防护逻辑无需调整。

八、互动提问

1、你的域环境中，是否还在单纯依靠Protected Users组保护高权账户？

2、你以往加固时，是否误将委派加固用于防护Kerberoasting攻击？