Kerberos委派
1. 介绍
Kerberos 协议允许用户向某个服务进行身份验证以便使用该服务，而 Kerberos 委派 则使该服务能够以原始用户的身份，向另一个服务进行身份验证。大致流程如下
在此示例中，用户向
WEBSRV进行身份验证以访问网站。在网站上进行身份验证后，用户需要访问存储在数据库中的信息，但不应被授予访问其中所有信息的权限。这时候网站的服务账户WEBSRV$,就伪装成用户去访问DBSRV。这就是委派
委派一般有一下三种类型：
- 非约束性委派：在服务A上配置，配置后服务A可以模拟用户的身份访问服务B以及其他任何服务
- 约束性委派：在服务A上配置，配置后服务A可以模拟用户的身份访问服务B
- 基于资源的约束委派（RBCD）：在服务B上配置，配置后仅允许服务A模拟特定用户如用户A的身份访问服务B（从目标来说的，目标资源指定哪些服务能够代表用户访问它）
2. 三种委派
2.1. 无约束委派 Unconstrained Delegation
2.1.1. 介绍
无约束委托允许服务（此处为 WEBSRV ）在访问 any other service 时模拟用户。这是一种非常宽松且危险的权限，因此，并非任何用户都可以授予此权限。
2.1.2. 配置无约束委派
在账户的 Delegation 选项卡上选中 Trust this computer for delegation to any service (Kerberos only) 选项
执行此操作需要拥有 SeEnableDelegationPrivilege 权限，服务账户无法自己修改自己
当启用此选项时，此服务账户的User Account Control(UAC) 标志中会设置TRUSTED_FOR_DELEGATION标志
当一个服务账户被设置了TRUSTED_FOR_DELEGATION标志时，且有用户发起 TGS 请求以访问该服务时，域控制器会将该用户 TGT的一个副本 添加到返回的 TGS 票据中。
通过这种方式，服务账户可以从票据中提取出这个 TGT 副本，从而利用该副本向域控制器发起 TGS 请求。因此，该服务将拥有与该用户身份一致的有效 TGS 票据（即服务票据 ST），并能够以该用户的身份访问任何服务。
更多利用相关的知识点请看非约束委派
2.2. 约束委派 Constrained Delegation
2.2.1. 介绍
由于无约束委派限制性不强， 约束委派是另一种“限制性更强”的委派类型。这种委派下，服务仅有权在访问特定的服务列表时模拟用户。在此示例中， WEBSRV 只能将身份验证中继到 SQL/DBSRV 服务，而不能中继到其他服务。
2.2.2. 配置 约束委派
“约束性委派（Constrained Delegation）的配置路径与无约束委派相同，都在服务账户的‘委派（Delegation）’选项卡中
应当选择‘仅信任此计算机来委派指定的服务
与非约束委派一样，默认情况下服务账户无法修改此选项。启用此选项后，允许委派的服务列表将存储在负责委派的服务账户的
msDS-AllowedToDelegateTo属性中
在无约束委派中，用户 TGT 的副本会被发送给服务账户，但约束性委派（Constrained Delegation）的情况并非如此。如果服务账户（在此例中为 WEBSRV）希望代表用户向某个资源（SQL/DBSRV）进行身份验证，它必须向域控制器发起一种特殊的 TGS 请求。与传统的 TGS 请求相比，该请求将修改两个字段
additional tickets字段将包含用户发送给服务的 TGS 票据或服务票据的副本。cname-in-addl-tkt标志将被设置，以指示域控制器不应使用服务器信息，而应使用additional tickets中的票据信息，即服务器想要模拟的用户信息。
随后，域控制器将验证该服务是否有权将身份验证委派给所请求的资源，并检查 TGS 票据副本是否是可转发的（Forwardable）（票据默认是可转发的，但如果用户的 UAC 标志中设置了‘账户敏感且不能被委派Account is sensitive and cannot be delegated，则该功能会被禁用）
如果一切顺利，它将返回一个 TGS 票据或服务票据给服务，其中包含要委派以访问最终资源的用户信息
2.3. 基于资源的约束委派 RBCD
2.3.1. 介绍
在此之前，委派管理是在‘发起委派的服务’（即想要模拟用户去访问资源的服务）级别进行的。而基于资源的约束性委派（Resource-based Constrained Delegation，简称 RBCD） 则是反过来的，将委派管理权转移到了最终资源的一侧。
我们通过在资源上配置信任列表，允许此列表内的账户可以有权委派身份验证访问此资源
此示例中，资源DBSRV$ 的信任列表仅包含账户 WEBSRV$ 。因此只有WEBSRV$有权模拟用户来访问DBSRV提供的服务，其他服务账号则无法委派身份验证
与另外两种委派类型不同，资源有权修改自己的受信任列表。因此，任何服务账户都有权修改其受信任列表，以允许一个或多个账户向其委派身份验证。
如果服务账户向其受信任列表中添加一个或多个账户，它会更新其 msDS-AllowedToActOnBehalfOfOtherIdentity 属性
#把WEBSRV 添加到 DBSRV 的受信任列表中
PS C:\Tools> Import-Module ActiveDirectory
PS C:\Tools> Set-ADComputer DBSRV -PrincipalsAllowedToDelegateToAccount (Get-ADComputer WEBSRV)
与约束委派相同。服务账户会向域控制器发起一个 TGS 请求，以访问特定资源。该请求中嵌入了用户 TGS 票据的副本。然后，域控制器会检查该服务是否确实在所请求资源的信任列表中。如果是，它将向该服务提供一个 TGS 票据，以便其以用户身份访问该资源。
3. S4U2Proxy & S4U2Self
S4U2Proxy （Service for User to Proxy）和 S4U2Self （Service for User to Self）是 Active Directory 是用于委派的的两个扩展
3.1. S4U2Proxy
这一扩展对应于服务账户为了模拟用户而发起的 TGS 请求。服务账户发起该 TGS 请求是为了访问特定的资源，并且在该请求中嵌入了用户 TGS 票据的副本。
随后，域控制器会检查该服务是否有权将身份验证委派给所请求的资源。如果是这种情况，域控制器将向该服务提供一个 TGS 票据，使其能够以该用户的身份访问该资源。
3.2. S4U2Self
但是，如果用户在没有使用 Kerberos 协议的情况下（因此也就没有提供 TGS 票据）向服务进行了身份验证，例如，当身份验证机制使用的是 NTLM 协议时，就需要用到S4U2Self了
这一步（S4U2Self）是在 S4U2Proxy 之前完成的，因为服务账户此时手中并没有任何可以嵌入到请求中的用户 TGS 票据。
S4U2Self 扩展允许服务代表任意用户获取一张发往该服务自身的可转发（Forwardable） TGS 票据。因此，当用户通过 NTLM 等方式向服务进行身份验证时，服务会先代表该用户请求一张发往自身的可转发 TGS 票据，以此来模拟用户已经通过 Kerberos 完成了验证。
一旦服务拥有了这张特殊的 TGS 票据，它就可以发起 TGS 请求以使用目标资源（即 S4U2Proxy 过程），并将刚刚申请到的这张全新的可转发 TGS 票据嵌入其中。
该扩展协议允许在用户与不同服务之间所使用的身份验证协议不一致的情况下进行委派。这被称为协议转换（Protocol Transition）
正因如此，这一特性在约束性委派中是可以被启用或禁用的
- 如果选择了仅使用 Kerberos选项，那么服务账户就无法进行协议转换，因此也就无法使用 S4U2Self 扩展。
- 如果设置了使用任意身份验证协议选项，那么服务账户就可以使用 S4U2Self 扩展，从而能够为任意用户创建 TGS 票据。
