Windows有兩種認證協議：NTLM（NT LAN Manager）和Kerberos。
域成員計算機在登錄的時候可以選擇登錄到域中或此臺電腦，選擇登錄到域一般會採用Kerberos協議在域控DC上進行認證。
NTLM認證協議
NTLM是一種網絡認證協議，它是基於挑戰（Chalenge）/響應（Response）認證機制的一種認證模式。
這個協議只支持Windows，NTLM認證協議大概流程：
可以看到NTLM協議基於NTLM hash，Windows本地登錄的密碼由LM hash和NTLM hash組成,存儲在SAM文件中,前一部分是LM Hash，後一部分是NTLM Hash。
administrator:500:6f08d7b306b1dad4ff17365faf1ffe89:032f3db689bf1ee44c04d08c785710de:::
在登錄Windows的時候，系統會將用戶輸入的密碼轉換成NTLM hash並與SAM文件中的密碼進行對比，如果相同，則認證成功。
Kerberos認證協議
Kerberos是一種網絡認證協議，整個認證過程涉及到三方：客戶端、服務端和 KDC（Key Distribution Center），在 Windows 域環境中，KDC 的角色由 DC（Domain Controller）來擔當。
Kerberos基於票據(Ticket)進行安全認證，票據是用來在認證服務器和用戶請求的服務之間傳遞用戶身份的憑證。
以下是kerberos協議的認證流程：
-
KRB_AS_REQ：Client-A發送Authenticator（通過A密碼加密的一個時間戳TimeStamp）向KDC的AS服務認證自己的身份；
-
KRB_AS_REP：AS通過KDC數據庫中存儲的Client-A密碼的副本，解密收到的Authenticator，如果解密出的TimeStamp符合要求，則AS服務認爲Client-A就是所謂的Client-A；認證成功後，AS服務生成一個短期有效的SessionKeya-kdc，將該Key使用A的密碼副本加密成密文1，另外將Key連同時間戳標誌（控制該SessionKey的有效時間）通過TGS服務的密碼也就是KDC的密碼加密爲密文2（稱爲TGT），將這兩個密文組合成KRB_AS_REP返回給Client-A；
-
KRB_TGS_REQ：Client-A在接收到KRB_AS_REP後，首先使用自身密碼解密密文1得到SessionKeya-kdc，此時需要注意的是，密文2（TGT）是被KDC的密碼加密的，所以Client-A無法解密，這也是Kerberos協議設計的精妙之處，既解決了Server端（TGS相對於Client-A也稱之爲Server端）無法及時接收SessionKey的問題，又不怕Client-A對該TGT的僞造，因爲Client-A不知道Server端的密碼。得到SessionKeya-kdc後，Client-A利用其加密時間戳生成Authenticator用於向TGS申請Client-A與Client-B進行認證所需的SessionKeya-b，連同剛纔KRB_AS_REP接收的TGT一同組合成KRB_TGS_REQ發送給TGS
-
KRB_TGS_REP：TGS在接收到KRB_TGS_REP之後，利用KDC密碼解密TGT獲得本來就該發送給自己的SessionKeya-kdc，然後用其解密KRB_TGS_REQ中的Authenticator得到Client-A發送過來的時間戳，如果時間戳符合要求，則生成一個短期有效的SessionKeya-b，注意此時利用SessionKeya-kdc將SessionKeya-b加密爲密文1，然後利用Server-B的密碼將SessionKeya-b加密爲密文2（稱爲ServiceTicket），兩個密文一同構成KRB_TGS_REP返回給Client-A；
-
KRB_AP_REQ：Client-A在接收到KRB_TGS_REP之後，首先使用緩存的SessionKeya-kdc將密文1中的SessionKeya-b解密出來，然後利用其加密時間戳生成Authenticator用於向B進行對自身的驗證，另外，和剛纔TGT一樣，密文2也就是ServiceTicket是用Server-B的密碼加密的，所以Client-A無法解密，也就無法僞造，這也同樣解決了在三方認證中作爲Server端的B無法及時接收SessionKey的問題，又不怕Client-A對ServiceTicket的僞造；
-
KRB_AP_REP：Server-B受到KRB_AP_REQ之後，利用自身密碼解密ServiceTicket，得到SessionKeya-b，然後用SessionKeya-b解密Authenticator得到時間戳，驗證A的身份。