Kerberos認證基礎是怎樣的呢

這期內容當中小編將會給大家帶來有關Kerberos認證基礎是怎樣的呢，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

在古希臘神話中Kerberos指的是：一只三頭犬守護在地獄之門外,禁止任何人類闖入地獄之中。而現實中的Kerberos是一種網絡認證協議，其設計目標是通過密鑰系統為客戶機 / 服務器應用程序提供強大的認證服務,域環境中默認優先使用Kerberos進行認證。

下面請看Kerberos 協議框架：

通過上圖可以看到整個認證流程有三個重要的角色,分別為Client、Server和KDC。下面介紹下幾個相關的名詞：

1、訪問服務的 Client。

2、提供服務的 Server。

3、KDC（Key Distribution Center）：密鑰分發中心。

在KDC中又分為兩個部分：Authentication Service(AS,身份驗證服務)和Ticket Granting Service(TGS,票據授權服務)。

4、DC（Domain Controller）：即域控制器；AD（Active Directory）：即活動目錄。

DC中有一個特殊用戶叫做:krbtgt，它是一個無法登錄的賬戶，是在創建域時系統自動創建的，在整個kerberos認證中會多次用到它的Hash值去做驗證。

AD會維護一個Account Database(賬戶數據庫). 它存儲了域中所有用戶的密碼Hash和白名單。只有賬戶密碼都在白名單中的Client才能申請到TGT。

舉個簡單的栗子：如果把Kerberos中的票據一類比作一張門禁卡，那么Client端就是住客，Server端就是房間，而KDC就是小區的門禁。住客想要進入小區，就需要手里的門禁卡與門禁相對應，只有通過門禁的驗證，才能打開門禁進入小區，整個過程就相當于一個縮減版的Kerberos認證。

Kerberos 詳細認證流程：

當 Client 想要訪問 Server 上的某個服務時，需要先向 AS 證明自己的身份,驗證通過后AS會發放的一個TGT,隨后Client再次向TGS證明自己的身份,驗證通過后TGS會發放一個ST,最后Client向 Server 發起認證請求，這個過程分為三塊： 

※ Client 與 AS 的交互

※ Client 與 TGS 的交互

※ Client 與 Server 的交互

壹 Client 與 AS 的交互

一、準備：

用戶在Client中輸入賬號密碼后,Client會對密碼進行哈希加密,我們叫做Master key。

1、請求：Client 先向 KDC 的 AS 發送 Authenticator(認證者),我們叫它Authenticator1,為了確保Authenticator1僅限于自己和KDC知道,Client使用自己的Master Key對其的主體部分進行加密。

其內容為：

1)、經過 ClientMaster Key(用戶的NTLM Hash)加密的TimeStamp(一個當前時間的時間戳)。

2)、Client的一些信息(info),比如用戶名。

二、響應：

1、AS接收到Authenticator1后,會根據Client提交的用戶名在AD中尋找是否在白名單中,然后查詢到該用戶名的密碼,并提取到Client對應的Master key,對TimeStamp進行解密,如果是一個合法的Timestamp,就證明了Client提供的用戶名和密碼是存在AD中的,并且AS提取到的Timestamp不能超過5分鐘,否則AS就會直接拒絕Client的請求。

2、TimeStamp驗證通過后,AS會給Client發送一個由Client的Master key加密過的Logon Session Key和一個TGT(client-server-ticket)。TGT的內容：經過KDC中的Master Key(krbtgt NTLM Hash)加密的 Logon Session Key(臨時會話密鑰) 和 TimeStamp、TGS會話密鑰、用戶信息、TGT到期時間。

當Client通過AS的驗證,并順利拿到TGT就完成了Kerberos的第一步認證。

這里需要理解Logon Session Key：

1、Logon Session Key是什么：

即臨時會話秘鑰a,Client向KDC發起對TGT的申請說自己要去訪問Server上的摸個服務,KDC在收到該請求后,會生成一個用于該Client和KDC進行安全通信的Session Key（SKDC-Client,也被稱為Logon Session Key)。這里KDC不會保存SKDC-Client。

需要注意的是SKDC-Client是一個臨時會話秘鑰,所以它具有自己的生命周期,同時TGT和Session相互關聯,當Logon Session Key過期,TGT也就失效了。

2、到了第二步還有一個Session Key(臨時會話秘鑰b),是用于Client和Server之間通信的Session Key（SServer-Client）,這里Server也不會保存SServer-Client。

貳 Client 與 TGS 的交互

Client使用TGT從KDC獲得基于某個Server的Ticket：

一、請求：

Client通過自己的Master key對第一部分解密獲得Logon Session Key之后,攜帶著TGT對TGT發送請求。Client是解不開TGT的,它作為一個Client通過身份驗證的票提交給TGS。

請求的內容：

1、TGT：Client通過與AS交互獲得的TGT,TGT 被 KDC 的 Master Key 進行加密。

2、Authenticator2：Client端使用 Logon Session Key對其進行加密,Authenticator2實際上就是關于Client的一些信息和當前時間的一個Timestamp,用以證明當初 TGT 的擁有者是否就是自己。

二、響應--TGS驗證通過后發放ST(Service Ticket)票：

TGS收到Client請求,驗證其真身份：

TGS 在發給Client真正的Ticket之前,會檢查自身是否存在 Client 所請求的服務,如果服務存在,還得確定Client提供的那個TGT是否是AS頒發給它的,于是它得通過 Client 提供的 Authenticator2 來證明。但是 Authentication2 是通過 Client的 Logon Session Key 進行加密的,而TGS并沒有保存這個 Logon Session Key 。所以 TGS 先得通過自己的 Master Key(krbtgt的密碼hash處理) 對 Client 提供的 TGT 進行解密,從而獲得Client Info和 Logon Session Key（SKDC-Client）,再通過這個Logon Session Key解密 Authenticator2，獲得Client Info,對兩個Client Info進行比較進而驗證對方的真身份

響應內容：

認證通過后TGS會生成一個經過Logon Session Key（SKDC-Client）加密的用于Client和Server之間通信的Session Key（SServer-Client）,和經過KDC的Master Key加密的ST(Service Ticket)

1、經過 Logon session key加密的Client和Server之間的Session Key

2、經過Server的Master Key進行加密的ST(Service Ticket)。Ticket大體包含以下一些內容：Session Key（SServer-Client）Domain name\Client。Ticket的到期時間。

Client 收到TGS的響應,使用 Logon session key,解密第一部分后獲得 Session Key （注意區分 Logon Session Key 與 Session Key 分別是什么步驟獲得的,及其的區別）。有了 Session Key 和 ST(Service Ticket), Client 就可以直接和 Server 進行交互,而無須在通過 KDC 作中間人了。

叁 Client 與 Server 的交互與雙向驗證： 

Server驗證Client：Client通過與TGS交互獲得訪問Server的Session Key,然后為了證明自己就是ST(Service Ticket)的真正所有者,會將Authenticator和時間戳提取出來,并使用Session Key進行加密。最后將這個被加密過的Authenticator3 和ST作為請求數據包發送給Server。此外還包含一個Flag用于表示Client是否需要進行雙向驗證。

Server接收到Request之后,首先通過自己的Master Key(krbtgt的NTLM Hash處理)解密ST,從而獲得Session Key。然后通過解密出來的Session Key再去解密Authenticator3 ,進而驗證對方的身份。如果驗證成功,就讓 Client 訪問對應的資源,否則就會直接拒絕對方的請求。

到目前為止，服務端已經完成了對客戶端的驗證，但是，整個認證過程還沒有結束。接下來就是Client對Server進行驗證以確保Client所訪問的不是一個釣魚服務。

Server需要將Authenticator3中解密出來的Timestamp再次用Session Key進行加密,并發送給Client。Client再用緩存Session Key進行解密,如果Timestamp和之前的內容完全一樣,則可以證明此時的Server是它想訪問的Server。

到這里就完成了整個Kerberos認證

上述就是小編為大家分享的Kerberos認證基礎是怎樣的呢了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。