深入理解 Active Directory身份验证 与Kerberos协议

Active Directory身份验证 的安全性对于任何环境都至关重要，因为它是身份保护的基石。在深入探讨AD DS（Active Directory Domain Services）安全性的改进之前，了解Active Directory身份验证如何与Kerberos协议协同工作是至关重要的。本文将解释AD身份验证在幕后的工作原理。

在基础设施中，使用了不同类型的身份验证协议。Active Directory使用Kerberos版本5作为身份验证协议，以在服务器和客户端之间提供身份验证。Kerberos v5从Windows Server 2003开始成为Windows Server的默认身份验证协议。它是一个开放标准，可与使用相同标准的其他系统进行互操作。

Kerberos协议的设计目的是在一个开放网络中保护服务器和客户端之间的身份验证，其中还连接了其他系统。身份验证的主要概念是，两方约定一个密码（秘密），并且两者都使用它来识别和验证对方的真实性。

在上面的示例中，Dave和Server A经常进行通信，在它们之间经常交换机密数据。为了保护这种通信，它们约定使用密码1234来验证在交换数据之前的身份。当Dave进行初始通信时，他将他的秘密传递给Server A，并说“我是Dave”。Server A检查秘密是否正确。如果正确，它将将其标识为Dave并允许进一步通信。

Dave和Server A之间的通信发生在开放网络中，这意味着有其他连接的系统。Sam是连接到与Dave相同网络的用户。他知道Dave和Server A之间的通信，对它们之间的数据交换感兴趣，并希望获取这些数据。他开始监听这两个主机之间的流量以找出它们使用的秘密。一旦他找到了秘密，他开始与Server A通信，并声称他是Dave，并提供秘密1234。从Server A的角度来看，现在无法区分来自Dave和Sam的消息，因为两者都提供了正确的秘密。Kerberos通过使用共享对称加密密钥而不是秘密来解决了这个挑战。它使用相同的密钥进行加密和解密。Kerberos的名称来自希腊神话中三头强大的狗。与三头狗一样，Kerberos协议有三个主要组件。

1. 客户端
2. 服务器
3. 负责发放秘密密钥的可信机构

这个可信机构被称为密钥分发中心（KDC）。在深入研究Kerberos之前，最好了解一下典型密钥交换的工作原理。

如果我们重新审视我们的场景，现在有一个KDC。现在Dave不直接与Server A通信，而是去KDC并告诉它他需要访问Server A。现在它需要一个对称密钥来开始与Server A的通信。这个密钥只应该由Dave和Server A使用。KDC接受请求并生成一个密钥（Key D+S），然后将其分发给Dave和Server A。从表面上看，这似乎相当简单，但从服务器的角度来看，存在一些挑战。为了接受来自Dave的连接，它需要知道Key D+S，因此它需要将这个密钥存储在Server A中。在这里，我们只考虑了一个连接。但如果有一百个连接，它需要存储涉及的所有密钥。这将为Server A消耗资源。然而，实际的Kerberos协议操作比这更有效。

在Active Directory环境中，KDC作为域控制器的一部分安装。KDC负责两个主要功能。

1. 身份验证服务（AS）
2. 授予票证服务（TGS）

例如，当Dave登录系统时，它需要向KDC证明他确实是他声称的人。当他登录时，他将他的用户名与“长时键”一起发送到KDC。长时键是基于Dave的密码生成的。Dave计算机上的Kerberos客户端接受他的密码并生成加密密钥。KDC还在其数据库中维护此密钥的副本。一旦KDC收到请求，它会检查用户名和长期密钥与其记录是否一致。如果一切正常，KDC会用一个会话密钥响应给Dave。这被称为票证授予票证（TGT）。TGT包含两个东西。

1. 用于与Dave通信的KDC使用的会话密钥的副本。这与KDC的长期密钥加密。
2. Dave可以用于与KDC通信的会话密钥的副本。这与Dave的长期密钥加密，因此只有Dave能够解密它。

一旦Dave收到这个密钥，他可以使用他的长期密钥解密会话密钥。之后，所有与KDC的未来通信都将基于这个会话密钥。这个会话密钥是临时的，并且有其TTL（生存时间）值。这个会话密钥保存在Dave计算机的易失性内存中。现在是请求访问Server A的时候了。Dave必须再次联系KDC，但这次他使用KDC提供的会话密钥。此请求包括TGT，由会话密钥加密的时间戳以及服务ID（运行在Server A上的服务）。一旦KDC收到它，它使用其长期密钥解密TGT并检索会话密钥。然后使用会话密钥解密时间戳。如果其更改少于5分钟，它证明其来自Dave，并且不是上一次的相同请求。一旦KDC确认为合法请求，它创建另一个票证，这被称为服务票证。它包含两个密钥。一个给Dave，一个给Server A。这两个密钥都包含请求者的名称（Dave），接收者，时间戳，TTL值以及由KDC和Dave之间共享的新会话密钥。其中一个密钥使用Dave的长期密钥加密。另一个密钥使用Server A的长期密钥加密。最后，两者都使用KDC和Dave之间的会话密钥加密。最后，票证准备就绪，并发送给Dave。Dave使用会话密钥解密票证。他还发现了“他的”密钥，并使用他的长期密钥解密它。它揭示了需要在他和Server A之间共享的新会话密钥。然后，他创建一个新的请求，其中包括从服务票证检索的Server A的密钥，由KDC创建的新会话密钥加密的时间戳。一旦Dave将其发送到Server A，Server A解密其密钥，并检索会话密钥。然后使用它，Server A可以解密时间戳以验证请求的真实性。正如我们所看到的，在这个过程中，Server A的责任不是跟踪客户端使用的密钥，而是客户端的责任保持相关的密钥。

让我们继续总结我们对Kerberos身份验证的了解。

1. Dave向KDC（域控制器）发送用户名和他的长期密钥。
2. KDC检查用户名和长期密钥与其数据库的一致性并验证身份。然后生成TGT（票证授予票证）。它包含KDC用于与Dave通信的会话密钥的副本。这与KDC的长期密钥加密。它还包含Dave用于与KDC通信的会话密钥的副本。
3. 以TGT响应Dave。
4. Dave使用他的长期密钥解密并检索会话密钥。然后，他的系统创建一个新的请求，包括TGT，由会话密钥加密的时间戳和服务ID。生成请求后，将其发送到KDC。
5. KDC使用其长期密钥解密TGT并检索会话密钥。然后，会话密钥可用于解密时间戳。接着，它创建一个服务票证。此票证包含两个密钥，一个给Server A，一个给Dave。Dave的密钥使用他的长期密钥加密，Server A的密钥使用Server A的长期密钥加密。最后，两者都使用KDC和Dave之间的会话密钥加密。
6. 将服务票证发送给Dave。
7. Dave使用会话密钥解密票证并检索他的密钥。然后，他继续解密以获取新密钥，该密钥可用于与Server A建立连接。最后，他创建另一个请求，包括Server A的密钥（在第5步创建），由Dave在此步骤中先前解密的会话密钥加密的时间戳。一切准备就绪后，系统将其发送到Server A。
8. Server A继续使用其长期密钥解密其密钥并检索会话密钥。然后，使用它，Server A可以解密时间戳以验证请求的真实性。一切正常后，允许Dave和Server A之间的连接。

在完成上述过程之前，还需要满足一些其他条件。

• 连通性 – 服务器、客户端和KDC之间需要可靠的连接以处理请求和响应。
• DNS – 客户端使用DNS查找KDC和服务器。因此，需要具有正确记录的正常运行的DNS。
• 时间同步 – 正如我们所看到的，该过程使用时间戳验证请求的真实性。它只允许5分钟的时间差异。因此，必须与PDC或其他时间源进行准确的时间同步。
• 服务主体名称（SPN） – 客户端使用SPN在AD环境中查找服务。如果服务没有SPN，客户端和KDC在需要时无法找到它们。在设置服务时，请确保设置SPN。