介紹：
Kerberos 是一種由 MIT（麻省理工大學）提出的一種網絡身份驗證協議。它旨在通過使用密鑰加密技術爲客戶端/服務器應用程序提供強身份驗證。
在 Kerberos 認證中，最主要的問題是如何證明「你是你」的問題，如當一個 Client 去訪問 Server 服務器上的某服務時，Server 如何判斷 Client 是否有權限來訪問自己主機上的服務，同時保證在這個過程中的通訊內容即使被攔截或篡改也不影響通訊的安全性，這正是 Kerberos 解決的問題。在域滲透過程中 Kerberos 協議的攻防也是很重要的存在。
Kerberos 主要是用在域環境下的身份認證協議。
Kerberos 協議框架：
在 Kerberos 協議中主要是有三個角色的存在：
1. 訪問服務的 Client；
2. 提供服務的 Server；
3.KDC（Key Distribution Center）密鑰分發中心
注意：
1、KDC 服務默認會安裝在一個域的域控中
2、從物理層面看，AD與KDC均爲域控制器(Domain Controller)
3、AD其實是一個類似於本機SAM的一個數據庫，全稱叫account database，存儲所有client的白名單，只有存在於白名單的client才能順利申請到TGT
4、KDC 服務框架中包含一個 KRBTGT 賬戶，它是在創建域時系統自動創建的一個賬號，你可以暫時理解爲他就是一個無法登陸的賬號，在發放票據時會使用到它的密碼 HASH 值。
上文提到的TGT，KDC,client，server又是什麼東西呢，下文來介紹下：
Kerberos粗略的驗證流程：
先來舉個例子：如果把 Kerberos 中的票據類比爲一張火車票，那麼 Client 端就是乘客，Server 端就是火車，而 KDC 就是就是車站的認證系統。如果Client端的票據是合法的（由你本人身份證購買並由你本人持有）同時有訪問 Server 端服務的權限（車票對應車次正確）那麼你才能上車。當然和火車票不一樣的是 Kerberos 中有存在兩張票，而火車票從頭到尾只有一張。
在KDC中又分爲兩個部分：Authentication Service和Ticket Granting Service
Authentication Service：AS 的作用就是驗證 Client 端的身份（確定你是身份證上的本人），驗證通過就會給一張 TGT（Ticket Granting Ticket）票給 Client。
Ticket Granting Service：TGS 的作用是通過 AS 發送給 Client 的票（TGT）換取訪問 Server 端的票（上車的票 ST）。ST（ServiceTicket）也被稱之爲 TGS Ticket，爲了和 TGS 區分，在這裏就用 ST 來說明，所以TGS Ticket和ST的意思是一樣的。
這就說明了爲什麼在Kerberos中存有兩種票，其實就是更加細分了其中的驗證，簡單的描述就是首先你拿身份證驗證頭像是不是一樣，是的話就返回一張TGT，然後在通過驗證車票獲得上車的資格，這裏就有對TGT的驗證，通過的話再返回一張ST/TGS Ticket的票，如果都可以那麼就驗證成功了。
Kerberos 詳解認證流程：
當 Client 想要訪問 Server 上的某個服務時，需要先向 AS 證明自己的身份，然後通過 AS 發放的 TGT 向 Server 發起認證請求，這個過程分爲三塊：
The Authentication Service Exchange：Client 與 AS 的交互，
The Ticket-Granting Service (TGS) Exchange：Client 與 TGS 的交互，
The Client/Server Authentication Exchange：Client 與 Server 的交互。
(1)TheAuthentication Service Exchange
KRB_AS_REQ(請求)：
Client->AS：Client 先向 KDC 的 AS 發送 Authenticator1(內容爲Client hash加密的時間戳）
KRB_AS_REP(應答)：
AS-> Client：AS根據用戶名在AD中尋找是否在白名單中，然後根據用戶名提取到對應的NTLM Hash，然後會生成一個隨機數session key，然後返回給Client由Client的ntlm hash加密的session key-as作爲AS數據，再返回TGT（使用KDC中krbtgt的NTLM Hash加密session key和客戶端的信息，客戶端的信息裏面包含了時間戳等信息）
AS驗證的簡述：在 KDC(AD) 中存儲了域中所有用戶的密碼 HASH，當 AS 接收到 Client 的請求之後會根據 KDC 中存儲的密碼來解密，解密成功並且驗證信息。
驗證成功後返回給 Client兩個東西，一個是由 Client 密碼 HASH 加密的 session key-as 和 TGT（由 KRBTGT HASH 加密的 session key 和 TimeStamp 等信息）。
(2)TheTicket-Granting Service (TGS) Exchange
KRB_TGS_REQ(請求)：
Client 接收到了加密後的session key-as 和 TGT 之後，先用自身密碼 HASH解密得到session key ，TGT 是由 KDC 中KRBTGT的HASH加密，所以Client 無法解密。這時 Client 再用session key加密的TimeStamp，然後再和TGT 一起發送給 KDC 中的 TGS（TicketGranting Server）票據授權服務器換取能夠訪問 Server 的票據。
KRB_TGS_REP(應答)：
TGS 收到 Client 發送過來的 TGT 和 Session key 加密的 TimeStamp 之後，首先會檢查自身是否存在 Client 所請求的服務。如果服務存在，則用 KRBTGT的HASH解密 TGT。
一般情況下 TGS 會檢查 TGT 中的時間戳查看 TGT 是否過期，且原始地址是否和 TGT 中保存的地址相同。
驗證成功之後將返回Client兩個東西，一個是用 session key 加密的 session key-tgs，然後另一個是 Client要訪問的Server的密碼 HASH 加密的 session key-tgs（前面和session key加密生成的）生成就是ST（TGS）
(3)TheClient/Server Authentication Exchange
KRB_AP_REQ(請求)：
Client -> Server 發送 Authenticator3(session key-tgs 加密 TimeStamp) 和票據 ST(Server 密碼 HASH 加密 session key-tgs)
Client 收到 session key 加密生成的 session key-tgs 和 Server 密碼 HASH 加密 session key-tgs生成的TGS 之後，用 session key 解密得到 session key-tgs，然後把 sessionkey-tgs 加密的 TimeStamp 和 ST（也就是TGS）一起發送給 Server。
KRB_AP_REP(應答)：
Server-> Client
server 通過自己的密碼解密 ST，得到 sessionkey-tgs, 再用 sessionkey-tgs 解密 Authenticator3 得到 TimeStamp，驗證正確返回驗證成功。
上文文字描述的也就是最開頭的圖片，這裏再放上去，是不是會發現這張圖理解了？？？
參考文章：https://tools.ietf.org/html/rfc4120.html
參考文章：https://www.freebuf.com/articles/system/196434.html