Kerberos認證過程

1、Kerberos認證簡介

Windows認證協議有兩種NTLM（NT LAN Manager）和Kerberos， 前者主要應用於用於Windows NT 和 Windows 2000 Server（or Later） 工做組環境，然後者則主要應用於Windows 2000 Server（or Later） 域（Domain）環境。Kerberos較之NTLM更高效、更安全，同時認證過程也相對複雜。Kerberos這個名字來源於希臘神話，是冥界守護神 獸的名字。Kerberos是一個三頭怪獸，之因此用它來命名一種徹底認證協議，是由於整個認證過程涉及到三方：客戶端、服務端和KDC（Key Distribution Center）。在Windows域環境中，KDC的角色由DC（Domain Controller）來擔當。

某個用戶採用某個域賬號登陸到某臺主機，並遠程訪問處於相同域中另外一臺主機時，如何對訪問者和被訪問者進行身份驗證（這是一種雙向的驗證）？這就是Kerberos須要解決的場景。接下來我儘可能以比較直白的語言來介紹我所知道的Kerberos認證的整個流程。

Kerberos其實是一種基於票據（Ticket）的認證方式。客戶端要訪問服務器的資源，須要首先購買服務端承認的票據。也就是說，客戶端在訪問服務器以前須要預先買好票，等待服務驗票以後才能入場。在這以前，客戶端須要先買票，可是這張票不能直接購買，須要一張認購權證。客戶端在買票以前須要預先得到一張認購權證。這張認購權證和進入服務器的入場券均有KDC發售。右圖（點擊看大圖）一張圖基本揭示了Kerberos整個認證的過程。

2、如何得到「認購權證」？

首先，咱們來看看客戶端如何得到「認購權證」。這裏的認購權證有個專有的名稱——TGT（Ticket Granting Ticket），而TGT的是KDC一個重要的服務——認證服務（KAS：Kerberos Authentication Service）。當某個用戶經過輸入域賬號和密碼試圖登陸某臺主機的時候，本機的Kerberos服務會向KDC的認證服務發送一個認證請求。該請求主要包括兩部份內容，明文形式的用戶名和通過加密的用於證實訪問者身份的Authenticator（我實在找不到一個比較貼切的中文翻譯沒，Authenticator在這裏能夠理解爲僅限於驗證雙反預先知曉的內容，至關於聯絡暗號）。

當KDC接收到請求以後，經過AD獲取該用戶的信息。經過獲取的密碼信息生成一個祕鑰對Authenticator進行解密。若是解密後的內容和已知的內容一致，則證實請求着提供的密碼正確，即肯定了登陸者的真實身份。

KAS成功認證對方的身份以後，會先生成一個用於確保該用戶和KDC之間通訊安全的會話祕鑰——Logon Session Key，並採用該用戶密碼派生的祕鑰進行加密。KAS接着爲該用戶建立「認購權證」——TGT。TGT主要包含兩方面的內容：用戶相關信息和Logon Session Key，而整個TGT則經過KDC本身的密鑰進行加密。最終，被不一樣密鑰加密的Logon Session Key和TGT返回給客戶端。（以上的內容對應流程圖中的步驟一、2）

3、如何經過「認購權證」購買「入場券」？

通過上面的步驟，客戶端獲取了購買進入同域中其餘主機入場券的「認購憑證」——TGT，以及Logon Session Key，它會在本地緩存此TGT和Logon Session Key。若是如今它須要訪問某臺服務器的資源，它就須要憑藉這張TGT向KDC購買相應的入場券。這裏的入場券也有一個專有的名稱——服務票據（ST：Service Ticket）。

具體來講，ST是經過KDC的另外一個服務TGS（Ticket Granting Service）出售的。客戶端先向TGS發送一個ST購買請求，該請求主要包含以下的內容：客戶端用戶名；經過Logon Session Key加密的Authenticator；TGT和訪問的服務器（實際上是服務）名。

TGS接收到請求以後，現經過本身的密鑰解密TGT並獲取Logon Session Key，而後經過Logon Session Key解密Authenticator，進而驗證了對方的真實身份。

TGS 存在的一個根本的目有兩點：其一是避免讓用戶的密碼客戶端和KDC之間頻繁傳輸而被竊取。其二是由於密碼屬於Long Term Key（咱們通常不會頻繁的更新本身的密碼），讓它做爲加密密鑰的安全係數確定小於一個頻繁變換得密鑰（Short Term Key）。而這個Short Term Key就是Logon Session Key，它確保了客戶端和KDC之間的通訊安全。

TGS完成對客戶端的認證以後，會生成一個用於確保客戶端-服務器之間通訊安全的會話祕鑰——Service Session Key，該會話祕鑰經過Logon Session Key進行加密。而後出售給客戶端須要的入場券——ST。ST主要包含兩方面的內容：客戶端用戶信息和Service Session Key，整個ST經過服務器密碼派生的祕鑰進行加密。最終兩個被加密的Service Session Key和ST回覆給客戶端。（以上的內容對應流程圖中的步驟三、4）

4、憑票入場

客戶端接收到TGS回覆後，經過緩存的Logon Session Key解密獲取Service Session Key。同時它也獲得了進入服務器的入場券——ST。那麼它在進行服務訪問的時候就能夠藉助這張ST憑票入場了。該Serivce Session Key和ST會被客戶端緩存。

可是，服務端在接收到ST以後，如何確保它是經過TGS購買，而不是本身僞造的呢？這很好辦，不要忘了ST是經過本身密碼派生的祕鑰進行加密的。具體的操做過程是這樣的，除了ST以外，服務請求還附加一份經過Service Session Key加密的Authenticator。服務器在接收到請求以後，先經過本身密碼派生的祕鑰解密ST，並從中提取Service Session Key。而後經過提取出來的Service Session Key解密Authenticator，進而驗證了客戶端的真實身份。

實際上，到目前爲止，服務端已經完成了對客戶端的驗證，可是，整個認證過程尚未結束。談到認證，不少人都認爲只是服務器對客戶端的認證，實際上在大部分場合，咱們須要的是雙向驗證（Mutual Authentication）——訪問者和被訪問者互相驗證對方的身份。如今服務器已經能夠確保客戶端是它所聲稱的那麼用戶，客戶端尚未確認它所訪問的不是一個釣魚服務呢。

爲了解決客戶端對服務器的驗證，服務要須要將解密後的Authenticator再 次用Service Session Key進行加密，併發揮給客戶端。客戶端再用緩存的Service Session Key進行解密，若是和以前的內容徹底同樣，則能夠證實本身正在訪問的服務器和本身擁有相同的Service Session Key，而這個會話祕鑰不爲外人知曉（以上的內容對應流程圖中的步驟五、6）