什么叫Kerberos委派？
在域中如果出现A使用Kerberos身份验证访问域中的服务B，而B再利用A的身份去请求域中的服务C，这个过程就可以理解为委派。
比如
User访问主机s2上的HTTP服务，而HTTP服务需要请求其他主机的SQLServer数据库，但是S2并不知道User是否有权限访问SQLServer，这时HTTP服务会利用User的身份去访问SQLServer，如果User有权限访问SQLServer服务才能访问成功。 而委派主要分为非约束委派（Unconstrained delegation）和约束委派（Constrained delegation）两个方式，和2012年提供了基于资源的约束委派 下面分别介绍三种方式如何实现
非约束委派
非约束委派在Kerberos中实现时，User会将从KDC处得到的TGT发送给访问的service1（可以是任意服务），service1拿到TGT之后可以通过TGT访问域内任意其他服务，所以被称为非约束委派。
整个过程可以理解为
当用户使用用户名和密码登录后 第一步 计算机将密码转换为NTLM哈希，然后使用哈希对该时间戳进行加密，然后将其作为身份验证票证（TGT）请求（AS-REQ）中的身份验证器发送给KDC。 然后 域控制器（KDC）检查用户信息（登录限制，组成员身份等）并创建票证授予票证（TGT）。 第二步 TGT已加密，签名并交付给用户（AS-REP）。只有域中的Kerberos服务（KRBTGT）才能打开和读取TGT数据 第三步 当请求票证授予服务（TGS）票证（TGS-REQ）时，用户向DC提交TGT。 DC打开TGT并验证PAC校验和–如果DC可以打开票证和校验和签出，则TGT =有效。有效复制TGT中的数据以创建TGS票证 第四步 TGS使用目标服务帐户的NTLM密码哈希进行加密，然后发送给用户（TGS-REP）。 第五步 用户连接到在适当端口上托管服务的服务器，并显示TGS（AP-REQ）。该服务使用其NTLM密码散列打开TGS票证。
第六步
在托管TGS-REQ中引用的服务主体名称中指定的服务的服务器上启用Kerberos不受约束委派时（步骤3），域控制器DC将用户TGT的副本放入服务票证中。将用户的服务票证（TGS）提供给服务器以进行服务访问时，服务器将打开TGS，并将用户的TGT放入LSASS，以供以后使用。现在，Application Server可以无限制地模拟该用户！
注意：为了为应用程序服务器配置“ Kerberos不受约束的委派”，域或企业管理员需要在域中的计算机帐户上配置此设置。可以将此权限委派给其他组，因此请注意谁在Active Directory中拥有此权限。
计算机需配置
约束委派
Windows Server 2003中引入了约束委派，它允许您配置可以将帐户委派给的服务，从而使这一步骤更进一步。从理论上讲，如果发生折衷，这将限制潜在的风险敞口。
对于约束委派需要注意的是，他不能跨域林工作，而且当一个用户被设置为可以委派时候，会发现两件事情
1用户的对象的属性更新 有“TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION“标志
2在“委派”选项卡上配置的SPN出现msDS-AllowedToDelegateTo属性
基于资源的约束委派
基于资源的约束委派在Windows Server 2012中引入，它更改了配置约束委派的方式，并且将在信任关系中工作。托管服务的资源没有指定可以委托给哪个对象的对象
，而是指定可以委托给哪个服务的对象。从管理的角度来看，这允许资源所有者控制谁可以访问它。例如，您可以在SQL Server服务帐户上指定WebServer服务帐户有权委派对数据库的访问
，而不是使用约束委派指定WebServer服务帐户可以委派给SQL Service来访问数据库。
通过使用允许委派给目标资源的对象的SID填充目标资源上的msDS-AllowedToActOnBehalfOfOtherIdentity属性
，可以配置基于资源的约束委派。要配置基于资源的约束委派，您实际上需要利用PowerShell，Active Directory用户和计算机中没有GUI组件
，并且“属性编辑器”页面不允许手动修改此属性。您可以在我的其他博客中了解有关基于资源的约束委派以及滥用它的更多信息。
参考
https://stealthbits.com/blog/resource-based-constrained-delegation-abuse/ https://docs.microsoft.com/en-us/windows-server/security/kerberos/kerberos-constrained-delegation-overview https://adsecurity.org/?p=1667 https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/domain-compromise-via-unrestricted-kerberos-delegation https://www.anquanke.com/post/id/173477