kerberos认证_初识 Windows域认证体系 Kerberos认证
關鍵詞:
- Kerberos認證
- 域控制器(Domain Controller,DC)
- 密鑰分發中心(Key Distribution Center,KDC)
- 帳戶數據庫(Account Database,AD)
- 身份驗證服務(Authentication Service,AS)
- 入場卷[認證票據](Ticket Granting Ticket,TGT)
- 票據發放服務(Ticket Granting Service,TGS)
- 票據(Ticket)
- Master Key / Long-term Key |長期密鑰(被 Hash加密的用戶密鑰)
- Session Key / Short-term Key | 短期會話密鑰
- krbtgt 賬戶
關鍵詞/名稱含義:
- Account Database:類似于 SAM的數據庫,存儲所有 Client的白名單,只有處于白名單中的 Client才可以成功申請 TGT
- Authentication Service:為 Client生成 TGT的服務
- Ticket Granting Ticket:入場券,通過入場券能夠獲得票據,是一種臨時憑證的存在
- Ticket Granting Service:為 Client生成某個服務的票據
- Ticket:票據,網絡對象互相訪問的憑證
- Master Key:長期密鑰。將本機密碼進行 Hash運算(NTML)得到一個Hash Code, 我們一般管這樣的 Hash Code叫做 Master Key
- Session Key:短期會話密鑰。一種只在一段時間內有效的 Key
- krbtgt賬戶:每個域控制器都有一個 krbtgt的用戶賬戶,是 KDC的服務賬戶,用來創建票據授予服務(TGS)加密的密鑰
域認證體系 Kerberos認證含義:
Kerberos 是一種網絡認證協議,其設計目標是通過密鑰系統為 客戶機 / 服務器應用程序 提供強大的認證服務。該認證過程的實現不依賴于主機操作系統的認證,無需基于主機地址的信任,不要求網絡上所有主機的物理安全,并假定網絡上傳送的數據包可以被任意地讀取、修改和插入數據。在以上情況下, Kerberos 作為一種可信任的第三方認證服務,是通過傳統的密碼技術(如:共享密鑰)執行認證服務的。——度娘百科
Kerberos認證的三只狗頭(腦補地獄三頭犬):
- Client
- Server
- DC(KDC)。在 Windows域環境中,KDC的角色由 DC(Domain Controller)來擔當
Kerberos大致流程:
- Client 攜帶賬戶信息向 KDC上的 AS服務發送想要訪問 Server A的請求,索要入場卷( TGT);AS通過 AD驗證 Client賬戶的訪問權,成功后返回 TGT
- Client 攜帶 TGT請求 KDC中的 TGS服務想要訪問 Server A,索要票據(Ticket);TGS驗證 Client的 TGT,具有 Server A的訪問權,返回 Ticket
- Client 攜帶 Ticket與服務器進行相互驗證且成功,可以訪問 Server A,但無權訪問其他服務器
認證流程三步走:
一、Client 與 AS
第一步 AS 實現對 Client 身份的確認,并頒發給該 Client 一個 TGT首先,Client發送一個攜帶被自身 Master Key加密的身份信息 AS Request到 KDC,KDC驗證用戶名是否存在于 AD中(KDC 可以通 AD中對應用戶名提取該 Client 的 Master Key)
- Pre-authentication data:被 Client 的 Master Key加密過的 Timestamp(Timestamp防爆破)。時間同步(Time Synchronization)顯得尤為重要
- Client name & realm:Domain nameClient name (Client info)
- Server Name:KDC中 TGS 的 Server Name
AS 需要驗證發送方 Client info 是否為本人(Client的密碼對否),所以 AS 只需從 AD中提取 Client對應的 Master Key 對 Pre-authentication data 進行解密,如果是一個合法的 Timestamp(時間差距合理),則可以證明發送方提供的用戶名是存在于白名單中且密碼對應正確的
驗證成功后,返回給 Client一個 AS Response,主要包含兩個部分:請求 Client 的 Master Key加密過的 TGS Session Key 和被 KDC(krbtgt 帳戶)加密的TGT (客戶端無法解密 TGT,因為它沒有 KDC Hash)
- Session Key : 第一部分的 TGS Session Key (這里的Session Key是被KDC加密,不是 Client)
- Client name & realm : Domain nameClient (Client info)
- End time : TGT到期的時間
KDC此時生成一個 Session Key,使用 Client用戶名對應的 Master Key加密 Session Key,作為 AS數據(第一部分,用于后續與 TGS通訊);使用 KDC中 krbtgt 帳戶 的 Master Key 加密 Session Key 和 Client info,生成TGT(第二部分)
Client 通過自己的 Master Key對第一部分解密獲得 TGS Session Key后,攜帶 TGT進入第二步
第一步二、Client 與 TGS
第二步 實現 TGS 對 Client 身份(TGT)的確認,并分發給該 Client 一個 TicketClient 使用 AS返回的 TGS Session Key 建立訪問 KDC中 TGS服務的請求(TGS Request),再將 TGT 連同請求一起發送到 TGS 服務
- Authenticator:(Client info + timestamp)通過 TGS Session Key加密
- TGT :(TGS Session Key + Client info + End Time)
- Client info :Domain name/ Client
- Server info :Client試圖訪問的 Server
- 時間戳
TGS收到 TGS Request后需要驗證 TGT 和 Authenticator;因為 Authenticator 被 TGS Session Key 加密,TGS服務并沒有保存這個 Session Key ;于是使用 TGS 自己的 Master Key 解密 TGT 獲得其中的 TGS Session Key ,進而解密 Authenticator ,驗證客戶端是否受信
驗證成功后,TGS 返回一個 TGS Response ,包含兩個消息:加密的 Ticket 和加密的 Session Key
- 使用 Server 的 Master Key 進行加密的 Ticket
- 通過 TGS Session Key 加密的 Server Session Key (將來 Client與 Server Service的通信使用)
- Server Session Key
- Client info
- End time: Ticket的到期時間
Client收到 TGS Response后,使用 TGS Session Key 解密 Server Session Key,得到 Session Key后,進入第三步
第二步三、Client 和 Server
第三步,Client 攜帶 Server Session Key 和 Ticket訪問服務器,驗證成功后,可以訪問 Server資源Client 通過第二步獲的 Server 的 Session Key ,創建用于證明自己就是 Ticket 的真正所有者的 Authenticator 和時間戳,并使用 Server的 Session Key 進行加密
向服務器請求后,服務器用自己的 Master Key 解密 Ticket ,得到 Server Session Key,使用 Server Session Key 解密 Authenticator 進行驗證,同上一步一樣
驗證成功后返回給 Client 新時間戳,使用 Server Session Key 加密
Client 通過緩存中的 Server Session Key 解密服務器返回信息,得到新時間戳并驗證其是否正確。驗證通過的話則客戶端可以信賴服務器,并向服務器發送服務請求,服務器向客戶端提供相應的服務
校驗通過后,認證成功,該票據會一直存在客戶端內存中
第三步Ref
- windows 域認證 Kerberos詳解
- 徹底理解Windows認證 - 議題解讀
- kerberos認證原理---講的非常細致,易懂
- Kerberos
總結
以上是生活随笔為你收集整理的kerberos认证_初识 Windows域认证体系 Kerberos认证的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: jvm类加载机制_JVM 类加载机制
- 下一篇: 因为在此系统上禁止运行脚本。有关详细信息