過去一般用於工作組環境中，也就是個人pc機，不過域內也會使用，而且與kerberos認證共存。
域內的流程：
客戶端向要訪問的機器傳送使用者名稱，這個被訪問的機器稱為服務端。
服務端向客戶端傳送乙個challenge。
客戶收到challenge後用自己的 ntml hash對其進行加密生成response ， 並將response傳送給服務端
服務端將response、challenge、客戶端的使用者名稱一起傳送給域控。
域控將使用者名稱對應的hash用challenge進行加密後與response進行對比，如果一樣那麼認真成功。
工作組環境下登陸時候的ntlm認證：
作業系統會將使用者輸入的密碼轉換成hash然後與sam檔案對應使用者的hash做比較，如果一致則認證成功。
如果cat 要訪問tom這個server，就會經歷以下的認證步驟。
1.客戶端向kdc的as傳送authenticator說自己是cat，authenticator它的內容是乙個被client的master key加密過的timestamp，還會明文傳送client name & realm: 簡單地說就是domain name\client例如test\zhangsan。還會傳送server name這個引數，此時的server name 是tgs的名字,還有其他的例如ip與加密方式等。因為客戶端下一步要訪問tgs來得到ticket。
傳送內容：
1.authenticator（master key加密的時間戳）2.as 收到 資料後用cat的master 解密authenticator，並對結果進行分析，若驗證成功，則as用cat的master加密一段隨機生成的challenge來生成第乙個值，這個challenge就是session key(c - kdc)。再生成乙個用krbtgt的hash加密的tgt，這個tgt裡面有cat的使用者資訊，時間戳，還有用與客戶端與kdc交流的session key也就是之前生成的那個challenge。2.client info（id與ip）
3.servername 這裡是tgs的名字
4.tgt的壽命
傳送內容：
1.tgt：client的名字，client的ip，tgs的名字，時間戳，tgt的到期時間， session key（kdc-client）3.客戶端收到這兩段資訊，用自己的master key解密得到session key。再用session key加密自己的資訊與時間戳得到authenticator。將authenticator與想要訪問的伺服器名與tgt這三個資料傳送給tgs。2.被client的master key加密的session key（kdc-client）tgs的名字，時間戳，到期時間
傳送內容：
1.authenticator。被session key（kdc-client）加密的時間戳還有client的名字2.tgt。同上
3.servername 這裡是真正要訪問的服務的名字
4.ticket的壽命
1.ticket：client的名字，client的ip，到期時間，session key（client-server），server的名字也就是tom，時間戳。前面這些是被server的master key 加密的。2.被session key（kdc-client）加密的session key（client-server），時間戳，到期時間，server的名字
**票據的原理就是，用krbtgt的hash來偽造tgt的內容。更改裡面的client引數與session key等。讓tgs以為我就是那個我所聲稱的人，當然我一般會聲稱自己是administrator。第四步主要是來驗證客戶端的身份。5.客戶端得到乙個ticket與乙個被（客戶端-kdc）session key加密的資料。先用session key（c-kdc）解密資料得到session key（s-c）。用這個session key（s-c）加密自己的client info 與時間戳生成authenticator。將authenticator與ticket 發給要訪問的伺服器。
傳送內容：
1.authenticator。被session key（c-s）加密的時間戳與client info###**票據就是偽造ticket。偽造tgs ticket的核心點是能夠得到目標伺服器的ntlm hash。2.ticket
###spn攻擊就是找到那個「主人」是krbtgt的伺服器。這樣子就可以請求到用krbtgt的hash加密的ticket了。這個ticket加密的內容是 client info 跟乙個session key還有timestamp。這時候可以用暴力破解技術來破解這個ticket。知道破解結果中有client info的相關資訊，即可算作破解成功。進而得到krbtgt的密碼，可以做**票據拿下整個域環境。
6.伺服器用自己的master key 解密ticket 得到session key與client info 等。再用session key 解密authenticator。對比資訊，決定驗證是否成功。成功後則會返回一條用session key（s-c）加密的包含client info與時間戳到資訊。
tgt跟ticket的內容基本是一樣的。只是加密途徑不一樣。乙個是用krbtgt的hash加密，乙個是用sever的hash加密。pac認證是在kerberos認證的第二步認證成功的時候就會將pac夾在返回的tgt中給客戶端。之後會存在tgs返回給client 的ticket中最終傳送給server。裡面內容都是client 的info 跟時間戳還是session key，只不過乙個session key是客戶端與kdc之間的，乙個是客戶端與服務端之間的。
當使用者與kdc之間完成了認證過程之後， client需要訪問server所提供的某項服務時， server為了判斷使用者是否具有合法的許可權需要將client的user sid等資訊傳遞給kdc， kdc通過sid判斷使用者的使用者組資訊， 使用者許可權等， 進而將結果返回給server， server再將此資訊與使用者所索取的資源的acl進行比較， 最後決定是否給使用者提供相應的服務。
pac會在krb_as_rep階段中被as放在tgt裡加密傳送給client，然後由client**給tgs，讓其驗證自己的pac是否被更改。
在pac中包含有兩個數字簽名pac_server_checksum和pac_privsvr_checksum，這兩個數字簽名分別由server端密碼hash和kdc的密碼hash加密。
同時tgs解密之後驗證簽名是否正確，然後再重新構造新的pac放在ticket裡返回給客戶端，客戶端將ticket傳送給服務端進行驗證。
附錄：第一組資訊ticket的詳細內容：（被server的master key 加密）
你的姓名/id
http 服務名/id
你的網路位址(如果是多個主機，則是乙個ip列表．如果是任意一台機器，那麼就是null)
時間戳ticket的壽命
第二組資訊：被 session key（kdc-c）加密http服務名/id
時間戳ticket的壽命
第一組資訊tgt的內容：被krbtgt的master key 加密你的名字/id 也就是client的名字
tgs的名字/id
時間戳你的網路位址 (如果是多個主機，則是乙個ip列表．如果是任意一台機器，那麼就是null)
tgt的壽命
tgs session key 用與c與kdc的通訊
第二組資訊：被client的master key 加密tgs的名字/id
時間戳壽命
tgs session key
Windows身份認證 NTLM認證
步驟一 使用者通過輸入windows帳號和密碼登入客戶端主機。在登入之前，客戶端會快取輸入密碼的雜湊值，原始密碼會被丟棄 原始密碼在任何情況下都不能被快取 這是一條基本的安全準則 成功登入客戶端windows的使用者如果試圖訪問伺服器資源，需要向對方傳送乙個請求。該請求中包含乙個以明文表示的使用者名...
Kerberos認證協議
序言 近幾天學習了kerberos認證協議，覺得有必要把學習過程和學習心得記錄一下，文章內容有william stallings編著的 網路安全基礎 中的部分內容，也有自己的理解和思考。我希望能用自己的理解來解發布kerberos認證協議的工作過程。由於kerberos比較複雜，所以需要通過多個假設...
Kerberos認證協議
一 簡介 kerberos由mit於1988年開發，用於分布式環境中，完成伺服器與使用者之間的相互認證。設計者的設計初衷是要用kerberos的三個頭來守衛網路之門。三個頭分別包括 認證 賬目清算和審計。kerberos要解決的問題 在乙個開放的分布式網路環境中，使用者通過工作站訪問伺服器提供的服務...