本文主要是介绍复现kerberos认证过程、黄金票据，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
目录
了解Kerberos协议
第一步：客户端向DC的AS请求
第二步：DC的AS想客户端的全球做出响应
第三步：客户端向DC的TGS 请求
第四步：DC的TGS向客户端的请求做出响应
第五步：客户端向服务器请求
第六步：服务器向DC的KDC的请求
第七步：DC的KDC向服务端响应
第八步：服务端向客户端响应
了解Kerberos协议
在Kerberos协议中，主要有以下三个角色：
-
访问服务的客户端（cilent简写c）：Kerberos客户端是代表需要访问资源的用户进行操作的用程序，例如打开文件、查询数据库或打印文档。每个Kerberos客户端在访问资源之前都会请求身份验证。
-
提供服务的服务端（server简写s）：域内提供服务的服务端，服务端都有一个独一的SPN。
-
提供认证服务的KDC(Key Distribution Center，密钥分发中心)：KDC密钥发行中心是一种网络服务，它向活动目录域内的用户和计算机提供会话票据和临时会话密钥，其服务帐户为krbtgt。KDC作为活动目录域服务ADDS的一部分运行在每个域控制器上。 这里说一下krbtgt帐户，该用户是在创建活动目录时系统自动创建的一个账号，其作用是KDC密钥发行中心的服务账号，其密码是系统随机生成的，无法正常登陆主机。以下是Kerberos认证整个流程图：
第一步：客户端向DC的AS请求
此时客户端本机的Kerberos服务会向KDC的AS认证服务发送AS-REQ认证请求，请求内容包括
客户端的个人信息即principal如用户名，以及说明要请求什么服务、目标服务的主机名等信息，
告诉AS自己将与TGS通信。除此之外为了防止别人伪造这个客户端的身份，还要求发送一个认
因子authenticator，这个认证因子需要使用客户端的hash来加密一个时间戳。
第二步：DC的AS想客户端的全球做出响应
此时AS收到了客户端的请求之后，由于AS是在DC上面的，DC是有客户端的hash的，此时会查
AD目录找到该客户端的hash，然后对时间戳进行解密，如果解密失败说明用于加密的hash是错
的，同时验证是否为受到了重放攻击。
在AS验证通过之后，AS会生成一个login session key，并且使用用户的hash加密这个login
session key，然后AS还会生成一个TGT，同使用过hash加密后的login session key以及一些其
相关信息打包发送给客户端。
第三步：客户端向DC的TGS 请求
此时客户端收到了DC的的响应包之后会将收到的TGT存储在本地，并使用自己的hash将对应使、
自己的hash加密的信息进行解密，获取到AS生成的login session key，然后客户端使用login
session key去加密时间戳然后与收到的TGT、需要的服务名字、自己的相关信息一同打包发送
DC的TGS。
关于krbtgt
krbtgt是Kerberos中的一个特殊账户，用于存储和管理Ticket Granting Ticket（TGT）。
Kerberos认证系统中，krbtgt账户是一个系统级别的账户，用于生成TGT和使用自己的has
（krbtgt hash）加密TGT，并提供给用户进行身份验证和获取服务票据。那么如果攻击者获取到
这个hash（krbtgt hash），那么就可以任意的伪造TGT了，也就是黄金票据，拥有了黄金票据就
以跳过AS验证了。
第四步：DC的TGS向客户端的请求做出响应
当TGS接收到请求之后，会检查自身是否存在客户端请求的服务，如果存在就会拿ktbtgt hash解
TGT（由于TGS是在DC上的，所有具有krbtgt的hash），解密到的信息中包含了login session
key，别忘了客户端发过来的时间戳就是利用login session key加密的，此时就可以用其解密获
到时间戳了，然后验证时间戳。
然后KDC会生成一个新的名叫service session key，用于客户端和服务端直接的安全通信，并且
客户端生成ST服务票据，该票据是由客户端信息+service session key打包后用后用服务端的has
加密的（KDC在DC上，故DC拥有服务端的hash）。除此之外会将service session key用之前
login session key加密同ST一同打包发送给客户端。
此时为什么要用服务端的hash加密service session key？
因为为了保证service session key不被窃取不可明文传输且后期客户端和服务端要使用service
session key进行安全通信，而服务端没有login session key，DC就使用服务端的hash进行加密
同时还可以防止非目标服务器窃取这个service session key，因为只有知道服务端的hash才能获
service session key，进一步保证了service session key的安全。如果攻击者窃取了服务端的has
那么就可以任意伪造ST也就是白银票据了，就可以不经过KDC了。
第五步：客户端向服务器请求
此时客户端接收到了TGS的响应，然后利用login session key解密获取到service session key，
后用于与服务端通信，同时将ST存储起来，然后客户端用service session key加密客户端信息和
间戳同ST（服务端hash加密的相关信息+service session key）打包一起发送给服务端验证。
第六步：服务器向DC的KDC的请求
客户端收到服务端发送过来的信息之后，用自己的hash即服务端hash解密ST，而ST中包括
service session key，那么再用service session key去解密使用service session key加密的信息包
有客户端相关信息和时间戳，再去验证这个时间戳，判断是否安全，判断是否为真实身份。
除此之外服务端还要向DC请求，使用PAC（Privilege Attribute Certificate）将客户端的属性信息
送给KDC进行验证客户端是否安全是否具有获取该服务的资格。
第七步：DC的KDC向服务端响应
此时KDC将会对服务端发来的PAC进行一个验证，验证流程如下
1.KDC首先会检查PAC中的票据（Ticket）是否有效，即检查票据的签名是否正确、是否过期等
这是基本的票据验证过程，确保票据本身是合法的。
2.KDC会从PAC中提取出客户端的属性信息，如授权信息、组成员资格等。
3.KDC会与自身存储的客户端属性信息进行比对，以验证PAC中的属性信息是否与KDC中存储的
息一致。这样可以确保客户端的属性信息没有被篡改或伪造。
4.如果PAC中的属性信息与KDC中存储的信息一致，KDC将认为PAC是有效的，并返回一个验证
功的响应给服务端。反之如果PAC中的属性信息与KDC中存储的信息不一致，KDC将认为PAC
无效的，并返回一个验证失败的响应给服务端。
第八步：服务端向客户端响应
此时服务端会生成一个票据，该票据包括客户端身份信息，以及服务端的身份信息，并使用之前
得的service session key去加密该票据信息并发送给客户端，然后客户端就可以正常获取到服务
的服务了。
这篇关于复现kerberos认证过程、黄金票据的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
