在Windows中的身份認證方式有很多，也在不斷的升級，但是在域中，依舊使用的是Kerberos認證。
Kerberos 是一種網絡認證協議，它的實現不依賴於主機操作系統的認證，無需基於主機地址的信任，不要求網絡上所有主機的物理安全，並假定網絡上傳送的數據包可以被任意地讀取、修改和插入數據，也就是說它的認證完全是從一個不安全的網絡環境出發進行認證的，它是擁有第三方信托機構的，與上一篇主機間的交互是不同的。
Kerberos 這個名字來源於希臘神話，是冥界守護神獸的名字
其實看到這張圖后，也就能明白Kerberos認證的是由三方來完成的，他們分別是client、server、KDC(Key Distribution Center)。
其中KDC是由兩種服務所構成的，AS(Authentication Service)和TGS(Ticket Granting Service)
AS是用來為client生成TGT的，TGS是用來為client生成某個服務的Ticket的，TGT(Ticket Granting Ticket)是用來獲取Ticket的臨時憑證，Ticket是用來訪問某種服務所必須使用的票據
只有用戶TGT才能獲取Ticket，才能去訪問server上的服務。
而在Windows當中，域控DC(Domain Controller)充當了KDC的角色，還有一點需要注意的是，它有一個類似於本地SAM一樣的數據庫AD(Account Database)，里面存儲着所有client的名單，只有存在於client中的用戶才能申請到TGT。
從物理層面看，AD與KDC均為域控制器DC(Domain Controller)。
** 域認證的大致流程是這樣的：**
** client先向DC請求，要求獲取訪問server的權限，當DC接收到請求之后，先由AS向AD發起請求，查看此client是否在白名單中，成功后，則由AS將TGT返回給client。
** 然后client帶着TGT繼續向DC發起請求，要求獲取訪問server的權限，當DC接收到請求后，TGS會通過TGT判斷此client是否有獲取server服務的權限，成功后，則將Ticket返回給client。
** 然后client憑借Ticket去訪問所請求的server，這個Ticket只對該server有效，如果要訪問其他server，需要重新申請。
結合下面的圖片，分析大致流程效果更佳，文章最后有用通俗的語言解釋過程的。
接下來我們走一遍完整的數據請求流程
先說一下這次實驗中所使用的機器
DC 192.168.5.130
Client 192.168.5.238
計算機名：SECQUAN_WIN7-PC
域用戶：win7
Server 192.168.5.239
計算機名：SECQUAN_WIN7
域用戶：win71
以下的講解中的Kerberos數據包是通過網絡共享服務來抓取的
首先，我們來看第一步的流程
Client發送自己的身份信息給KDC，KDC驗證成功后，會在本地生成一個隨機字符串session key，然后返回給client兩個信息。
** 一個是由client提供的用戶名所對應的NTLM hash對session key進行加密后得到的，那么為什么KDC可以用client用戶的NTLM hash來進行加密呢，在AD中儲存了所有域用戶的賬號密碼等信息，當client發送過身份信息之后，AS會先向AD請求，詢問是否有此用戶，如果有的話，就會取出它的NTLM hash，然后對所生成的session key進行加密然后作為返回數據包中的一個內容。
** 另一個就是KDC中的一個特定用戶的NTLM hash對session key和client所發送的用戶信息進行加密后得到的，其中這個特定用戶就是krbtgt（krbtgt是在創建域控的時候自動生成的，並且由系統給他隨機分配一個密碼）；這個加密數據的內容其實就是后面請求中所使用的TGT。
- 這兩個中間所用到的session key是相同的。
接下來再詳細理一遍每一個請求所傳輸的具體內容
先看一下client發送身份信息的時候，都傳輸了哪些內容
他發送一個KRB_AS_REQ的一個請求，包含了被client加密的timestamp，還有自己的名字等信息，還有請求域時候的服務器信息
我們來看一下他中間所有的數據包
當KDC驗證成功后，給client返回一個KRB_AS_REP的請求，它所包含的詳細內容是這樣的
再從數據包中對應一下
到這里為止，Kerberos請求的第一步過程就結束了，此時已經獲取到了所需要的TGT，接下來就是通過TGT來請求ticket。
** 這里還有一點需要注意的是，返回的兩個內容，第一個client hash，client可以通過自己的NTLM hash解密，得到其中的session key，但是client是沒有KDC的hash，也就是client不知道krbtgt用戶的密碼，是無法得到TGT中的具體內容的，我們可以使用前面得到的session key繼續和TGS進行通信。
接下來我們來看一下第二步的協議流程
首先他會傳輸之前所獲得到的TGT，然后還有前面通過自己的NTLM hash解密出來的session key，來加密client的信息和timestamp，還有client和server的信息，client將這三塊信息一同發送給TGS。
等到TGS接收到前面所傳輸的信息后，因為TGS本身也屬於KDC的一部分，它是擁有krbtgt用戶的NTLM hash的，可以對所傳輸的TGT進行解密，為什么要先解密TGT呢，因為TGS本身是沒有session key的，不能對client中所加密的其他信息進行一個認證，而TGT中是存在session key的，TGS通過解密TGT便可以獲得傳輸中的session key，最后便通過session key來解密client所加密的內容，從中獲取到時間戳timestamp，如果時間戳跟當前時間相差太久的話，認證就需要重新再來，重復第一步中的操作，重新去請求TGT（因為Kerberos在設計的時候，就假設是處於一個不安全的環境中的，是假設它中間存在中間人攻擊的，所以依靠時間戳來限制）。
從中還能獲取到client的信息，TGS還會將這個client的信息與TGT中的client信息進行比較，如果兩個相等的話，還會繼續判斷此client有沒有權限訪問server，如果都沒有問題的話，就認證成功，返回ticket給client。
在這次傳輸的時候，里面是包含有兩個信息的
-
首先它會在本地
再生成一個隨機字符server session key，使用之前的session key將新生成的server session key加密得到第一個字符串，這里的server session key主要用於后面在client與server的認證過程中的。 -
第二個內容就是ticket了，KDC先會通過前面所得到的server的信息，在AD中找到所對應的NTLM hash，然后通過這個NTLM hash去加密ticket，最后一並返回到client。
在給到client以后，client擁有session key的，所以可以解密得到server session key，但是服務端沒有server hash，所以是無法解密得到ticket的。
Ticket中所包含的內容主要有以下幾個
我們再在數據包中看一下所有的流程
先有client發起krb-tgs-req的一個請求
當TGS處理完以后，回復了krb-tgs-rep數據包
到這里為止，與KDC的通信就結束了，接下來是拿着ticket與server進行通信
Client向server發送一個krb-ap-req請求，其中第一塊就是ticket，因為client是不能對其進行解密的。然后第二個內容就是解密出來的server session key，通過解密出來的server session key加密client信息和時間戳，最后一並發送到server。
Server在收到數據包之后，使用自己的hash將ticket解密，從中獲得server session key，然后將krb-ap-req中的client信息和時間戳解密出來，然后與ticket中的client信息進行比對，將這里的時間戳與ticket中的end time進行比較，如果超過了這個時間，就代表ticket已經失效了，需要重新進行認證。
其實在整個Kerberos認證流程中，TGT和ticket的結構都是一樣的，唯一不同的就是TGT中是session key，ticket中是server session key，session key是由AS給client的，server session key是由TGS給client的。
以下是兩個交互的數據包
其實整個Kerberos認證的流程就是不斷交換密鑰，使用對稱加密算法，解密驗證身份和時間戳，最后達到認證的效果。
最后使用比較通俗的話來給大家解釋一下
比如你要去坐飛機，首先你去購買機票，對方（AS）肯定會先驗證你的身份（client info），驗證通過后，把機票（TGT）給你，然后在登機的時候，檢票人員（TGS）會驗證你的機票（TGT），然后告訴你飛機位置（ticket），之后你就可以帶着ticket去相應的位置了。
文章首發公眾號：無心的夢囈(wuxinmengyi)
這是一個記錄紅隊學習、信安筆記，個人成長的公眾號
掃碼關注即可
