Kerberos 是一种由 MIT（麻省理工大学）提出的一种网络身份验证协议。它旨在通过使用密钥加密技术为客户端/服务器应用程序提供强身份验证。

Kerberos 主要是用在域环境下的身份认证协议。

名词解释

DC(Domain Controller)：域控制器，简称DC，一台计算机，实现用户、计算机的统一管理。

KDC(Key Distribution Center)：秘钥分发中心，简称KDC，默认安装在域控里，包括AS和TGS。

AS(Authentication Service)：身份验证服务，简称AS，用于KDC对Client认证。

TGS(Ticket Grantng Service)：票据授予服务，简称TGS，用于KDC向Client和Server分发Session Key（临时秘钥）。

TGT(Ticket Granting Ticket)：认证票据，用于验证Client的身份

ST(

AD(Active Directory)：活动目录，简称AD，用于存储用户、用户组、域相关的信息。

Client：用户

Server：可以是某台计算机，也可以是某个域内服务

krbtgt用户：创建域控时自动生成的用户

认证过程

1、首先Client要通过AS验证，获得TGT

当某个Client要访问某个Server时，需要AS来进行认证，Client输入用户和密码，并且向KDC发送一个AS_REQ，这个AS_REQ里包含了使用Client的NTLM-Hash加密的时间戳以及Client-info、Server-info等数据，以及一些其他信息。

AS接收到Client发送的AS_REQ，首先向AD询问是否有此用户，有的话则用此用户的NTLM-Hash来对AS_REQ进行解密，如果可以成功解密，且解密后得到的时间戳和和当时时间在5分钟内则为认证成功。

需要认证时间的原因是为了保障此AS_REQ的安全，在传输AS_REQ的过程中，AS_REQ有被黑客截获的风险，黑客截获后如果想要骗取身份则需要重放攻击，这个过程中会花费一定的时间，所以要是时间戳和解密的时间偏差较大则可能遭遇攻击所以不会继续认证。

在这一个过程经历了两个验证，一是Client对AS的验证：如何AS是否为真，所以使用Client的NTLM-Hash进行加密，如果AS为真则可以正常解密AS_REQ；

二是AS如何判断此Client为真，问题仍然在AS_REQ这里，如果Client为真，则AS那Client的NTLM-Hash解密时是可以正确解密出来的。

然后AS会生成一个AS_REP，AS_REP包含两个部分

第一部分AS生成的临时密钥Session-key，然后使用Client的NTLM-Hash加密，用于Client和KDC进行安全通信。

另一部分就是TGT，内容是使用特定用户Krbtgt的NTLM-Hash加密的Session-key(AS生成的)、时间戳以及一些用户信息，这个用户信息就是PAC，PAC包含用户的sid，用户所在的组。

2、然后Client要和TGS认证，获得ST服务票据

当Client收到了AS发回来的AS_REP时，会使用自己的NTLM-Hash，将被加密过的临时秘钥Session-Key进行解密，得到没有被加密的Session-Key，然后将其保存在本地，如果有需要访问某个服务时就可以构成TGS_REQ提交给TGS，来得到对应的ST。

在这个过程中发送的TGS_REQ中包含了使用Session-Key(AS生成的)加密的时间戳以及Client-info、Server-info 等数据，以及一些其他信息，以及使用krbtgt用户NTLM-Hash加密的TGT

当TGS收到TGS_REQ后会首先对使用krbtgt用户NTLM-Hash加密的TGT进行解密，目的是得到Session-Key(AS生成的)、时间戳以及Client-info、Server-info等数据，同理，如果时间戳和解密时间相差太久则终止验证，同时TGS会使用TGT里的Client信息和当前Client的信息进行比较来判断是否为同一人，判断无误后则会判断此Client是否有访问此Server的权限，如果有，则返回一个TGS_REP，由两部分组成。

在这一个过程经历了一个验证：一是TGS如何判断Client为真，所以使用了Session-Key(AS生成的)，这个Session-Key除了DC就只有Client知道。

第一部分为TGS生成的新的Session-key，然后再使用第一个过程AS生成的Session-key进行加密。

第二部分为使用Server的NTLM-Hash加密的Session-key(TGS生成的)、时间戳以及一些用户信息，这个部分就是ST

3、Client和Server通信

Client收到了TGS_REP，获得了加密的Session-key以及ST，和上面的操作一样，先使用刚才储存在本地的Session-key(AS生成的)对Session-key(TGS生成的)进行解密，得到未加密的Session-key(TGS生成的)，然后继续将其和ST一起储存在本地。

在这一个过程经历了一个验证：一是Client如何判断TGS为真，所以使用了Session-Key(AS生成的)，这个Session-Key除了DC就只有Client知道。

当Client需要访问Server时，Client则会发送AP_REQ

AP_REQ包含了使用Session-key(TGS生成的)加密时间戳、Client-info、Server-info等数据，以及一些其他信息，然后再把ST一同发送给Server。

Server收到AP_REQ后会使用自己的NTLM-Hash对ST进行解密，拿到到Session-Key(TGS生成的)，时间戳、Client-info等数据，根据ST内的时间戳和解密时的时间戳进行对比，如果时间超过8小时则为验证失败，然后Server会将PAC发送给DC，询问DC该用户是否有访问权限，来决定Client是否有权限访问Server。

DC拿到PAC会进行解密获取用户的sid，以及所在的组，再判断用户是否有访问服务的权限，有访问权限(有些服务并没有验证PAC这一步，这也是白银票据能成功的前提，因为就算拥有用户hash，可以制作TGS，也不能制作PAC，PAC当然也验证不成功，但是有些服务不去验证PAC，这是白银票据成功的前提）就允许用户访问。

特别说明的是，PAC对于用户和服务全程都是不可见的。只有KDC能制作和查看PAC。

PAC

PAC的作用是用来验证用户是否有权限来访问服务，如果没有PAC，那么只需要拿到Hash就可以访问任何服务了，所以加入PAC是为了即使获得了Hash但是也会判断用户是否有权限访问某项服务。

详细看：PAC在Kerberos认证协议中的作用（一） | Microsoft Docs

总结

从这个过程中可以看出，整个认证过程其实最主要就是两部分

一是DC需要知道提交内容的人是否是Cilent；二是Client需要知道发放内容的人是否是DC，这个过程有点像CSRF的防御，都需要一个黑客无法伪造的内容，然而，这个内容并非完全安全，所以Kerberos协议才会有利用的点

比如黄金票据（Golden ticket）

当黑客可以获得Krbtgt 用户的NTLM-Hash就代表着黑客黑客就可以伪造TGT

又或者是白银票据（Silver ticket）

白银票据不同于黄金票据，白银票据的利用过程是伪造 TGS，通过已知的授权服务密码生成一张可以访问该服务的 TGT。因为在票据生成过程中不需要使用 KDC，所以可以绕过域控制器，很少留下日志。而黄金票据在利用过程中由 KDC 颁发 TGT，并且在生成伪造的 TGT 得 20 分钟内，TGS不会对该 TGT 的真伪进行效验。

白银票据依赖于服务账号的密码散列值，这不同于黄金票据利用需要使用 Krbtgt 账号的密码哈希值，因此更加隐蔽。

Kerberos协议认证过程确实比较难理解，可以看知乎的回答来辅助理解能用通用的语言介绍下 Kerberos 协议么？ - 知乎 (zhihu.com)

至于Kerberos协议的利用方法在以后的文章再发，由于我也不是很深入了解，也是看了别人的文章做的一个总结，如果有什么问题欢迎讨论。