Windows安全认证机制之Kerberos 域认证

1. Kerberos简介

Kerberos是由麻省理工学院（MIT）开发的网络身份验证协议，它的主要好处是强大的加密和单点登录（SSO）。Kerberos作为一种可信任的第三方认证服务，是通过传统的密码技术（如共享密钥）实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并假定网络上传送的数据包可以被任意地读取、修改和插入数据的情况下保证通讯安全。

2.Kerberos通讯端口

1）TCP/UDP的88(Kerberos)端口：身份验证和票证授予。

2）TCP/UDP的464端口：Kerberos Kpaswd（密码重设）协议。

3）LDAP：389。

4）LDAPS：636。

3.Kerberos专用名词

4.Kerberos角色组件

如图1-1所示，Kerberos角色组件包含如下部分。

1）KDC：KDC是ADDS（AD目录服务）的一部分，运行在每个域控制器上。它向域内的用户和计算机提供会话票据和临时会话密钥，其服务帐户为krbtgt。

2）AS：身份认证服务，它执行初始身份验证并为用户颁发票证授予票证。

3）TGS：票据授权服务，它根据用户身份票据权限来颁发服务票据。

4）Client：客户端是指需要访问资源的用户，如查看共享文件、查询数据库或远程连接。客户端在访问资源之前需要进行身份验证。

5）Server：对应域内计算机上的特定服务，每个服务都有一个唯一的SPN。

图1-1 Kerberos角色组件

5. Kerberos认证流程概括

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

1）当用户登录时，使用NTLM Hash对时间戳进行加密，以向KDC证明他们知道密码，此步骤被称为“预认证”。

2）完成预认证后，认证服务器会向用户提供一张在有限时间内有效的票据授予票据（TGT）。

3）当用户希望对某个服务进行身份验证时，用户将TGT呈现给KDC的TGS服务。如果TGT有效且用户具有该服务权限，则用户会从票据授予服务（TGS）接收服务票据（ST）。

4）用户可以将ST呈现给他们想要访问的服务，该服务可以对用户进行身份验证，并根据TGS中包含的数据做出授权决策。

6. Kerberos认证流程详解

（1）AS_REQ & AS_REP（Client与AS的交互）

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

2）AS_REP。当KDC中的AS认证服务收到客户端AS_REQ 请求后，KDC就会检查客户端用户是否在AD白名单中，如果在AD白名单中且使用该客户端用户的密钥对Authenticator预认证请求解密成功，AS认证服务就生成随机sessionKey（CT_SK )，并使用用户密码的NTLM hash对sessionKey（CT_SK )进行加密，并且使用默认账户krbtgt的NTLM hash对sessionKey、客户端信息、客户端时间戳、认证到期时间进行加密，得到TGT（票据授予票据），然后发送AS_REP响应包给客户端。

（2）TGS_REQ & TGS_REP（Client与TGS的交互）

1）TGS_REQ。当客户端收到AS认证服务发来的相应包后，客户端会使用自己的NTLM hash对两部分密文内容进行解密得到用于与TGS通信的密钥SessionKey（CT_SK )以及SessionKey Client缓存TGT（票据授予票据），随即客户端使用SessionKey（CT_SK )加密一个Authenticator认证请求发送给KDC中的TGS，以此来获取Server的访问权限。Authenticator认证包含了Client主体名、Timestamp、客户端发送SS主体名、Lifetime、Authenticator和TGT。

2）TGS_REP。当TGS收到TGS_REQ发送的Authenticator认证请求后，会对其SS主体名进行验证，如果验证存在，TGS使用账户krbtgt的NTLM hash对TGT进行解密并提取出SessionKey，与此同时也会对TGT的过期时间、Authenticator认证中的Client主体名和TGT中是否相同等信息对客户端进行校验，校验通过后，TGS将会随机生成一个新的字符串Sessionkey，并向客户端一同返回如下两部分内容。

• 旧SessionKey加密的SS主体名、Timestamp（时间戳）、Lifetime（存活时间）、新SessionKey。
• 通过Server Hash加密生成的票据，主要包括了SS密钥加密的Client主体名、SS主体名、IP_List、Timestamp、Lifetime、新SessionKey。

（3）AP-REQ & AP-REP（Client与Server的交互）

1）AP-REQ。客户端收到TGS回复以后，通过SessionKey解密得到Server Session key后，并用其加密成一个Authenticator。Authenticator包括Client主体名、Timestamp、ClientAuthenticator、Service Ticket，发给SS（server）。

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

我正在参与2024腾讯技术创作特训营第五期有奖征文，快来和我瓜分大奖！