kerberos協議與票據
windows用戶密碼存儲在SAM文件（安全用戶管理）中
當我們登錄系統時，會對我們的密碼進行hash加密后與數據庫中密碼對比、
（SAM文件保留了計算機本地所有用戶的憑證信息）
NTLM（NT Lan Manager）協議
早期SMB協議在網絡上傳輸明文口令。后來出現 LAN Manager Challenge/Response驗證機制，簡稱LM，它是如此簡單以至很容易就被破解。微軟提出了WindowsNT挑戰/響應驗證機制，稱之為NTLM。
是一種基於挑戰、應答的wins早期認證機制，安全性不高，從windows2000開始默認不再使用。
認證流程
winlogon.exe -> 接收用戶輸入 -> lsass.exe -> (認證)
（lsass進程，這個進程中會存一份明文密碼，將明文密碼加密成NTLM Hash，對SAM數據庫比較認證）
認證過程是將我們輸入的密碼轉化成NTML hash 與SAM 文件中的NTML hash對比
windows下兩種hash加密方法
LM hash
一種對稱加密hash
參考：https://www.cnblogs.com/-qing-/p/11343859.html
LM hash的不足：
1.輸入密碼后 大小寫不敏感
2.可以猜測到密碼是否大於七位
3.‘魔術字符串’已知，容易破解
NTML hash
將輸入的密碼進行十六進制編碼后轉化為Unicode，再用MD4加密得到結果
admin -> hex(16進制編碼) = 61646d696e
61646d696e -> Unicode = 610064006d0069006e00
610064006d0069006e00 -> MD4 = 209c6174da490caeb422f3fa5a7ae634
具體過程
1.客戶端向服務端發送用戶信息
2.服務端收到后判斷該用戶是否在本地賬戶列表中，如果沒有認證失敗，如果有隨機產生一個16位隨機數，稱為‘Challenge’，
使用用戶名對應的NTLM hash加密Challenge生成Challenge-1，存放在服務端內存中，然后將Challenge發送給客戶端
3.客戶端收到Challenge后用密碼對應的NTLM hash加密后得到Response（ 表現形式為Net-NTLM hash），將它發送給服務方
4.服務端驗證Response和Challenge-1 相等則驗證成功
kerberos協議
Kerberos 是一種網絡認證協議，其設計目標是通過密鑰系統為 客戶機 / 服務器應用程序 提供強大的認證服務。該認證過程的實現不依賴於主機操作系統的認證，無需基於主機地址的信任，不要求網絡上所有主機的物理安全，並假定網絡上傳送的數據包可以被任意地讀取、修改和插入數據。在以上情況下， Kerberos 作為一種可信任的第三方認證服務，是通過傳統的密碼技術（如：共享密鑰）執行認證服務的
三個實體：Client Server KDC(Authentication Server --AS 和 Ticket-Grant Service --TGS)
AS :用來認證用戶身份
TGS：授權服務訪問
Server：提供服務
Client：請求服務
具體過程
第一步:用戶登錄、請求身份認證
這個階段用戶輸入賬號密碼，在客戶端密碼被一個單向hash函數加密成Client密鑰
用戶向AS發送請求
隨后AS確認存在該用戶，就將數據庫中該用戶對應的密碼也用同樣的單向hash函數加密，得到Client密鑰，，與用戶登錄時生成的相同。
AS發回給Client的內容
1.用Client密鑰加密的Client/TGS SessionKey（client ，TGS間的通訊）
2.用TGS密鑰加密的TGT（用 krbtgt的HTLM hash加密）
（TGT中有：Client/TGS SessionKey、Client ID、Ticket的有效時間、Client的網絡地址）
Client收到后因為有Client密鑰所以可以解密得到Client/TGS SessionKey
第二步：請求服務授權
Client向TGS發送的有
要服務的ID （Service ID） 和 上一步AS給的TGT
還有用Client/TGS SessionKey加密的{Client ID,Timestamp}
然后TGS返回給Client的信息有
MsgF:使用[Client/TGS SessionKey]加密的[Client/Server SessionKey]
MsgE:Client/Server SessionKey（用Service密鑰加密）、Client網絡地址、Ticket有效時間、Client ID
因為Client有Client/TGS SessionKey 可以的到 Client/Server SessionKey
然而 Client/Server SessionKey因為是用Service加密，所以對Client不透明
第三步：發送服務請求、Server響應請求
MsgE:就是上一步的MsgE,
MsgG:用Client/Server SessionKey加密的{Client ID,Timestamp}(用來向ss證明，自己有來自TGS的key)
SS收到客戶端的服務請求之后，先利用自身的[Service密鑰]對Msg E進行解密，提取出Client-To-Server Ticket, 在3.2步驟中，提到了該Ticket中包含了[Client/Server SessionKey]以及Client ID信息。
SS使用[Client/Server SessionKey]解密Msg G，提取Client ID信息，而后將該Client ID與Client-To-Server Ticket中的Client ID進行比對，如果匹配則說明Client擁有正確的[Client/Server SessionKey]。
而后，SS向Client響應Msg H(包含使用[Client/Server SessionKey]加密的Timestamp信息)。
Client收到SS的響應消息Msg H之后，再使用[Client/Server SessionKey]對其解密，提取Timestamp信息，然后確認該信息與Client發送的Authenticator 2中的Timestamp信息一致。
黃金票據（Golden Ticket）
在認證的第一步Client通過AS認證后，AS會給Client發送Client/TGS SessionKey和TGT ，因為Client/TGS SessionKey不會保存在KDC中，而TGT的產生是用krbtgt 的NTLM hash加密（固定）的，所以假如知道了krbtgt的NTML hash就可以偽造TGT，然后這樣有了黃金票據，在Client和TGS交互的時候，只要拿出偽造的TGT，和隨便一個Client/TGS SessionKey生成的{Client ID,Timestamp}就可以跳過AS的驗證，不用驗證賬號和密碼
特點
需要知道krbtgt的NTML hash
不用到AS那去驗證
可以獲取任意服務
白銀票據（Silver Ticket）
在認證的第三步，Client要向Server發送ST 和 Client/Server SessionKey加密的{Client ID,Timestamp} ，然后服務端用自己的Key（Server的NTML hash）解密得到 Client/Server SessionKey，然后用Client/Server SessionKey解密得到{Client ID,Timestamp} 。
如果Client知道了Server的NTML hash就可以偽造出一個ST ，而 Client/Server SessionKey在server收到之前是不知道的，也可以偽造，從而繞過了KDC，直接獲取服務。
特點
需要知道server的NTML hash
不需要和KDC驗證
只能得到特定的服務