1.什么是委派
在Windows 2000 Server首次发布Active Directory时，Microsoft必须提供一种简单的机制来支持用户通过Kerberos向Web Server进行身份验证并需要代表该用户更新后端数据库服务器上的记录的方案。这通常称为“ Kerberos双跳问题”，并且要求进行委派，以便Web Server在修改数据库记录时模拟用户。需要注意的一点是接受委派的用户只能是服务账户或者计算机用户。
说人话就是：为了解决服务代表用户访问其他应用产生的功能
2.非约束委派
如果某台机器A(Web Server)配置了非约束的委派，那么这个机器A(Web Server)就可以接受任何用户的委派请求其他所有的服务。任意用户在访问机器A(Web Server)时会将自己的TGT票据发送给机器A(Web Server)，如果机器A(Web Server)被攻陷，攻击者可以dump所有的TGT，然后任意伪造ST，访问域内各种服务。
只有域管在域控可以配置 并且可以修改非约束和约束委派
使用非约束委派，被授予此权限的服务器或服务帐户能够模拟用户对任何主机上的任何服务进行身份验证。
约束和非约束委派的鉴权都是在web server上
如何配置“非约束委派”
如何判断配置“非约束委派”
配置了非约束委派的用户的userAccountControl 属性有个FLAG位 TrustedForDelegation
userAccountControl 中的TRUSTED_FOR_DELEGATION 对应是 0x80000 ，也就是 524288。
2.1.涉及的问题
非约束委派的安全问题就是如果我们找到配置了非约束的委派的账户，比如test，并且通过一定手段拿下该账户的权限，然后诱导域管访问该test，这个时候域管会将自己TGT发送到test$并缓存到LSASS中，那我们就可以从LSASS中导出域管的TGT票据，然后通过PTT，从而拥有域管的权限。
因为配置非约束的委派的账户的UserAccount 配置了TRUSTED_FOR_DELEGATION flag位，TRUSTED_FOR_DELEGATION 对应是 0x80000 ，也就是 524288 。
所以对应的LDAP过滤规则是
(&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=524288))
可以通过这个规则进行查找
3.约束委派
微软很早就意识到非约束委派并不是特别安全，在 Windows 2003上发布了"约束"委派。 其中包括一组 Kerberos 协议扩展。配置它后，约束委派将限制指定服务器可以代表用户执行的服务。这需要域管理员特权(其实严谨一点是SeEnableDelegation特权，该特权很敏感，通常仅授予域管理员)才能为服务配置域帐户，并且将帐户限制为单个域。
约束委派 和 非约束委派 区别是，约束委派只能访问委派的那个机器并是指定的服务
如何配置约束委派
配置了约束委派的用户的userAccountControl 属性有个FLAG位 TrustedToAuthForDelegation 。
其中 TRUSTED_TO_AUTH_FOR_DELEGATION 对应是 0x1000000 ，也就是 16777216 。
所以对应的LDAP过滤规则是
(&(objectCategory=computer)(objectClass=computer)(userAccountControl:1.2.840.113556.1.4.803:=16777216))
约束的资源委派，除了配置TRUSTED_TO_AUTH_FOR_DELEGATION 之外，还有个地方是存储对哪个spn 进行委派的，位于msDS-AllowedToDelegateTo
3.1.涉及的问题
约束委派的安全问题就是如果我们找到配置了约束委派的服务账号，比如test2，并且通过一定手段拿下该账号所在的计算机。我们就可以利用这个服务账号代表任意用户(这里面很重要的一点是服务代表用户获得针对服务自身的kerberos票据这个过程，服务是不需要用户的凭据的)进行s4u2self获得一个可转发的票据，然后把获取到的票据用于s4u2proxy(作为AddtionTicket)，获取一个可转发的TGS，这样服务就可以代替任意用户访问另外一个服务(既被配置的约束委派的服务）。
相较于非约束的委派，约束的委派并不需要用户过来访问就可以代表该用户，但是只能访问特定的服务。不同服务下所能达到的效果是不同的，例如：对于 HOST SPN，则可以实现完全的远程接管。 对于 MSSQLSvc SPN，则可以拿到 DBA 权限。 对于 CIFS SPN 则可以实现完全的远程文件访问。对于 HTTP SPN 则可能实现接管远程网络服务，而对于 LDAP 则可以执行 DCSync。而对于 HTTP 或 SQL 服务帐户，即使它们没有提升目标服务器上的管理员权限，也可能使用 Rotten Potato 进一步滥用，提权至 SYSTEM 的权限
4.基于资源的约束委派
为了配置受约束委派，必须拥有SeEnableDelegation特权，该特权十分敏感，通常仅授予域管理员。为了使用户/资源更加独立，Windows Server 2012中引入了基于资源的约束委派。基于资源的约束委派允许资源配置受信任的帐户委派给他们。基于资源的约束委派将委派的控制权交给拥有被访问资源的管理员。
这种约束委派的风格与传统约束委派非常相似，但配置相反。从帐户A到帐户B的传统约束委派在msDS-AllowedToDelegateTo属性中的帐户A上配置，并定义从A到B的“传出”信任，而在马上到！S-AllowedToActOnBehalfOfOtherIdentity属性中的帐户B上配置基于资源的约束委派，并定义从A到B的“传入”信任。
说人话就是：A配置对于B的基于资源的约束委派，那么A对于B就处于完全信任状态，如果我们拿下了B，那么我们就可以利用B申请任意用户到A的票据（前提是具有合法的SPN的）。
从安全性的角度来讲，基于资源的约束委派相对于约束委派来讲，是不那么安全的。更片面的武断的来讲，约束委派好歹还限定了特定的某个服务，但是基于资源的约束委没有。相较于传统的约束委派。基于资源的约束委派的利用又相对较为简单。
基于资源的约束委派在Active Directory中的表现:
4.1涉及的问题
直接抛结论：
1.利用基于资源的约束委派进行提权操作
具体实现手法很简单，利用可以连接且可修改ldap的账户，去设置msDS-AllowedToActOnBehalfOfOtherIdentity属性，配置该属性的值指向自己已控制的用户账户。
2.利用基于资源的约束委派RCE
我们前面文章讲过，域环境下，计算机与服务之间、服务与服务之间的数据交互以及鉴权都是通过“票据”来实现的，换句话说，我们拿到对应服务的票据，也就意味着利用该服务进行数据操作。
举个栗子：当我们手里有A、B两个用户，我们发现A可以配置msDS-AllowedToActOnBehalfOfOtherIdentity属性，那我们直接配置AmsDS-AllowedToActOnBehalfOfOtherIdentity到B，就可以利用B申请到任意用户的到A的CIFS票据（前提是CIFS已经配置合法的SPN）。
5.SPN
关于SPN，microsoft文档是这么写的：
System Center Virtual Machine Manager uses Kerberos-based authentication. If you are using Kerberos-based authentication, you must configure a Service Principal Name (SPN) for Network Controller in Active Directory. The SPN is a unique identifier for the Network Controller service instance, which is used by Kerberos authentication to associate a service instance with a service login account. For more details, see Service Principal Names.
翻译成人话就是：SPN(ServicePrincipal Names)服务主体名称，是服务实例(比如：HTTP、SMB、MySQL等服务)的唯一标识符。Kerberos认证过程使用SPN将服务实例与服务登录账户相关联，只有正确配置SPN，你才能申请对应服务的票。否则，哒咩！
SPN分为两种，一种注册在AD上机器帐户(Computers)下，另一种注册在域用户帐户(Users)下
当一个服务的权限为Local System或Network Service，则SPN注册在机器帐户(Computers)下
当一个服务的权限为一个域用户，则SPN注册在域用户帐户(Users)下
注册SPN，直接给结论：
在Windows域里，默认普通机器账号有权注册SPN
普通域用户账号是没有权注册SPN
如果需要域用户能够有注册SPN的权限，需要在DC上为域账号赋予
Read servicePrincipalName 和 Write serverPrincipalName的权限。
