PAC是Kerberos认证中实现“身份验证+权限判定”闭环的关键，它由KDC生成并签名，内含用户SID、组信息等授权数据，嵌入TGT和ST票据中，经双签名（PAC_SERVER_CHECKSUM与PAC_PRIVSVR_CHECKSUM）保障不可篡改，服务端通过校验PAC生成Windows访问令牌完成授权。
在 windows 域环境中，kerberos 认证真正完成“身份验证 + 权限判定”闭环的关键，并不只靠票据（tgt/st）本身，而是依赖其中嵌入的 pac（privilege attribute certificate，特权属性证书）。它不是可选附件，而是微软 kerberos 实现中强制参与授权决策的核心数据块。
PAC 是什么、放在哪儿、谁来管
PAC 是一段由 KDC（域控制器）生成并签名的二进制结构，内含用户 SID、所属组 SID、登录信息、用户权限标志等关键授权数据。它不暴露给客户端或服务端应用层，全程由系统级组件（如 LSASS）处理：
- 首次认证时（AS-REP），PAC 被加密封装进 TGT，随会话密钥一起返回给用户；
- 后续申请服务票据时（TGS-REP），KDC 从 TGT 中解密提取 PAC，校验签名完整性后，重新封装进发给服务端的 Service Ticket；
- 服务端收到 KRB_AP_REQ 后，调用系统 API（如 LsaLogonUser）解析 PAC，生成 Windows 访问令牌（Access Token），再与资源 ACL 匹配完成授权。
PAC 的双签名机制与防篡改设计
PAC 结构末尾包含两个独立数字签名，用于保障其不可伪造和不可篡改：
- PAC_SERVER_CHECKSUM：由目标服务账户（如 HTTP/web01、CIFS/file01）的密码派生密钥生成，供服务端本地验证；
- PAC_PRIVSVR_CHECKSUM：由 KDC（krbtgt 账户）密钥生成，确保 PAC 来源可信且未被中间节点修改。
任一签名验证失败，Windows 就会拒绝生成令牌，表现为 401 错误、登录失败或“访问被拒绝”，即使票据本身解密成功。
常见 PAC 相关问题与排查方向
很多 Kerberos 故障表面是“认证失败”，实际根源在 PAC 缺失、损坏或签名不匹配：
- 非交互式登录（如 Java kinit、curl + SPNEGO）常因未启用预认证（pre-authentication），导致 KDC 不发放带 PAC 的 TGT —— 抓包可见 AS-REP 返回票据仅约 200 字节，远小于正常带 PAC 的 800+ 字节；
- 委派（Delegation）场景下，若服务账户未配置“信任此计算机用于委派”或未启用基于资源的约束委派（RBCE），TGS 可能剥离 PAC 或拒绝转发；
- MS14-068 漏洞利用正是通过伪造 PAC_SERVER_CHECKSUM 和 PAC_PRIVSVR_CHECKSUM，向 TGT 注入高权限组 SID，实现权限提升；
- 时间偏差超过 5 分钟、krbtgt 密码轮换未同步、或域功能级别过低（如 Windows 2000 混合模式），都可能导致 PAC 签名验证失败。
如何查看和验证 PAC 状态
日常运维中无需手动解析二进制 PAC，但可通过以下方式间接确认其存在与有效性：
- 使用 klist tickets 查看票据详情，带 PAC 的票据通常显示 “PAC: Present” 或包含 “Has PAC” 标识；
- 开启域控制器上的 Kerberos 事件日志（Event ID 4768/4769），检查字段 “Ticket Encryption Type” 和 “Certificate Issuer Name” 是否异常；
- 在服务端启用详细安全审核策略（如 “Audit Sensitive Privilege Use”），观察 LSASS 是否报错 “0xC000006D”（状态码表示 PAC 验证失败）；
- 抓包分析 Wireshark 中 KRB_TGS_REP 流量，用域控密钥解密 Service Ticket 后，用 ASN.1 解码器定位 PAC-CLIENT-ID、PAC-CREDENTIALS 等 OID 字段。
