Kerberos域认证简述

Kerberos是一种认证机制。目的是通过密钥系统为客户端/服务器应用程序提供强大的可信任的第三方认证服务：保护服务器防止错误的用户使用，同时保护它的用户使用正确的服务器，即支持双向验证。kerberos最初由MIT麻省理工开发，微软从Windows 2000开始支持Kerberos认证机制，将kerberos作为域环境下的主要身份认证机制，理解kerberos认证协议是域渗透的基础。

1.1：Kerberos认证框架

• kerberos机制中主要包含三个角色：Client、Server、KDC(Key Distribution Center)密钥分发中心。
• Client代表用户，用户有自己的密码，Server上运行的服务也有自己的密码，KDC是受信任的三方认证中心，它拥有用户和服务的密码信息。

• KDC服务默认会安装在域控中，Client想要访问Server的服务（xxx service），前提是通过KDC认证，再由KDC发放的票据决定Client是否有权限访问Server的服务。
• KDC 服务框架中包含一个 KRBTGT 账户，它是在创建域时系统自动创建的一个账号，你可以暂时理解为他就是一个无法登陆的账号，在发放票据时会使用到它的密码 HASH 值。

1.2：名词解析

1. KDC(Key Distribution center)：密钥分发中心，在域环境中，KDC服务默认会安装在域控中。
2. AS(Authentication Service)：认证服务，验证client的credential(身份认证信息)，发放TGT。

1. TGT(Ticket Granting ticket)：票据授权票据，由KDC的AS发放，客户端获取到该票据后，以后申请其他应用的服务票据(ST)时，就不需要向KDC的AS提交身份认证信息(credential)，TGT具有一定的有效期。由 KBRTGT HASH 加密的 sessionkey-as 和 Timestamp 等信息。TGT=KBRTGT HASH（）
2. TGS(Ticket Granting Service)：票据授权服务，验证TGT，发放ST。

1. ST(Service Ticket)：服务票据，由KDC的TGS发放，是客户端应用程序访问Server某个服务的凭证，Server端验证通过则完成Client与Server端信任关系的建立。
2. Session key:用来加密client和TGS之间传输的数据。

1. Server session key:用来加密client和server之间传输的数据。

1.3：简单认证流程

首先Client想要访问Server的某个服务，就需要通过KDC的认证，获取到服务票据（ST），服务会验证服务票据（ST）来判断Client是否通过了KDC认证。为了避免Client每次访问Server的服务都要向KDC认证(输入密码)，KDC设计时分成了两个部分，一个是AS，另一个是TGS;AS接收Client的认证信息，认证通过后给Client发放一个可重复使用的票据TGT，后续Client使用这个TGT向TGS请求ST即可。

二：Kerberos认证流程

The Authentication Service Exchange（认证服务器）-->	Client 与 AS 的交互AS_REQ•AS_REP
Ticket-Granting Service (TGS) Exchange（票据授予服务器）-->	Client 与 TGS 的交互 TGS_REQ•TGS_REP
The Client/Server Authentication Exchange（pc和要访问的服务）-->	Client 与 Server 的交互 AP_REQ•AP_REP

2.1：第一步：Client与AS交互

用户登录阶段，通常由用户(admin)输入[用户名][密码]信息，在客户端侧，用户输入的密码信息被一个单向 Hash 函数生成 Client 密钥，即 admin 的 NTLM Hash：

• Pre-authentication data:就是用client对应的master key加密了一个timestamp。
• Client info:client用户信息

• Server info:这里并不是Client真正要访问的Server的名称，实际上是KDC的Ticket Granting Service的Server Name。

AS_REQ（请求）：

KDC端收到该请求后，Authentication service用client info部分信息，在AD（account database）中查询该client name对应的master key，并对pre-authentication data数据进行解密，如果可以提取出一个合法的时间戳，那就说明该用户是合法的，验证通过，并回复KRB_AS_REP给client。

AS_REP（返回）：

AS 收到用户认证请求后，AS 根据请求中的 用户名 AA 信息，从数据库中查找用户名是否存在。如果 用户名 AA 存在，则从 KDC 中可以获取 用户 AA 的密码，使用单向函数为该密码生成一个 Client 密钥（即NTLM Hash）。AS 生成随机字符串 Client/TGS Session Key，使用 Client 密钥(用户 AA 的密码 NTLM Hash)对 Client/TGS Session Key 加密得到 sessionkey_as； //Sessionkey_as = 用户密码NTLM HASH(Client/TGS Session Keys)

再使用 TGS 密钥(krbtgt 用户的 NTLM Hash)对 Client/TGS Session Key 、 Client Info 和 Timestamp 加密,得到 TGT（TGT票据）。

//TGT = KRBTGT用户NTLM Hash(Client/TGS Session_key,Client info,Timestamp)

将 sessionkey_as 和 TGT 一起返回给 Client。

Client 收到 AS 的响应消息后，利用自身的 Client 密钥（AA 的 NTLM Hash）对sessionkey_as 解密，这样就获取到 Client/TGS Session Key。

另一个版本：

在 KDC 中存储了域中所有用户的密码 hash，当 AS 接受到 Client 的请求后会根据 AD 中存储的密码来解密，解密成功并且验证信息。验证成功后返回给 Client 由 Client 密码 hash 加密的 sessionkey-as 和 TGT

总体来说，KRB_AS_REP分为两部分：

1. 用client master key对session key进行加密后的值。Session key是KDC随机生成的UUID，用于client和TGS服务之间的数据加密、认证。
2. 用KDC master key值对Client/TGS Session Key进行加密。这部分client解不了。由此处也可以看出，TGT包括三个部分，分别是session key、client name、end time。（当响应信息里面有KDC Hash，即可伪造黄金票据） //Master Key = NTLM Hash

2.2：第二步：Client与TGS交互

当client端接收到AS_REP时，client使用client master key对KRB_AS_REP的第一部分信息进行解密，得到session key，并再次拼装出TGS_REQ请求体，向KDC的TGS发出请求

请求结构如下，TGS_REQ请求体包括：client/TGS Session key(client info+时间戳)、TGT、client info、server info；

其中，server info就是该client真正要访问的server，步骤一AS_REQ中的不一样

TGS-REQ（请求）：

当TGS服务收到到client请求体KRB_TGS_REQ时，因为TGS端并没有session key，只能先利用KDC的master key去解TGT部分内容，得到session key，再去解Session key(client info+时间戳)部分，从而验证该用户是否是AS颁发给该client的。验证通过后，给client回复KRB_TGS_REP给client

TGS-REP（返回）：

TGS 收到请求后，检查 KDC 数据库中是否存在所请求的服务(Service ID)。如果存在，TGS 使用 KDC密钥(krbtgt 的 NTLM Hash)解密 TGT，得到 Client/TGS Session Key、timestamp、Client info；同时使用从 TGT 中解密得到的 Client/TGS Session Key去解密 Authenticator2，得到 Client info 和 timestamp。比对 Authenticator2 和TGT 的解密内容以验证通过。

•TGS 比对 Authenticator2 包含的 Client ID 和 TGT 中的 Client ID•比较时间戳（误差范围在2分钟）

•通过生命周期字段检查 TGT 是否过期

•检查 Authenticator2 已经不再 TGS 的缓存中

•若原始请求中的网络地址不为 NULL，比较 TGT 中的 IP 和请求的 IP验证成功后，随机生成 Client 所请求服务的会话密钥 Client/Server Session Key；

使用 Server 密钥（即服务器计算机的NTLM Hash）对 Client/Server Session Key、Client Info（包含 Client ID）、TimeStamp 加密得到 Client-To-Server Ticket（也称为 ST 票据）；

使用 Client/TGS Session Key 对 Client/Server Session Key 加密得到sessionkey_tgs

//ST=Server NTLM Hash(Client/Server Session Key,Client Info,TimeStamp)

//Sessionkey_tgs = Client/TGS Session Key(Client/Server Session Key)

最终将 Client-To-Server Ticket、sessionkey_tgs 返回给 Client。

2.3：第三步：Client与SS交互

Client 向 SS(Service Server)发送服务请求

AP-REQ：

Client 收到 Client-To-Server Ticket、sessionkey_tgs 之后，使用Client/TGS Session Key 对 sessionkey_tgs 解密得到 Client/Server Session Key,然后使用 Client/Server Session Key 对 Client Info 和 timestamp 加密得到Authenticator3；将 Authenticator3 和 Client-To-Server Ticket 发送给所请求服务的服务器(Service Server)。

Service Server 响应 Client

Service Server 收到客户端的服务访问请求之后，利用 Server 密钥(Server 的 ntlm Hash)对 Client-To-Server Ticket 解密，提取出 Client/Server SessionKey、Client ID 等信息。Service Server 使用 Client/Server SessionKey 对 Authenticator3 解密得到 Client ID 和 TimeStamp。

Service Server 发送最后的验证消息——用 Client/Server SessionKey 加密的 Timestamp 和 Service ID 数据包给 Client。

Client 收到之后，使用缓存的 Client/Server SessionKey 解密提取 Timestamp 信息，然后确认该信息与 Client 发送的 Authenticator3 中的 Timestamp 信息是否一致。验证通过后，在定义的通讯周期内，Client 可以使用票据请求 Service。

2.4：总结

第一步：返回TGT&Session Key_As

AS 的响应消息中有一条是属于 Client 的，有一条是 TGS 的。

• TGT 的到期时间为 8 小时，如果超过了 8 小时，还需要重新申请 TGT。
• KDC 返回的 TGT 客户端是无法解密的，因为它没有 KDC Hash，如果有，我们就可以伪造黄金票据

第二步：返回ST&Session Key_tgs

认证通过后TGS生成使用Logon Session Key（SKDC-Client）加密过用于Client和Server之间通信的Session Key（SServer-Client），Server的Master Key进行加密的ST(Service Ticket)

• 经过 Logon session key加密的Client和Server之间的Session Key
• 经过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 作中间人了。

白银票据不与KDC交互，伪造Ticket直接与 Service server进行交互，看下第三步Client和Server认证中的请求，Server接收到客户端的数据包后，使用自己的密码Hash解密 Ticket 得出 session key，再使用 session key解密Authenticator和timestamp即可通过验证，所以我们只需要知道 server 用户的hash可以伪造出一个 ticket，这就是白银票据。