The Kerberos authentication protocol used by Microsoft is adopted from Kerberos version 5 created by MIT. Kerberos has been used as Microsoft's primary authentication mechanism since Windows Server 2003. While NTLM authentication works via a challenge-and-response paradigm, Windows-based Kerberos authentication uses a ticket system.
Microsoft 使用的 Kerberos 身份验证协议采用自 MIT 创建的 Kerberos 版本 5。自 Windows Server 2003 以来，Kerberos 一直用作 Microsoft 的主要身份验证机制。NTLM 身份验证通过质询和响应模式工作，而基于 Windows 的 Kerberos 身份验证使用票证系统。

A key difference between these two protocols (based on the underlying systems) is that with NTLM authentication, the client starts the authentication process with the application server itself, as discussed in the previous section. On the other hand, Kerberos client authentication involves the use of a domain controller in the role of a Key Distribution Center (KDC).¹ The client starts the authentication process with the KDC and not the application server. A KDC service runs on each domain controller and is responsible for session tickets and temporary session keys to users and computers.
这两种协议（基于底层系统）之间的一个关键区别是，使用 NTLM 身份验证时，客户端使用应用程序服务器本身启动身份验证过程，如上一节所述。另一方面，Kerberos 客户端身份验证涉及在密钥分发中心 （KDC） 的角色中使用域控制器。¹ 客户端使用 KDC 而不是应用程序服务器启动身份验证过程。KDC 服务在每个域控制器上运行，负责用户和计算机的会话票证和临时会话密钥。

The client authentication process at a high level is shown in Figure 2.
图 2 显示了高级别的客户端身份验证过程。

Let's review this process in detail. First, when a user logs in to their workstation, an Authentication Server Request (AS-REQ) is sent to the domain controller. The domain controller, acting as a KDC, also maintains the Authentication Server service. The AS-REQ contains a timestamp that is encrypted using a hash derived from the password of the user² and their username.
让我们详细回顾一下这个过程。首先，当用户登录其工作站时，将向域控制器发送 Authentication Server 请求 （AS-REQ）。充当 KDC 的域控制器还维护 Authentication Server 服务。AS-REQ 包含一个时间戳，该时间戳使用从用户² 的密码及其用户名派生的哈希值进行加密。

When the domain controller receives the request, it looks up the password hash associated with the specific user in the ntds.dit³ file and attempts to decrypt the timestamp. If the decryption process is successful and the timestamp is not a duplicate, the authentication is considered successful.
当域控制器收到请求时，它会在 ntds.dit³ 文件中查找与特定用户关联的密码哈希，并尝试解密时间戳。如果解密过程成功且时间戳不重复，则认为身份验证成功。

Next, the domain controller replies to the client with an Authentication Server Reply (AS-REP). Since Kerberos is a stateless protocol, the AS-REP contains a session key and a Ticket Granting Ticket (TGT). The session key is encrypted using the user's password hash and may be decrypted by the client and then reused. The TGT contains information regarding the user, the domain, a timestamp, the IP address of the client, and the session key.
接下来，域控制器使用 Authentication Server Reply （AS-REP） 回复客户端。由于 Kerberos 是无状态协议，因此 AS-REP 包含会话密钥和票证授予票证 （TGT）。会话密钥使用用户的密码哈希进行加密，客户端可以解密，然后重复使用。TGT 包含有关用户、域、时间戳、客户端 IP 地址和会话密钥的信息。

To avoid tampering, the TGT is encrypted by a secret key (NTLM hash of the krbtgt⁴ account) known only to the KDC and cannot be decrypted by the client. Once the client has received the session key and the TGT, the KDC considers the client authentication complete. By default, the TGT will be valid for ten hours, after which a renewal occurs. This renewal does not require the user to re-enter their password.
为避免篡改，TGT 由只有 KDC 知道的密钥（krbtgt⁴ 帐户的 NTLM 哈希）加密，客户端无法解密。客户端收到会话密钥和 TGT 后，KDC 会认为客户端身份验证已完成。默认情况下，TGT 的有效期为 10 小时，之后将进行续订。此续订不需要用户重新输入其密码。

When the user wishes to access resources of the domain, such as a network share or a mailbox, it must again contact the KDC.
当用户希望访问域的资源（如网络共享或邮箱）时，必须再次联系 KDC。

This time, the client constructs a Ticket Granting Service Request (TGS-REQ) packet that consists of the current user and a timestamp encrypted with the session key, the name of the resource, and the encrypted TGT.
这一次，客户端构建一个票证授予服务请求 （TGS-REQ） 数据包，该数据包由当前用户和使用会话密钥、资源名称和加密的 TGT 加密的时间戳组成。

Next, the ticket-granting service on the KDC receives the TGS-REQ, and if the resource exists in the domain, the TGT is decrypted using the secret key known only to the KDC. The session key is then extracted from the TGT and used to decrypt the username and timestamp of the request. At this point the KDC performs several checks:
接下来，KDC 上的票证授予服务接收 TGS-REQ，如果资源存在于域中，则使用只有 KDC 知道的密钥解密 TGT。然后从 TGT 中提取会话密钥，并用于解密请求的用户名和时间戳。此时，KDC 将执行多项检查：

1. The TGT must have a valid timestamp.
   TGT 必须具有有效的时间戳。
2. The username from the TGS-REQ has to match the username from the TGT.
   TGS-REQ 中的用户名必须与 TGT 中的用户名匹配。
3. The client IP address needs to coincide with the TGT IP address.
   客户端 IP 地址需要与 TGT IP 地址一致。

If this verification process succeeds, the ticket-granting service responds to the client with a Ticket Granting Server Reply (TGS-REP). This packet contains three parts:
如果此验证过程成功，则票证授予服务将使用票证授予服务器回复 （TGS-REP） 响应客户端。此数据包包含三个部分：

1. The name of the service for which access has been granted.
   已授予访问权限的服务的名称。
2. A session key to be used between the client and the service.
   要在客户端和服务之间使用的会话密钥。
3. A service ticket containing the username and group memberships along with the newly-created session key.
   包含用户名和组成员资格以及新创建的会话密钥的服务票证。

The service ticket's service name and session key are encrypted using the original session key associated with the creation of the TGT. The service ticket is encrypted using the password hash of the service account registered with the service in question.
服务票证的服务名称和会话密钥使用与创建 TGT 关联的原始会话密钥进行加密。使用向相关服务注册的服务帐户的密码哈希对服务票证进行加密。

Once the authentication process by the KDC is complete and the client has both a session key and a service ticket, the service authentication begins.
KDC 的身份验证过程完成并且客户端同时具有会话密钥和服务票证后，服务身份验证将开始。

First, the client sends the application server an Application Request (AP-REQ), which includes the username and a timestamp encrypted with the session key associated with the service ticket along with the service ticket itself.
首先，客户端向应用程序服务器发送应用程序请求 （AP-REQ），其中包括用户名和时间戳，该时间戳使用与服务票证关联的会话密钥以及服务票证本身进行加密。

The application server decrypts the service ticket using the service account password hash and extracts the username and the session key. It then uses the latter to decrypt the username from the AP-REQ. If the AP-REQ username matches the one decrypted from the service ticket, the request is accepted. Before access is granted, the service inspects the supplied group memberships in the service ticket and assigns appropriate permissions to the user, after which the user may access the requested service.
应用程序服务器使用服务帐户密码哈希解密服务票证，并提取用户名和会话密钥。然后，它使用后者解密 AP-REQ 中的用户名。如果 AP-REQ 用户名与从服务票证解密的用户名匹配，则接受请求。在授予访问权限之前，该服务会检查服务票证中提供的组成员资格，并向用户分配适当的权限，之后用户可以访问请求的服务。

This protocol may seem complicated and perhaps even convoluted, but it was designed to mitigate various network attacks and prevent the use of fake credentials.
该协议可能看起来很复杂，甚至可能令人费解，但它旨在减轻各种网络攻击并防止使用假凭据。

Now that we have discussed the foundations of both NTLM and Kerberos authentication, let's explore various cached credential storage and service account attacks.
现在我们已经讨论了 NTLM 和 Kerberos 身份验证的基础，让我们来探讨各种缓存的凭证存储和服务账户攻击。