1.3.4 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专有名词
Kerberos的专有名词见表1-6。
表1-6 Kerberos专有名词
4.Kerberos角色组件
如图1-25所示，Kerberos角色组件包含如下部分。
1）KDC：KDC是ADDS（AD目录服务）的一部分，运行在每个域控制器上。它向域内的用户和计算机提供会话票据和临时会话密钥，其服务账户为krbtgt。
2）AS：一个身份认证服务器，它执行初始身份验证并为用户颁发票据授予票据。
3）TGS：票据授权服务，它根据用户身份票据权限来颁发服务票据。
4）客户端：需要访问资源（如查看共享文件、查询数据库或进行远程连接）的用户。客户端在访问资源之前需要进行身份验证。
5）服务端：对应域内计算机上的特定服务，每个服务都有一个唯一的SPN。
图1-25 Kerberos角色组件
5.Kerberos认证流程概览
Kerberos是一种基于票据的认证方式。当客户端需要访问服务器的某个服务时，需要获得ST（Service Ticket，服务票据）。也就是说，客户端在访问服务之前需要准备好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中包含的数据做出授权决策。
6.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白名单中。如果在且使用该客户端用户的密钥对Authenticator预认证请求解密成功，AS就生成随机sessionKey（CT_SK），使用用户密码的NTLM哈希对sessionKey（CT_SK）进行加密，并使用默认账户krbtgt的NTLM哈希对sessionKey、客户端信息、客户端时间戳、认证到期时间进行加密，得到TGT，然后发送AS-REP响应包给客户端。
（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主体名和TGT中是否相同等信息对客户端进行校验。校验通过后，TGS将会随机生成一个新的字符串sessionKey，并向客户端一同返回如下两部分内容。
❑旧sessionKey加密的SS主体名、Timestamp（时间戳）、Lifetime（存活时间）、新sessionKey。
❑通过Server哈希加密生成的票据，主要包括SS密钥加密的Client主体名、SS主体名、IP_List、Timestamp、Lifetime、新sessionKey。
（3）AP-REQ和AP-REP（客户端与服务端的交互）
1）AP-REQ。客户端收到TGS回复以后，通过sessionKey解密得到Server session Key，并将其加密成一个Authenticator（包括Client主体名、Timestamp、ClientAuthenti-cator、Service Ticket），然后发给SS（server）。
2）AP-REP。服务端收到由客户端发来的AP-REQ请求之后，会通过服务密钥对ST进行解密，并从中提取Service sessionKey信息，同时就TGT的过期时间、Authenticator认证中的Client主体名和TGT中是否相同等信息对客户端进行校验。校验成功后，服务端会检查在AP-REQ请求包中的协商选项配置是否要验证服务端的身份。如果配置了要验证服务端的身份，则服务端会对解密后的Authenticator再次使用Service sessionKey进行加密，通过AP-REP响应包发送给客户端。客户端再用缓存的Service sessionKey进行解密，如果和之前的内容完全一样，则证明自己正在访问的服务器和自己拥有相同的Service sessionKey。