Windows安全認證是如何進行的？[Kerberos篇]

最近一段時間都在折騰安全（Security）方面的東西，比如Windows認證、非對稱式加密、數位憑證、數位簽章、TLS/SSL、WS-Security等。如果時間允許，我很樂意寫一系列的文章與廣大網友分享、交流。對於很多讀者來說，今天討論的可能是一個既熟悉、又陌生的話題——Windows認證。

目錄
一、Kerberos認證簡介
二、如何獲得“認購權證”？
三、如何通過“認購權證”購買“入場券”？
四、憑票入場

一、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整個認證的過程。

二、如何獲得“認購權證”？

首先，我們來看看用戶端如何獲得“認購權證”。這裡的認購權證有個專有的名稱——TGT（Ticket Granting Ticket），而TGT的是KDC一個重要的服務——認證服務（KAS：Kerberos Authentication Service）。當某個使用者通過輸入欄位帳號和密碼試圖登入某台主機的時候，原生Kerberos服務會向KDC的認證服務發送一個認證請求。該請求主要包括兩部分內容，明文形式的使用者名稱和經過加密的用於證明訪問者身份的Authenticator（我實在找不到一個比較貼切的中文翻譯沒，Authenticator在這裡可以理解為僅限於驗證雙反預Crowdsourced Security Testing曉的內容，相當於聯絡暗號）。

當KDC接收到請求之後，通過AD擷取該使用者的資訊。通過擷取的密碼資訊產生一個秘鑰對Authenticator進行解密。如果解密後的內容和已知的內容一致，則證明請求著提供的密碼正確，即確定了登入者的真實身份。

KAS成功認證對方的身份之後，會先產生一個用於確保該使用者和KDC之間通訊安全的會話秘鑰——Logon Session Key，並採用該使用者密碼派生的秘鑰進行加密。KAS接著為該使用者建立“認購權證”——TGT。TGT主要包含兩方面的內容：使用者相關資訊和Logon Session Key，而整個TGT則通過KDC自己的密鑰進行加密。最終，被不同祕密金鑰加密的Logon Session Key和TGT返回給用戶端。（以上的內容對應流程圖中的步驟1、2）

三、如何通過“認購權證”購買“入場券”？

經過上面的步驟，用戶端擷取了購買進入同域中其他主機入場券的“認購憑證”——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回複給用戶端。（以上的內容對應流程圖中的步驟3、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，而這個會話秘鑰不為外人知曉（以上的內容對應流程圖中的步驟5、6）

以上的內容僅僅講述的是基於Kerberos的Windows認證的大體流程，並不涉及到一些細節的東西，比如如何確保時間的同步，如何抵禦Replay Attack等。此外，由於本文對Windows底層的知識有限，不能確保所有的內容都是完全正確，如有錯誤，還往不吝指正。

Windows安全認證是如何進行的？[Kerberos篇]
Windows安全認證是如何進行的？[NTLM篇]