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 name\Client。
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認證