下载掌阅APP，畅读海量书库
立即打开
Kerberos是由美国麻省理工学院（MIT）开发的一种网络身份验证协议，它的主要优势在于强大的加密和单一登录功能。Kerberos作为一种可信任的第三方认证服务，可以通过传统的密码技术（如共享密钥）实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全，并能在网络上传送的数据包可以被任意地读取、修改和插入数据的情况下保证通信安全。
Kerberos是一种基于票据（Ticket）的认证方式。当客户端访问服务端的某个服务时，需要获得服务票据（Service Ticket，ST）。也就是说，客户端在访问服务之前需要准备好ST，等待服务验证ST后才能访问。但是这张票并不能直接获得，需要一张票据授权票据（Ticket Granting Ticket，TGT）证明客户端身份。因此，客户端在获得ST之前必须先获得一张证明身份的TGT。TGT和ST均是由密钥分发中心（Key Distribution Center，KDC）发放的。因为KDC运行在域控制器上，所以TGT和ST均由域控制器颁发。
Kerberos认证的简要流程如下，过程中常见的名词及解释如表1-3所示。
1）当用户登录时，使用NTLM哈希对时间戳进行加密，以向KDC证明用户知道密码，此步骤被称为“预身份验证”。
2）完成预身份验证后，认证服务器会向用户提供一张在有限时间内有效的TGT。
3）当用户希望对某个服务进行身份验证时，用户需要将TGT呈现给KDC的票据授权服务（Ticket Granting Service，TGS）。如果TGT有效且用户具有访问该服务的权限，则用户会从TGS中接收ST。
4）用户可以将ST提供给他们想要访问的服务。这些服务可以据此对用户进行身份验证，并根据TGS所包含的数据做出授权决策。
表1-3 Kerberos认证流程中常用名词及解释
（续）
下面介绍Kerberos通信端口、角色组件及认证流程细节。
常用的Kerberos通信端口如下。
❑TCP/UDP的88端口：身份验证和票证授予。
❑TCP/UDP的464端口：Kerberos Kpaswd（密码重设）协议。
❑LDAP的389端口：用于轻型目录访问协议中。
❑LDAPS的636端口：使用SSL/TLS技术加密LDAP流量。
如图1-41所示，Kerberos角色组件如下。
1）KDC：KDC是AD目录服务（AD DS）的一部分，运行在每个域控制器上。它向域内的用户和计算机提供会话票据及临时会话密钥，其服务账户为krbtgt。
2）AS：执行初始身份验证并为用户颁发票证授予票据。
3）TGS：根据用户身份票据权限来颁发服务票据。
4）Client：客户端，指需要访问资源的用户，执行查看共享文件、查询数据库或远程连接等操作。客户端在访问资源之前需要进行身份验证。
5）Server：服务端，对应域内计算机上的特定服务，每个服务都有一个唯一的SPN。
图1-41 Kerberos角色组件
（1）AS-REQ和AS-REP（客户端与AS的交互）
1）AS-REQ。当域内的某个用户在客户端输入账号密码，想要访问域中的某个服务时，客户端就会向AS发送一个Authenticator认证请求。该认证请求中携带了通过客户端NTLM哈希加密的时间戳、用户名、主机IP，以及消息类型、版本号、协商选项等其他参数信息，这些都会作为认证请求的凭据。为了验证AS是否为真，该请求利用客户端的NTLM哈希进行加密，如果AS为真，则会正常解密AS-REQ。
2）AS-REP。当KDC中的AS收到客户端的AS-REQ请求后，KDC会检查客户端用户是否在AD白名单中。如果在AD白名单中，且能够使用该客户端用户的密钥成功对Authenticator预认证请求解密，则AS就会生成随机的Session Key（CT_SK），并使用用户密码的NTLM哈希对该Session Key进行加密。之后，AS使用默认账户krbtgt的NTLM哈希对Session Key、客户端信息、客户端时间戳、认证到期时间进行加密，生成TGT，并发送AS-REP响应包给客户端。
（2）TGS-REQ和TGS-REP（客户端与TGS的交互）
1）TGS-REQ。当客户端收到AS发来的响应包后，客户端会使用自己的NTLM哈希对两部分密文进行解密，以得到用于与TGS通信的Session Key（CT_SK）及客户端缓存的TGT。随即，客户端使用该Session Key加密一个Authenticator认证请求，并将其发送给KDC中的TGS，以获取服务端的访问权限。Authenticator认证包含客户端主体名、时间戳、客户端发送的SS主体名、存活时间、Authenticator和TGT。
2）TGS-REP。当TGS收到TGS-REQ发送的Authenticator认证请求后，会对其SS主体名进行验证。如果验证通过，则TGS使用账户krbtgt的NTLM哈希对TGT进行解密并提取Session Key。与此同时，TGS会对客户端进行校验，检查TGT的过期时间，以及Authenticator中的客户端主体名是否与TGT中的信息相同等。校验通过后，TGS将会随机生成一个新的字符串Session Key，并向客户端一同返回如下两部分内容。
❑由旧Session Key加密的SS主体名、时间戳、存活时间、新Session Key。
❑通过服务端哈希加密生成的票据，主要包括SS密钥加密的客户端主体名、SS主体名、IP列表、时间戳、存活时间、新Session Key。
（3）AP-REQ和AP-REP（客户端与服务端的交互）
1）AP-REQ。客户端收到TGS回复以后，通过Session Key解密得到Server Session key后，并用其加密成一个Authenticator。Authenticator包括客户端主体名、时间戳、客户端Authenticator、ST，发给SS（服务端）。
2）AP-REP。服务端收到由客户端发来的AP-REQ请求之后，会通过服务密钥对ST进行解密，并从中提取Service Session Key。与此同时，服务端会校验TGT的过期时间，以及Authenticator认证中的客户端主体名和TGT中的是否相同等。校验成功后，服务端会检查在AP-REQ请求包中的协商选项配置，查看是否要验证服务端的身份。如果要验证服务端的身份，则服务端会对解密后的Authenticator再次使用Service Session Key进行加密，并通过AP-REP响应包发送给客户端，客户端再用缓存的Service Session Key进行解密。如果解密后的内容和之前的内容完全一致，则可以证明自己正在访问的服务器拥有和自己相同的Service Session Key。