Windows域权限维持——Kerberos协议

一、Kerberos通信端口

• TCP/UDP的88（Kerberos）端口：身份验证和票据授予；
• TCP/UDP的464端口：Kerberos Kpaswd（密码重设）协议；
• LDAP：389
• LDAPS：636

二、Kerberos专有名词

名词	作用
AS	身份验证服务（验证client身份）
KDC	密钥分发中心（域内最重要的服务器，域控制器）
TGT	证明用户身份的票据（访问TGS的票据）
TGS	票据授权服务
ST	访问服务的票据
krbtgt	每个域中都有krbtgt账户，此账户是KDC服务账户在创建TGT时用来加密的，其密码随机生成
Principal	认证主体 Name[/Instance]@REALM
PAC	特权属性证书（用户的SID、用户所在的组）
SPN	服务主体名称
Session Key	临时会话密钥a，只有客户端和TGS知道
Server Session Key	临时会话密钥b，只有客户端和服务端知道
Authenticator	用session key加密，包含客户端主体名和时间戳，有效时间2分钟
Replay Cache	Kerberos 5 加入了Replay Cache，服务会缓存2分钟内收到的Authenticator，如果Authenticator和缓存中的相同，则拒绝

三、Kerberos角色组件

（1）KDC：KDC是AD目录服务的一部分，运行在域控上。它向域内的用户和计算机提供会话票据和临时会话票据，其服务账户为krbtgt；
（2）AS：身份验证服务器，它执行初始身份验证并为用户颁发票据授予票据（TGT，金票）；
（3）TGS：票据授予服务，它根据用户身份票据权限来颁发服务票据（ST，银票）；
（4）客户端：需要访问资源（如查看共享文件、查询数据库或进行远程连接）的用户，客户端在访问资源之前需要进行身份验证。
（5）服务端：对应域内计算机上的特点服务，每个服务都有一个唯一的SPN。

四、Kerberos认证流程概览

Kerberos是一种基于票据的认证方式。当客户端需要访问服务器的某个服务时，需要获取ST（service Ticket，服务票据）。也就是说。客户端在访问服务之前需要准备好ST，等待服务验证ST后才能访问。但是这张ST并不能直接获取，需要一种TGT（Ticket Granting TIcket，票据授予票据）证明客户端身份。也就是说，客户端在获得ST之前需要先获得一张证明身份的TGT。TGT和服务票据ST均由KDC颁发。因为KDC运行在域控上，所以TGT和ST均由域控颁发。Kerberos认证流程如下：

1. 当用户登录时，使用NTLM哈希对时间戳进行加密，以此向KDC证明他知道密码，此步骤被称为“预认证”；
2. 完成预认证后，认证服务器回向用户提供一张在有限时间内有效的TGT；
3. 当希望对某个服务进行身份验证时，用户将TGT呈现给KDC的TGS。如果TGT有效且用户权限具有该服务权限，则用户不会从TGS接收ST；
4. 用户可以将ST呈现给它们想要访问的服务。该服务可以对用户进行身份验证，并根据TGS中包含的数据做出授权决策。

五、Kerberos认证流程详解

5.1 AS-REQ和AS-REP（客户端和AS的交互）

1、AS-REQ

当域内的某个用户在客户端输入用户名和密码时、想要访问域内的某个服务时，客户端会向AS发送一个Authenticator的认证请求，认证请求携带了通过客户端NTLM哈希加密的时间戳、用户名、主机IP，以及一些其他参数（如消息类型、版本号、协商选项等），作为认证请求的凭据。因为需要验证AS是否为真，所以利用客户端的NTLM哈希进行加密。如果AS为真，则会正常解密AS-REQ。

2、AS-REP

在KDC中的AS收到客户端的REQ请求后，KDC就会检查客户端用户是否在AD白名单中。如果在且使用该客户端用户的密钥对Authenticator预认证请求解密成功，AS就生成随机sessionkey（CT_SK），使用用户密码的NTLM哈希对sessionkey（CT_SK）进行加密，并使用默认用户 krbtgt 的NTLM哈希对 sessionkey、客户端信息、客户端时间戳、认证到期时间进行加密，得到TGT，然后发送AS-REP响应包给客户端。

5.2 TGS-REQ和TGS-REP（客户端和TGS的交互）

1、TGS-REQ
收到AS发来的响应包后，客户端会使用自己的NTLM哈希对两部分密文进行解密，得到用于与TGS通信的密码 sessionkey（CT_SK）及sessionkey client缓存TGT，随即客户端使用sessionkey（CT_SK）加密一个Authenticator认证请求并发送给KDC的TGS，以此来获得 Server的访问权限。Authenticator认证包含客户端主体名、时间戳、客户端发送SS主体名、Lifetime、Authenticator 和TGT。

2、TGS-REP

TGS在收到TGS-REQ发送的Authenticator认证请求后，会对其SS主体名进行验证。如果验证存在，TGS使用账户krbtgt的NTLM哈希对TGT进行解密并提取出sessionkey，同时会就TGT的过期时间、Authenticator认证中的Client主体名等信息对客户端进行验证。校验通过后，TGS会随机生成一个新的字符串sessionkey，并向客户端一同返回以下两部分内容：

• 旧SessionKey加密的SS主体名、时间戳、存活时间、新sessionkey；
• 通过server哈希加密生成的票据，主要包括SS密钥加密的Client 主体名、SS主体名、IP_List、Timestamp、Lifetime、新sessionkey。

5.3 AP-REQ和AP-REP（客户端和服务端的交互）

1、AP-REQ

客户端收到TGS回复后，通过session key解密得到server session key，并将其加密成一个Authenticator（包括client主体名、timestamp、clientauthticator、service ticket），然后发给SS（server）。

2、AP-REP
服务端收到由客户端发来的AP-REO请求后，会通过服务密钥对ST进行解密，并从中提取service sessionkey信息，同时就TGT的过期时间、Authenticator认证中的Client主体名和TGT中是否相同等信息对客户端进行校验。校验成功后，服务端会检查在AP-REQ请求包中的协商选项设置是否要验证服务端的身份。如果配置了要验证服务端的身份，则服务端会对解密后的Authenticator再次使用Service sessionkey进行加密，通过AP-REP响应包发送给客户端。客户端再用缓存的Service sessionkey进行解密，如果和之前的内容完全相同，则证明自己正在访问的服务器和自己拥有相同德service sessionkey。