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）

AS Request大致内容：

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）

TGT大致内容：

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 一个 Ticket

Client 使用 AS返回的 TGS Session Key 建立访问 KDC中 TGS服务的请求（TGS Request），再将 TGT 连同请求一起发送到 TGS 服务

TGS Request大致内容：

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

TGS Response 大致内容：

使用 Server 的 Master Key 进行加密的 Ticket
通过 TGS Session Key 加密的 Server Session Key （将来 Client与 Server Service的通信使用）

Ticket 大致内容：

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