Kerberos认证协议中的约束委派与基于资源的约束委派（RBCD）详解 1. 描述 Kerberos是一种网络认证协议，通过票据（Ticket）机制实现身份验证，避免了密码在网络上传输。在Kerberos中， 委派（Delegation） 允许一个服务代表用户访问另一个服务。传统的 约束委派（Constrained Delegation） 和 基于资源的约束委派（Resource-Based Constrained Delegation, RBCD） 是两种不同的委派模型，用于控制委派权限的范围和配置方式。理解这两种模型对于企业环境中服务间的安全访问控制至关重要。 2. 核心概念与背景 Kerberos基础流程 ：用户通过身份验证后获得票据授予票据（TGT），再用TGT申请访问特定服务的服务票据（ST）。 委派需求 ：例如，用户访问Web服务（Service A），该服务需要代表用户访问后端数据库（Service B）。传统Kerberos允许无限制委派，但安全风险高。 约束委派 ：限制Service A只能代表用户访问特定的Service B（通过配置Service A的 msDS-AllowedToDelegateTo 属性）。 RBCD ：在Windows Server 2012及更高版本中引入，将委派控制权从“调用方服务”转移到“资源服务”（即Service B自己决定谁可以委派给自己）。 3. 传统约束委派的工作原理 配置方式 ：在Active Directory中，为Service A（如Web服务账户）设置 msDS-AllowedToDelegateTo 属性，列出允许委派的目标服务（如MSSQL/serviceb.domain.com）。 流程 ： 用户向KDC（密钥分发中心）申请访问Service A的ST。 KDC检查Service A的约束委派配置，并在ST中设置“转发标志”。 Service A使用该ST代表用户向KDC申请访问Service B的ST。 Service A用新ST访问Service B。 限制 ：需Service A具备SeEnableDelegation特权（通常域管理员权限），且配置集中在调用方，资源方被动接受。 4. 基于资源的约束委派（RBCD）详解 设计目标 ：解决传统约束委派权限过高、配置不灵活的问题，将控制权交给资源服务所有者。 配置方式 ：在资源服务（Service B）的 msDS-AllowedToActOnBehalfOfOtherIdentity 属性中，添加允许委派给它的服务账户（如Service A）。 流程 ： Service A像普通服务一样运行，无需特殊委派权限。 当Service A需要代表用户访问Service B时，Service B检查自身属性，验证Service A是否被允许。 验证通过后，Service B接受Service A的委派请求。 优势 ： 无需域管理员权限，资源服务管理员即可配置。 更符合最小权限原则，攻击者入侵Service A后无法任意委派到其他服务。 5. 安全风险与攻击面 传统约束委派风险 ：若攻击者控制了配置约束委派的服务账户，可代表任意用户访问允许委派的目标服务，导致横向移动。 RBCD风险 ： 若资源服务配置错误（如允许任意账户委派），攻击者可利用此创建恶意服务账户并添加到属性中，实现权限提升。 结合Kerberos协议缺陷（如无PAC验证），可能伪造票据。 检测与防御 ： 定期审计委派配置，清理不必要的条目。 对RBCD，确保资源服务属性仅包含受信任账户。 启用Kerberos防护功能（如Windows的“始终提供委派凭据”策略）。 6. 实际应用示例 假设环境：Web服务器（账户WebSvc）需代表用户访问后端SQL服务器（账户SQLSvc）。 传统约束委派配置 ：在AD中为WebSvc设置 msDS-AllowedToDelegateTo 为 MSSQL/sqlserver.domain.com 。 RBCD配置 ：在SQLSvc账户的属性中，设置 msDS-AllowedToActOnBehalfOfOtherIdentity 为WebSvc的SID。 攻击模拟 ：若攻击者入侵WebSvc，在传统模型中可直接访问SQL服务；在RBCD中，除非SQLSvc错误配置了其他账户，否则攻击无法扩展。 7. 总结 约束委派与RBCD是Kerberos中实现安全服务委派的核心机制。传统模型以调用方为中心，需高权限配置；RBCD以资源方为中心，更灵活且安全。在防御中，应优先使用RBCD，严格限制委派范围，并监控相关配置变更。