Windows認證 | 域認證

在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去相應的位置了。

本文由博客一文多發平臺 OpenWrite 發佈！