PAC是kerberos服务票证的扩展，其中包含<font style="color:rgb(32, 33, 36);">各种授权信息、、附加凭据信息、配置文件和策略，例如用户所属的用户组、用户所具有的权限</font>，由于在域中不同权限的用户能够访问的资源是不同的，因此微软设计PAC用来辨别用户身份和权限，当用户在Active Directory(AD)域中进行身份验证时，域控制器会将 PAC 信息添加到kerberos票证。当kerberos票证服务用于向其他系统进行身份验证时，它们可以从用户的票证中检索PAC以确定它们的特权级别，而无需查询域控制器。

PAC 凭证信息：

PAC_LOGON_INFO的类型为Logon info，包含kerberos票据客户端的凭据信息

字段含义：

  • Acct Name：对于的值是用户 sAMAccountName属性的值（sAMAccountName：用户命名属性 - Win32 apps)
  • Full Name：对应的值是用户displayName属性的值(displayName 属性值是一个字符串，用于在用户界面中显示用户的名字。它可以是用户的真实姓名，也可以是一个昵称或者一个简短的描述)
  • User RID：对应的值是用户的RID，也就是用户SID最后的部分，代表用户的权限。
  • Group RID：域用户的Group RID恒为513（也就是Domain Users 的RID），机器用户的Group RID 恒为515（也就是Domain Computers 的RID），域控的RID恒为516（也就是Domain Controllers的RID）
  • Num RIDS：用户所属组的个数
  • GroupIDS：用户所属的所有组的RID

PAC 签名：

PAC中包含两个数字签名：PAC_SERVER_CHECKSUM和PAC_PRIVSVR_CHECKSUM。

PAC_SERVER_CHECKSUM是用服务密匙进行签名，而PAC_PRIVSVR_CHECKSUM使用KDC密匙进行签名，签名的原因有两个：

  1. 存在带有服务密匙的签名，以验证此PAC服务已由服务签名。
  2. 带有KDC密匙的签名是为了防止不受信任的服务用无效的PAC为自己伪造票据。

两个签名的类型分别为 PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM 类型的

PAC_INFO_BUFFFER发送。在PAC数据用于访问控制之前，必须检验带有PAC_SERVER_CHECKSUM的签名，因为这将验证客户端是否知道服务的密匙。而PAC_PRIVSVR_CHECKSUM签名是可选的，默认不开启。它将验证PAC是否由KDC签发，而不是由KDC以外的具有访问服务密匙的第三方放入票据中。

KDC验证PAC：

当客户端接收到AP_REQ消息时，只能校验PAC_SERVER_CHECKSUM签名，并不能校验PAC_PRIVSVR_CHECKSUM 签名。

因为，如果要检验PAC_PRIVSVR_CHECKSUM签名，服务端还需要将客户端发来的ST签名中的PAC签名发回KDC进行校验。但是大部分服务默认没有开启KDC验证PAC这一步（需要目标服务主机配置为验证KDC PAC签名，默认未开启），因此服务端就无须将ST中的PAC签名发送到KDC校验了。

这也是白银票据攻击成功的前提，因为如果目标服务主机为需要校验PAC_PRIVSVR_CHECKSUM签名，服务器会将这个PAC的数字签名的结果以KRB_VERIFY_PAC的消息通过RPC协议发送给KDC，KDC再将验证后这个PAC的结果以RPC返回码的形式发送回服务端，服务端根据返回的结果判断PAC的真实性与有效性。这样就算攻击者拥有服务密匙，制作ST票据，也无法伪造PAC_PRIVSVR_CHECKSUM签名，自然无法通过KDC签名校验了。

注意：再本地系统账户下的服务，无论如果配置都不会触发KDC签名验证，也就是说SMB、CIFS、HOST等服务，无论如何都不会触发KDC验证PAC签名。

为什么KDC默认不验证PAC签名？

如果执行KDC验证PAC，意味着有响应时间和带宽使用方面的成本。它需要占用带宽在应用服务器和KDC之间传输请求和响应，这可能导致大容量应用程序服务器中出现了一些性能问题。这样的环境中可能导致额外的网络延迟和大量流量。

:::danger PAC是微软的一个特性，所以启用了PAC的域中不支持其他操作系统的的服务器，制约了域配置的灵活性。

:::

参考

AD学习笔记