我将在这里阐述关于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分钟，也会被认为是验证失败。
· 如果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分钟，也会被认为是验证失败。
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货