Freigeben über

Kerberos 验证

  • Artikel

我将在这里阐述关于Kerberos验证的过程。在此之前，我们先记住如下两个规则。我将在下文进行解释。

· 如果A与B两者拥有只有他们之间想要分享的信息，他们就会对该通信通过Session Key的方式进行加密。通常写为A / B Session Key 。

· 如果A的某些信息需要交到B手中，又不愿意B了解信息的内容，A会使用只有自己知道的Secret Key进行加密

 

在本文中，将使用到的术语如下：

· AS – Authentication Server

· TGS – Ticket Granting Server

· TGT – Ticket Granting Ticket

在本文中AS和TGS扮演同样的角色。

 

Kerberos验证的过程可以分为4步：客户端登陆；客户端验证；客户端-服务端验证；客户端-服务端请求；

 

客户端登陆

1． 客户端接收用户名与密码的输入。

2． 客户端计算密码的Hash值，并保存为客户端的Secret Key

 

 

客户端验证

1． 客户端以明文的方式，向验证服务器（Authentication Server / Ticket Granting Server）发送用户名。在微软的Kerberos实现中，验证服务器由KDC来实现。

2． 验证服务器在接收到客户端明文发过来的用户名后，从AD服务器中查询该用户名所对应的用户信息，并取得密码。注意，客户端并没有把密码也发给验证服务器。

3． 验证服务器通过同样的Hash算法，计算上步得到用户在AD服务器中的密码所对应的Hash值，作为Secret Key。我们可以看到，客户端和验证服务器分别通过相同的方法生成Secret Key。若客户端的密码与验证服务器从AD中查询到的密码一致，则生成的Secret Key也是一致的。

4． 验证服务器生成 Client/ TGS Session Key，并用上步得到的Secret Key进行加密。

5． 验证服务器同时生成一个TGT，使用TGS Secret Key进行加密。所以，该内容只有TGS自己可以解密。包含如下内容：

a.       Client ID

b.      Client Network Address

c.       Ticket Valid Period

d.      Client / TGS Session Key

6． 验证服务器将消息4与5的加密信息发给客户端。

7． 客户端如果成功使用自己的Secret Key解密了4，则认为客户端验证成功。客户端无法解密消息5的TGT。

如果你使用NetMon进行观察的话，就可以看到如下信息。

 

 

客户端- 服务端验证

1． 客户端生成消息1： TGT + Service ID。Service ID为需要访问的服务ID。无加密。

2． 客户端生成消息2：Client ID + 时间戳。并用Client / TGS Session Key进行加密。

3． 客户端将上述消息1和消息2发送给验证服务器。

4． 验证服务器通过消息1中的Service ID。

5． 验证服务器验证客户端是否有访问该Service的权限。

6． 验证服务器查询该Service ID在验证服务器上保存的Service Secret Key。

7． 验证服务器生成Client / Server Session Key。此处Server即Service。注意，这个Session Key由验证服务器生成。Service本身

8． 验证服务器生成消息8：Client-To-Server-Ticket。用Service Secret Key进行加密。包含：

a.       Client ID

b.      Client Network Address

c.       Ticket Valid Period

d.      Client / Server Session Key

9． 验证服务器生成消息9，包含使用Client / TGS Session Key加密的Client / Server Session Key。

10.   验证服务器将消息8与消息9一起发送给客户端。

如果你使用NetMon进行观察的话，就可以看到如下信息。

 

 

客户端- 服务端请求

1.       客户端从收到的消息9中，通过Client / TGS Session Key进行解锁，从而获得Client / Server Session Key。

2.       客户端将收到的Client-To-Server-Ticket转发给服务端。

3.       服务端使用自己的Service Secret Key对Client-To-Server-Ticket进行解锁，并获得Client / Server Session Key。

4.       如上述步骤成功，则整个Kerberos验证过程成功。客户端与服务端将由此通过进行Client / Server Session Key交互。

5.       在其后的客户端-服务器端交互的过程中，消息都会带有客户端或者服务端的时间戳，以保证当前的验证依然有效。如果来自客户端与服务端的时间戳超过5分钟，也会被认为是验证失败。