委派

域委派是指，将域内用户的权限委派给服务账号，使得服务账号能以用户权限开展域内活动。

服务账号（Service Account），域内用户的一种类型，服务器运行服务时所用的账号，将服务运行起来并加入域。例如MS SQL Server在安装时，会在域内自动注册服务账号SqlServiceAccount，这类账号不能用于交互式登录。

上图是经典的应用场景。一个域内普通用户jack通过Kerberos协议认证到前台WEB服后，前台运行WEB服务的服务账号websvc模拟（Impersonate）用户jack，以Kerberos协议继续认证到后台服务器，从而在后台服务器中获取jack用户的访问权限，即域中跳或者多跳的Kerberos认证。按照图中红色字体的数字，具体步骤如下：

•域内用户jack以Kerberos方式认证后访问Web服务器；•Web服务以websvc服务账号运行，websvc向KDC发起jack用户的票据申请；•KDC检查websvc用户的委派属性，如果被设置，则返回jack用户的可转发票据TGT；•websvc收到jack用户TGT后，使用该票据向KDC申请访问文件服务器的服务票据TGS；•KDC检查websvc的委派属性，如果被设置，且申请的文件服务在允许的列表清单中，则返回一个jack用户访问文件服务的授权票据TGS；•websvc收到的jack用户的授权票据TGS后，可访问文件服务，完成多跳认证。

在域中，只有 服务账号 和 主机账号 才具有委派属性

主机账号就是AD活动目录中 Computers 中的计算机，也可以称为机器账号(一个普通域用户默认最多可以创建十个主机账号)。
服务账号（Service Account）是域内用户的一种类型，是服务器运行服务时所用的账号，将服务运行起来并加入域。例如SQL Server 在安装时，会在域内自动注册服务账号 SQLServiceAccount。也可以将域用户通过注册SPN变为服务账号。

委派的前提

需要被委派的用户未设置不允许被委派属性。

如果勾上则administrator账户不能被委派

非约束性委派

对于非约束性委派，服务账号可以获取被委派用户的TGT，并将TGT缓存到LSASS进程中，从而服务账号可使用该TGT，模拟用户访问任意服务。

当服务账号或者主机被设置为非约束性委派时，其userAccountControl属性会包含WORKSTATION_TRUSTED_FOR_DELEGATION

从网络攻击的角度看，如果攻击者控制了服务账号B，并诱骗管理员来访问服务A，则可以获取管理员的TGT，进而模拟管理员访问任意服务，即获得管理员权限。越是大型网络、应用越多的网络，服务账号越多，委派的应用越多，越容易获取域管理员权限。

约束性委派

由于非约束委派的不安全性，微软在Windows Server 2003中发布了约束性委派。对于约束性委派（Constrained Delegation），即Kerberos的两个扩展子协议 S4u2self (Service for User to Self) 和 S4u2Proxy (Service for User to Proxy )，服务账号只能获取用户的TGS，从而只能模拟用户访问特定的服务。

配置了约束委派的账户的 userAccountControl 属性有个FLAG位 TRUSTED_TO_AUTH_FOR_DELEGATION，并且msDS-AllowedToDelegateTo 属性还会指定对哪个SPN进行委派。

基于资源的约束性委派

为了使用户/资源更加独立，微软在Windows Server 2012中引入了基于资源的约束性委派。基于资源的约束委派不需要域管理员权限去设置，而把设置属性的权限赋予给了机器自身。基于资源的约束性委派允许资源配置受信任的帐户委派给他们。基于资源的约束委派只能在运行Windows Server 2012和Windows Server 2012 R2及以上的域控制器上配置，但可以在混合模式林中应用。配置了基于资源的约束委派的账户的 userAccountControl 属性为 WORKSTATION_TRUST_ACCOUNT，并且msDS-AllowedToActOnBehalfOfOtherIdentity 属性的值为被允许基于资源约束性委派的账号的SID。

基于资源的约束性委派和约束性委派差别

委派的权限授予给了拥有资源的后端(B)，而不再是前端(A)

约束性委派不能跨域进行委派，基于资源的约束性委派可以跨域和林

不再需要域管理员权限设置委派，只需拥有在计算机对象上编辑”msDS-AllowedToActOnBehalfOfOtherIdentity”属性的权限，也就是 将计算机加入域的域用户 和 机器自身 拥有权限。

传统的约束委派是“正向的”，通过修改服务A的属性”msDS-AllowedToDelegateTo”，添加服务B的SPN（Service Principle Name），设置约束委派对象（服务B），服务A便可以模拟用户向域控制器请求访问服务B的ST服务票据。

而基于资源的约束委派则是相反的，通过修改服务B属性”msDS-AllowedToActOnBehalfOfOtherIdentity”，添加服务A的SID，达到让服务A模拟用户访问B资源的目的。

非约束委派和约束委派的流程

1.非约束委派流程

**前提：**在机器账号B上配置了非约束性委派(域管理员才有权限配置)

1.用户访问机器B的某个服务，于是向KDC认证。KDC会检查机器B的机器账号的属性，发现是非约束性委派，KDC会将用户的TGT放在ST服务票据中。

2.用户访问机器B时，TGT票据会和ST服务票据一同发送给机器B

3.这样B在验证ST服务票据的同时获取了用户的TGT，并将TGT存储在LSASS进程中，从而可以模拟用户访问任意服务

从网络攻击的角度来看，如果攻击者控制了机器B的机器账号，并且机器B配置了非约束性委派。则攻击者可以诱骗管理员来访问机器B，然后攻击者可以获取管理员的TGT，从而模拟管理员访问任意服务，即获得了管理员权限。

2.约束性委派流程

**前提：**在服务A上配置到服务B约束性委派(域管理员才有权限配置)

1.用户访问服务A，于是向域控进行kerberos认证，域控返回ST1服务票据给用户，用户使用此服务票据访问服务A

2.若该服务A允许委派给服务B，则A能使用S4U2Proxy协议将用户发送给自己的可转发的ST1服务票据以用户的身份再转发给域控制器。于是域控返回给服务A一个ST2服务票据，

3.服务A便能使用获得的ST2服务票据以用户的身份访问服务B。

从网络攻击的角度来看，如果攻击者控制了服务A的账号，并且服务A配置了到域控的CIFS服务的约束性委派。则攻击者可以利用服务A以administrator身份访问域控的CIFS服务，即相当于控制了域控。

筛选非委派属性的账号

注：域控主机账户默认开启非约束委派

1.PowerSploit下的PowerView.ps1脚本

Import-Module .\PowerView.ps1;
 
查询域中配置非约束委派的账户
Get-NetUser -Unconstrained -Domain 0day.org
Get-NetUser -Unconstrained -Domain 0day.org | select name
查询域中配置非约束委派的主机：
Get-NetComputer -Unconstrained -Domain 0day.org | select name

2.ADFind

使用参数

AdFind [switches] [-b basedn] [-f filter] [attr list]

参数说明：

•-b：指定要查询的根节点•-f：LDAP过滤条件•attr list：需要显示的属性

查找域中配置非约束委派的用户：

AdFind.exe -b "DC=0day,DC=org" -f "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

查找域中配置非约束委派的主机：

AdFind.exe -b "DC=0day,DC=org" -f "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" cn distinguishedName

3.ldapsearch

kali自带，可以在域外使用

查找域中配置非约束委派的用户：

ldapsearch -x -H ldap://192.168.200.143:389 -D "CN=administrator,CN=Users,DC=0day,DC=org" -w admin\!\@\#45 -b "DC=0day,DC=org" "(&(samAccountType=805306368)(userAccountControl:1.2.840.113556.1.4.803:=524288))" |grep -iE "distinguishedName"

查找域中配置非约束委派的主机：

ldapsearch -x -H ldap://192.168.200.146:389 -D "CN=administrator,CN=Users,DC=0day,DC=org" -w admin\!\@\#45 -b "DC=0day,DC=org" "(&(samAccountType=805306369)(userAccountControl:1.2.840.113556.1.4.803:=524288))" |grep -iE "distinguishedName"

筛选约束性委派属性的账号

1.ldapsearch

查找域中配置约束委派用户:

ldapsearch -x -H ldap://192.168.200.146:389 -D "CN=administrator,CN=Users,DC=0day,DC=org" -w admin\!\@\#45 -b "DC=0day,DC=org" "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"

查找域中配置约束委派的主机：

ldapsearch -x -H ldap://192.168.200.146:389 -D "CN=administrator,CN=Users,DC=0day,DC=org" -w admin\!\@\#45 -b "DC=0day,DC=org" "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" |grep -iE "distinguishedName|allowedtodelegateto"

2.ADFind

查找域中配置约束委派用户:

AdFind.exe -b "DC=0day,DC=org" -f "(&(samAccountType=805306368)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

查找域中配置约束委派的主机：

AdFind.exe -b "DC=0day,DC=org" -f "(&(samAccountType=805306369)(msds-allowedtodelegateto=*))" cn distinguishedName msds-allowedtodelegateto

3.Empire下的PowerView.ps1脚本

Import-Module .\powerview.ps1;
 
查询域中配置约束委派的账号
Get-DomainUser -TrustedToAuth -Domain 0day.org | select name
或
Get-DomainUser -TrustedToAuth -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto| fl
查询域中配置约束委派的主机
Get-DomainComputer -TrustedToAuth -Domain 0day.org | select name
或
Get-DomainComputer -TrustedToAuth -Properties distinguishedname,useraccountcontrol,msds-allowedtodelegateto|ft -Wrap -AutoSize

查询某用户是否具有委派性

Import-Module .\powerview.ps1;Get-DomainUser 域用户名 -Properties  useraccountcontrol,msds-allowedtodelegateto| fl

当该账号没委派属性时，查询不出任何信息

当服务账号被设置为 **非约束性委派 **时，其 userAccountControl 属性会包含为 TRUSTED_FOR_DELEGATION

当被设置为 **约束性委派 **时，其userAccountControl属性包含 TRUSTED_TO_AUTH_FOR_DELEGATION，且 msds-allowedtodelegateto 属性会被设置为哪些 SPN。