了解 Kerberos：它是什么？它是如何工作的？

在希腊神话中，Kerberos是一只看守地狱之门的多头狗。 Kerberos 在技术中的含义是类似的：Kerberos 是一种身份验证协议，它使系统和用户能够在授予资源访问权限之前相互证明自己的身份，从而保护网络。 继续阅读以了解 Kerberos 身份验证的工作原理并获得避免问题的宝贵提示。

Kerberos结构和操作

Kerberos 因协议中的三个不同参与者而以三头狗命名：

• 客户：寻求提供其身份的实体
• 应用服务器(AP)：客户端或用户想要访问的服务
• 密钥分发中心（KDC）：颁发票据的受信任第三方

几乎所有操作系统都支持 Kerberos，包括 Apple OSX/iOS 以及许多 UNIX 和 Linux 发行版。然而，Microsoft Active Directory 是使用最广泛的 Kerberos 实现。它基于 Kerberos 网络身份验证服务 (V5)。

Microsoft 对基本协议规范进行了扩展，添加了许多扩展来实现特定于 Active Directory 和 Windows Server 操作系统的功能。

在 Active Directory 中，每个域控制器充当 KDC 并提供两项核心服务：

• 身份验证服务 (AS) — 对客户端进行身份验证并向其颁发票据
• 票证授予服务 (TGS) — 接受经过身份验证的客户端并向他们颁发票证以访问其他资源

门票采用对称加密技术。某些用户密码用于加密和签署特定票证，但 Kerberos 安全性的根源是只有颁发票证的受信任第三方知道的密钥。

Kerberos 身份验证过程

Kerberos 身份验证的每个步骤都采用加密技术来保护数据包不被更改或读取，并提供相互身份验证。客户端向 KDC 请求用户的票证，并使用用户的密码对请求进行加密。如果 KDC 可以使用其存储的用户密码解密请求，则它知道客户端已为用户提供了正确的密码。 KDC 为用户创建票证授予票证 (TGT)，使用用户密码对其进行加密，然后返回给客户端。如果客户端可以使用用户的密码解密该票证，则它知道 KDC 是合法的。

客户端通过提供其 TGT 和票证授予服务 (TGS) 请求（其中包括其想要访问的服务的服务主体名称）来向 KDC 请求服务票证。 KDC 创建一个使用服务的密码哈希（TGS 密钥）加密的服务票证 (TGS)，使用共享票证授予服务会话密钥对票证和身份验证器消息进行加密，最后将 TGS 发送回客户端。

客户端通过向应用程序服务器提供从 KDC 获取的服务票证来请求访问应用程序服务器（服务），应用程序服务器使用自己的密码哈希来解密该消息。如果成功解密 TGS，应用程序服务器将授予客户端访问权限。

Kerberos 身份验证步骤

图 1：Kerberos 身份验证流程

1. KRB_AS_REQ：从身份验证服务 (AS) 请求 TGT

客户端的请求包括用户的用户主体名称 (UPN) 和时间戳。它使用用户的密码哈希进行加密。

1. KRB_AS_REP：从身份验证服务收到的 TGT

KDC 使用 UPN 在其数据库中查找客户端，并使用用户的密码哈希来尝试解密消息。

AS 生成包含客户端 ID、客户端网络地址、时间戳、生存期和会话密钥 (SK1) 的 TGT。

如果 KDC 成功解密 TGT 请求，并且时间戳在 KDC 配置的时间偏差内，则身份验证成功。

TGT 和 TGS 会话密钥被发送回客户端。 TGS 会话密钥用于加密后续请求。

1. KRB_TGS_REQ：当前 TGT 和 TGS 请求

客户端提供其 TGT 以及包含其想要访问的服务的 SPN 的请求。 TGS 请求使用 TGS 会话密钥进行加密。

1. KRB_TGS_REP：从 KDC 接收 TGS

KDC 尝试验证 TGT；如果成功，它会生成一个 TGS，其中包含有关请求者的信息，例如其 SID 和组成员身份，并使用服务的密码哈希进行加密。

TGS 和服务会话密钥使用 TGS 会话密钥加密并发回客户端。

1. KRB_AP_REQ：向应用程序服务器提供 TGS 进行授权

客户端将从 KDC 收到的 TGS 以及使用服务会话密钥加密的身份验证器消息发送到应用程序服务器。

1. KRB_AP_REP：授予客户端对服务的访问权限

客户端接收消息并使用服务会话密钥对其进行解密。

应用程序服务器从服务票证中提取权限属性证书 (PAC)，以通过域控制器验证其内容。

仅当 TGT 超过 20 分钟时才会验证票证和 PAC。

影响 Kerberos 运行的因素

如果没有充分考虑，有一些因素会出现问题。

• 域控制器之间需要复制。
  如果部署了多个域控制器（因此也有多个 KDC），则必须启用并及时进行复制。如果复制失败或延迟，用户更改密码时身份验证可能会失败。
• 客户端和 KDC 必须使用 NetBIOS 和 DNS 名称解析。
  Kerberos 服务主体名称通常包括 NetBIOS 和 DNS 地址，这意味着 KDC 和客户端必须能够以相同的方式解析这些名称。在某些情况下，IP 地址也可以用在服务主体名称中。
• 客户端和 KDC 的时钟必须同步。
  准确测量时间对于防止重放攻击非常重要。 Kerberos 支持可配置的时间偏差（默认情况下为 5 分钟），超出该时间偏差客户端身份验证将失败。
• 客户端和 KDC 必须能够在网络上进行通信。
  Kerberos 流量发生在 TCP 和 UDP 端口 88 上，所有客户端都必须能够访问该端口，并且至少有一个 KDC。
• 客户端、用户和服务必须具有唯一的名称。
  计算机、用户或服务主体名称的重复凭据可能会导致意外的 Kerberos 身份验证

Kerberos 与 LDAP

在阅读有关 Kerberos 协议的内容时，您会经常看到提及轻量级目录访问协议 (LDAP)。 Kerberos 和 LDAP 通常一起使用（包括在 Microsoft Active Directory 中），以提供集中式用户目录 (LDAP) 和安全身份验证 (Kerberos) 服务。

LDAP 在中央位置存储有关用户、组和其他对象（如计算机）的信息。它还可以提供简单的身份验证；然而，与 Kerberos 不同，该协议通常需要通过网络传输用户的秘密（即密码）。用户想要访问的每个资源都必须处理用户的密码并单独对目录进行用户身份验证。

与 LDAP 不同，Kerberos 提供单点登录功能。一旦用户通过 KDC 身份验证，其他服务（例如 Intranet 站点或文件共享）就不需要该用户的密码。 KDC 负责颁发每个服务信任的票证。

LDAP 和 Kerberos 的组合提供了集中的用户管理和身份验证，并且在较大的网络中，Kerberos 提供了显着的安全优势。

如何查看我的 Kerberos 票证？

查看您的 Kerberos 票证很容易。在 Microsoft Windows 计算机上，您可以通过打开命令提示符或 PowerShell 并运行 klist Tickets 命令，使用 klist.exe 程序来枚举它们。在下面的示例中，您可以看到 Joe 拥有 CIFS 服务的票证，该服务是对名为 fileserver1 的服务器的文件共享访问。

PS C:Windowssystem32> klist tickets
Current LogonId is 0:0xe67df
Cached Tickets: (4)
#0> Client: Joe @ domain.local
  Server: cifs/fileserver1.domain.local/domain.local @ DOMAIN.LOCAL
  KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
  Ticket Flags 0x60a10000 -> forwardable forwarded renewable pre_authent name_canonicalize
  Start Time: 7/10/2020 12:33:49 (local)
  End Time: 7/10/2020 22:32:13 (local)
  Renew Time: 7/17/2020 12:32:13 (local)
  Session Key Type: AES-256-CTS-HMAC-SHA1-96
  Cache Flags: 0x40 -> FAST
  Kdc Called: DC1.domain.local

结论

Kerberos 是一种众所周知且广泛使用的身份验证协议。由于它是 Microsoft Active Directory 的核心，因此它已成为最容易被各种攻击者滥用的协议之一。 Netwrix 致力于帮助企业防范和检测针对 Active Directory 的攻击。要了解更多信息，请访问 Netwrix 攻击目录或访问我们的网站以探索我们的解决方案组合。