kerberos 之TGS_REQ、TGS_REP

简述

在TGS_REQ & TGS_REP阶段，用户通过AS_REP拿到的TGT票据，去向KDC申请特定服务的访问权限，KDC校验TGT票据，如果校验通过的话，会向用户发送一个TGS票据，之后用户再拿着TGS去访问特定的服务。

TGS_REQ

TGS_REQ这个阶段不需要账号密码，需要AS_REP获取到的TGT凭据,进行本阶段的访问认证。
发送TGS-REQ请求，获取针对某个服务主体（service principal）的服务票据（TGS）。服务主体由SPN（service principal name，服务主体名称）来表示。

TGS_REP

ticket 部分
这个ticket用于AP_REQ的认证。ticket 内的加密部分是使用要访问服务的hash加密的，因此如果我们获得了对应服务的hash即可进行伪造该ticket,称为白银票据，正因为是使用要请求的服务的hash加密的，所以我们可以通过爆破enc_part获得该服务的hash，该问题被称为kerberoasting。

enc_part
在学习过程中，仔细阅读到这部分的内容解答了我之前的一个疑惑，既为什么伪装黄金票据时不需要对session_key进行构造之类的问题。

首先注意一下这个ticket问题，注意，这个enc_part不是ticket里面的enc_part。
这部分是可以解密的==，key是上一轮AS_REP里面返回的session_key,也就是导入凭据里面的 session_key，==解密后得到encryptionkey，encryptionkey这个结构里面最重要的字段也是session_key(但是这个session_key 不同于上一轮里面的session_key)，用来作为作为下阶段的认证密钥。

PAC

PAC是是微软为了访问控制而引进的一个扩展，在访问流程中，PAC解决的是用户若是没有权限访问相关服务的问题，在最后服务会拿着PAC去验证是否让用户进行访问（参考kereros认证基础）；
1、用户向KDC发起AS_REQ,请求凭据是用户hash加密的时间戳，KDC使用用户hash进行解密，如果结果正确返回用krbtgt hash加密的TGT票据，TGT里面包含PAC,PAC包含用户的sid，用户所在的组，后续PAC将一直存在在票据中。

2、户凭借TGT票据向KDC发起针对特定服务的TGS_REQ请求，KDC使用krbtgt hash进行解密，如果结果正确，就返回用服务hash 加密的TGS票据(这一步不管用户有没有访问服务的权限，只要TGT正确，就返回TGS票据，这也是kerberoating能利用的原因，任何一个用户，只要hash正确，可以请求域内任何一个服务的TGS票据

3、用户拿着TGS票据去请求服务，服务使用自己的hash解密TGS票据。如果解密正确，就拿着PAC去KDC那边询问用户有没有访问权限，域控解密PAC。获取用户的sid，以及所在的组，再判断用户是否有访问服务的权限，有访问权限(有些服务并没有验证PAC这一步，这也是白银票据能成功的前提，因为就算拥有用户hash，可以制作TGS，也不能制作PAC，PAC当然也验证不成功，但是有些服务不去验证PAC，这是白银票据成功的前提）就允许用户访问

注释

关于 SPN
SPN 是服务在使用 Kerberos 身份验证的网络上的唯一标识符。 它包含一个服务类、一个主机名，有时也包含一个端口。 HTTP SPN 不需要端口。 在使用 Kerberos 身份验证的网络中，必须在内置计算机帐户（如 NetworkService 或 LocalSystem）或用户帐户下为服务器注册 SPN。 对于内置帐户，SPN 将自动进行注册。 但是，如果在域用户帐户下运行服务，则必须为要使用的帐户手动注册 SPN。

实验部分

待补充

参考

https://www.jianshu.com/p/17ad0aa73755
https://daiker.gitbook.io/windows-protocol/kerberos/2
https://blog.csdn.net/qq_18501087/article/details/102831053
https://www.anquanke.com/post/id/200680
https://docs.microsoft.com/zh-cn/sql/reporting-services/report-server/register-a-service-principal-name-spn-for-a-report-server?view=sql-server-ver15