0x00 前言
对我们搞Web的而言，弄清Kerberos认证过程，最有利于帮助我们理解域内的金票和银票！
0x01 Kerberos介绍
在古希腊神话中Kerberos指的是：有着一只三头犬守护在地狱之门外,禁止任何人类闯入地狱之中。
而现实中的Kerberos是一种网络身份验证协议,旨在通过密钥加密技术为客户端/服务器应用程序提供身份验证,主要用在域环境下的身份验证。
而现实中的Kerberos是一种网络身份验证协议,旨在通过密钥加密技术为客户端/服务器应用程序提供身份验证,主要用在域环境下的身份验证。
通过上图可以看到整个认证流程有三个重要的角色,分别为Client、Server和KDC。下面介绍下几个相关的名词：
1.访问服务的 Client；
2.提供服务的 Server；
3.KDC（Key Distribution Center）密钥分发中心。
在KDC中又分为两个部分：Authentication Service(AS,身份验证服务)和Ticket Granting Service(TGS,票据授权服务)
4.DC是Domain Controller的缩写,即域控制器;AD是Active Directory的缩写,即活动目录。
DC中有一个特殊用户叫做:krbtgt,它是一个无法登录的账户,是在创建域时系统自动创建的,在整个kerberos认证中会多次用到它的Hash值去做验证。
AD会维护一个Account Database(账户数据库). 它存储了域中所有用户的密码Hash和白名单。只有账户密码都在白名单中的Client才能申请到TGT。
0x02 Kerberos认证过程
举个简单的栗子：如果把 Kerberos 中的票据一类比作一张门禁卡,那么 Client 端就是住客,Server 端就是房间,而 KDC 就是小区的门禁。住客想要进入小区,就需要手里的门禁卡与门禁想对应,只有通过门禁的检验,才能打开门禁进入小区。
需要注意的是,小区门禁卡只有一张,而Kerberos认证则需要两张票。
当 Client 想要访问 Server 上的某个服务时,需要先向 AS 证明自己的身份,验证通过后AS会发放的一个TGT,随后Client再次向TGS证明自己的身份,验证通过后TGS会发放一个ST,最后Client向 Server 发起认证请求,这个过程分为三块：
Client 与 AS 的交互,
Client 与 TGS 的交互,
Client 与 Server 的交互。
第一步，Client与AS的交互
准备：用户在Client中输入账号密码后，Client会对密码进行hash code，我们叫做Master key。
请求：
Client 先向 KDC 的 AS 发送 Authenticator(认证者)，我们叫它Authenticator1，为了确保Authenticator1仅限于自己和KDC知道，Client使用自己的Master Key对其的主体部分进行加密。
其内容为：
1.经过 Client用户密码hash code(Master key)加密的TimeStamp(一个当前时间的时间戳)。
2.Client的一些信息(info)，比如用户名。
响应：
(1).AS接收到Authenticator1后，会根据Client提交的用户名在AD中寻找是否在白名单中，然后查询到该用户名的密码，并提取到Client对应的Master key，对TimeStamp(时间戳)进行解密，如果是一个合法的Timestamp，就证明了Client提供的用户名和密码是存在AD中的，并且AS提取到的Timestamp不能超过5分钟，否则AS就会直接拒绝Client的请求。
(2).TimeStamp验证通过后，AS会给Client发送一个由Client的Master key加密过的Logon Session Key和一个TGT(client-server-ticket)。
TGT的内容：
经过KDC中的krbtgt的密码HASH加密的 Logon Session Key(登录会话密钥) 和 TimeStamp(时间戳)、TGS会话密钥、用户信息、TGT到期时间。
注意：
1.Logon Session Key是什么：Client向KDC发起对TGT的申请,”我需要一张TGT用以申请获取用以访问所有Server的Ticket”。KDC在收到该申请请求后，生成一个用于该Client和KDC进行安全通信的Session Key（SKDC-Client，也被称为Logon Session Key)。这里KDC不会保存SKDC-Client。
需要注意的是SKDC-Client是一个Session Key，他具有自己的生命周期，同时TGT和Session相互关联，当Logon Session Key过期，TGT也就宣告失效，此后Client不得不重新向KDC申请新的TGT，KDC将会生成一个不同Session Key和与之关联的TGT
2.第二步会有一个Session Key ，是用于Client和Server之间通信的Session Key（SServer-Client）
请求：
Client 先向 KDC 的 AS 发送 Authenticator(认证者)，我们叫它Authenticator1，为了确保Authenticator1仅限于自己和KDC知道，Client使用自己的Master Key对其的主体部分进行加密。
其内容为：
1.经过 Client用户密码hash code(Master key)加密的TimeStamp(一个当前时间的时间戳)。
2.Client的一些信息(info)，比如用户名。
响应：
(1).AS接收到Authenticator1后，会根据Client提交的用户名在AD中寻找是否在白名单中，然后查询到该用户名的密码，并提取到Client对应的Master key，对TimeStamp(时间戳)进行解密，如果是一个合法的Timestamp，就证明了Client提供的用户名和密码是存在AD中的，并且AS提取到的Timestamp不能超过5分钟，否则AS就会直接拒绝Client的请求。
(2).TimeStamp验证通过后，AS会给Client发送一个由Client的Master key加密过的Logon Session Key和一个TGT(client-server-ticket)。
TGT的内容：
经过KDC中的krbtgt的密码HASH加密的 Logon Session Key(登录会话密钥) 和 TimeStamp(时间戳)、TGS会话密钥、用户信息、TGT到期时间。
注意：
1.Logon Session Key是什么：Client向KDC发起对TGT的申请,”我需要一张TGT用以申请获取用以访问所有Server的Ticket”。KDC在收到该申请请求后，生成一个用于该Client和KDC进行安全通信的Session Key（SKDC-Client，也被称为Logon Session Key)。这里KDC不会保存SKDC-Client。
需要注意的是SKDC-Client是一个Session Key，他具有自己的生命周期，同时TGT和Session相互关联，当Logon Session Key过期，TGT也就宣告失效，此后Client不得不重新向KDC申请新的TGT，KDC将会生成一个不同Session Key和与之关联的TGT
2.第二步会有一个Session Key ，是用于Client和Server之间通信的Session Key（SServer-Client）
第二步,Client 与 TGS 的交互,Client使用TGT从KDC获得基于某个Server的Ticket
一、请求：Client通过自己的Master key对第一部分解密获得Logon Session Key之后，携带着TGT对TGT发送请求。Client是解不开TGT的，它作为一个Client通过身份验证的票提交给TGS。
请求的内容：
(1).TGT：Client通过与AS交互获得的TGT，TGT 被 KDC 的 Master Key 进行加密。
(2).Authenticator2：Client端使用 Logon Session Key对其进行加密，Authenticator2实际上就是关于Client的一些信息和当前时间的一个Timestamp，用以证明当初 TGT 的拥有者是否就是自己。
TGS收到Client请求，验证其真实身份：
TGS 在发给Client真正的Ticket之前，先得整个Client提供的那个TGT是否是AS颁发给它的，于是它得通过 Client 提供的 Authenticator2 来证明。但是 Authentication2 是通过 Client的 Logon Session Key 进行加密的，而TGS并没有保存这个 Logon Session Key 。所以 TGS 先得通过自己的 Master Key{krbtgt的密码hash处理} 对 Client 提供的 TGT 进行解密，从而获得Client Info和 Logon Session Key（SKDC-Client），再通过这个Logon Session Key解密 Authenticator2
获得Client Info，对两个Client Info进行比较进而验证对方的真实身份
二、响应--TGS验证通过后发ST(Service Ticket)票：
响应内容：
认证通过后TGS生成使用Logon Session Key（SKDC-Client）加密过用于Client和Server之间通信的Session Key（SServer-Client），Server的Master Key进行加密的ST(Service Ticket)
(1).经过 Logon session key加密的Client和Server之间的Session Key
(2).经过Server的Master Key进行加密的ST(Service Ticket)。
Ticket大体包含以下一些内容：
Session Key（SServer-Client）
Domain nameClient。
Ticket的到期时间。
Client 收到TGS的响应，使用 Logon session key，解密第一部分后获得 Session Key （注意区分 Logon Session Key 与 Session Key 分别是什么步骤获得的，及其的区别）。有了 Session Key 和 ST(Service Ticket)， Client 就可以直接和 Server 进行交互，而无须在通过 KDC 作中间人了。
第三步，Client 与 Server 的交互--双向验证：
Server验证Client：Client通过与TGS交互获得访问Server的Session Key,然后为了证明自己就是ST(Service Ticket)的真正所有者,会将Authenticator和时间戳提取出来,并使用Session Key进行加密。最后将这个被加密过的Authenticator3 和ST作为请求数据包发送给Server。此外还包含一个Flag用于表示Client是否需要进行双向验证。
Server接收到Request之后,首先通过自己的Master Key(krbtgt的密码hash处理)解密ST,从而获得Session Key。然后通过解密出来的Session Key再去解密Authenticator3 ,进而验证对方的身份。如果验证成功,且时间戳不长于5min,就让 Client 访问对应的资源,否则就会直接拒绝对方的请求。
双向认证：
到目前为止，服务端已经完成了对客户端的验证，但是，整个认证过程还没有结束。接下来就是Client对Server进行验证以确保Client所访问的不是一个钓鱼服务.
Client验证Server：
Server需要将Authenticator3中解密出来的Timestamp再次用Session Key进行加密,并发送给Client。Client再用缓存Session Key进行解密,如果Timestamp和之前的内容完全一样,则可以证明此时的Server是它想访问的Server。
参考文章：Kerberos认证