今天看到一篇关于域认证协议的文章，写得很好，就学习记录一下，文章传送门
NTLM协议—主机认证协议
首先讲述了NTLM协议，是一种基于Challenge/Response的认证机制，仅支持Windows的网络认证协议。过程如下（将文章中的叙述画图表示了一下）：
原文叙述内容：
1
2
3
4
| 1. 首先，client会向server发送一个username，这个username是存在于server上的一个用户
2. 首先会在本地查询是否存在这样的一个用户，如果存在，将会生成一个16位的随机字符，即Chalenge，然后用查询到的这个user的NTLM hash对Chalenge进行加密，生成Chalenge1，将Chalenge1存储在本地，并将Chalenge传给client。
3. 当client接收到Chalenge时，将发送的username所对应的NTLM hash对Chalenge进行加密即Response，并Response发送给server。
4. server在收到Response后，将其与Chalenge1进行比较，如果相同，则验证成功。
|
Kerberos协议—域认证协议
引用原文：Kerberos是一种网络认证协议，其设计目标是通过密钥系统为客户机 / 服务器应用程序提供强大的认证服务。该认证过程的实现不依赖于主机操作系统的认证，无需基于主机地址的信任，不要求网络上所有主机的物理安全。
在Kerberos协议中有三个角色：用户、服务器、密钥分发中心（KDC），其中KDC又由验证服务器（AS）和票据授予服务器（TGS）组成。
- AS：主要发放 票据授予票据（TGT）
- TGS：主要发放 授予票据（ST）
这个认证流程首先可以分成三个部分：Client – KDC.AS、Client – KDC.TGS、Client – Server
Client – KDC.AS 认证流程
流程如下：
这里对信息1进行一下分析：
首先，TGT是用TGS的密钥加密的，这部分对于Client来说是无法解密的，但是后续Client将TGT发送到TGS，由于里面包含了AS认证的客户端.name，所以验证了Client的真实性。
然后就是$$这部分（名字是随便起的，标识一下），由于是用Client的密钥加密的，所以Client通过解密后可以得到：TGS的名字、CT_SK、TGT有效时间、时间戳。
原文内容：
1
2
3
4
5
6
7
8
9
| 1、客户端用户向KDC以明文的方式发起请求。该次请求中携带了自己的用户名，主机IP，和当前时间戳；
2、KDC当中的AS接收请求（AS是KDC中专门用来认证客户端身份的认证服务器）后去kerberos认证数据库中根据用户名查找是否存在该用户，如果存在该用户名，则AS认证中心便认为用户存在，此时便会返回响应给客户端，其中包含两部分内容：
TGT：客户端需要使用TGT去KDC中的TGS获取访问网络服务所需的ST（服务授予票据），TGT中包含的内容有kerberos数据库中存在的该客户端的Name，IP，当前时间戳，客户端即将访问的TGS的Name，TGT的有效时间以及Session_key(CT_SK)。
整个TGT使用TGS密钥加密，客户端是解密不了的，由于密钥从没有在网络中传输过，所以也不存在密钥被劫持破解的情况。
第二部分内容是使用客户端密钥加密的一段内容，其中包括Session_key(CT_SK),客户端即将访问的TGS的Name以及TGT的有效时间，和一个当前时间戳。该部分内容使用客户端密钥加密，所以客户端在拿到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，因为该密钥也从没在网络中进行传输过。这也同时认证了客户端的身份，如果是假客户端会由于解密失败从而终端认证流程。
|
Client – KDC.TGS 认证流程
流程如下：
这里对信息2进行一下分析：
首先ST是用Server密钥加密的，客户端无法解密所以不能伪造，下一步发送给Server后，Server解密后即可验证Client。
然后是 $$$$，由于是用的CT_SK加密，在前面客户端是有CT_SK的，所以可以解密得到CS_SK（用于与Server通信的Session_key）。
这里继续附上原文内容：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| 1、客户端使用CT_SK加密将自己的客户端信息发送给KDC，其中包括客户端名，IP，时间戳；
2、客户端将自己想要访问的Server服务以明文的方式发送给KDC；
3、客户端将使用TGS密钥加密的TGT也原封不动的也携带给KDC；
4、此时KDC中的TGS（票据授予服务器）收到了来自客户端的请求。他首先根据客户端明文传输过来的Server服务IP查看当前kerberos系统中是否存在可以被用户访问的该服务。如果不存在，认证失败结束，。如果存在，继续接下来的认证。
5、TGS使用自己的密钥将TGT中的内容进行解密，此时他看到了经过AS认证过后并记录的用户信息，一把Session_KEY即CT_SK，还有时间戳信息，他会现根据时间戳判断此次通信是否真是可靠有无超出时延。
6、如果时延正常，则TGS会使用CT_SK对客户端的第一部分内容进行解密（使用CT_SK加密的客户端信息），取出其中的用户信息和TGT中的用户信息进行比对，如果全部相同则认为客户端身份正确，方可继续进行下一步。
7、此时KDC将返回响应给客户端，响应内容包括：
第一部分：用于客户端访问网络服务的使用Server密码加密的ST（Servre Ticket），其中包括客户端的Name，
IP，需要访问的网络服务的地址Server IP，ST的有效时间，时间戳以及用于客户端和服务端之间通信CS_SK（SessionKey）
第二部分：使用CT_SK加密的内容，其中包括CS_SK和时间戳，还有ST的有效时间。由于在第一次通信的过程中，AS已将CT_SK通过客户端密码加密交给了客户端，且客户端解密并缓存了CT_SK，所以该部分内容在客户端接收到时是可以自己解密的。
|
Client – Server 认证流程
流程如下：
这里在最后一步Server返回数据Response，原文中是讲用CT_SK加密，可能是笔误，所以这里修改成了CS_SK加密，毕竟这是客户端和服务器的通信，需要客户端和服务器的Session Key。
下面放上原文内容：
1
2
3
4
5
| 1、客户端使用CS_SK将自己的主机信息和时间戳进行加密作为交给服务端的第一部分内容，然后将ST（服务授予票据）作为第二部分内容都发送给服务端。
2、服务器此时收到了来自客户端的请求，他会使用自己的密钥，即Server密钥将客户端第二部分内容进行解密，核对时间戳之后将其中的CS_SK取出，使用CS_SK将客户端发来的第一部分内容进行解密，从而获得经过TGS认证过后的客户端信息，此时他将这部分信息和客户端第二部分内容带来的自己的信息进行比对，最终确认该客户端就是经过了KDC认证的具有真实身份的客户端，是他可以提供服务的客户端。此时服务端返回一段使用CT_SK加密的表示接收请求的响应给客户端，在客户端收到请求之后，使用缓存在本地的CS_ST解密之后也确定了服务端的身份（其实服务端在通信的过程中还会使用数字证书证明自己身份）。
至此，第三次通信完成。此时也代表着整个kerberos认证的完成，通信的双方都确认了对方的身份，此时便可以放心的进行整个网络通信了。
|
至此整个认证流程就完毕了，后续就是利用票据实现维权的内容……
