NTLM本地认证

NTLM网络认证（工作组认证）

kerberos认证（域认证）

其中Kerberos认证与NTML认证都是属于网络认证，也可以将这个三种认证方式分为两大类，就是本地认证和网络认证，网络认证分为Kerberos认证和NTML认证。

NTLM是一种网络认证协议，它是基于挑战（Chalenge）/响应（Response）认证机制的一种认证模式。(这个协议只支持Windows) NTLM协议的认证共需要三个消息完成：协商 --> 挑战 --> 认证。

协商：主要用于确认双方协议版本、加密等级等

挑战：服务器在收到客户端的协商消息之后， 会读取其中的内容，并从中选择出自己所能接受的服务内容，加密等级，安全服务等等。并生成一个随机数challenge, 然后生成challenge消息返回给客户端。该消息就是挑战/响应认证机制的主要功能体现。

认证：验证主要是在挑战完成后，验证结果，是认证的最后一步。

NTLM v1与NTLM v2最显著的区别就是Challenge与加密算法不同，共同点就是加密的原料都是NTLM Hash。

Challage:NTLM v1的Challenge有8位，NTLM v2的Challenge为16位。

Net-NTLM Hash:NTLM v1的主要加密算法是DES，NTLM v2的主要加密算法是HMAC-MD5。

又叫NTML本地认证。

winlogon.exe：负责加载用户身份的安全组件，提供图形化的登陆页面

lsass.exe：本地安全认证子系统服务，负责用户本地认证验证或远程登陆验证用户身份

%systemRoot%\system32\config\sam：通过NTLM Hash算法，储存用户密码的文件

开机以后，系统会自动调用Windows Logon Process(winlogon.exe)程序，这个程序给我们提供了一个用户交互界面，也就是我们的登陆界面。

我们在用户交互页面输入密码并点击登陆后，系统将用户输入的密码传递给lsass.exe程序，该程序会将我们输入的密码进行NTML-Hash值得加密，然后lsass.exe程序会去读取系统中的SAM文件中已经存在的NTML-Hash的值，进行对比。

发现相同则认证成功，将user SID \ Group SID 发送给winlogon.exe程序，然后生成会话，进入桌面。

认证过程流程图如下：

又叫NTML网络认证

NTLM协议的认证共需要三个消息完成：协商、挑战、认证。也叫挑战响应机制

场景：网络认证即在工作组环境下远程登陆另一台电脑所采用的认证机制

双方确定使用的协议版本，NTML现在有V1 和V2 两个版本，具体的版本区别就是加密方式不同

挑战（Chalenge）/响应（Response）认证机制的核心

客户端向服务器端发送用户信息(用户名)请求

服务器接受到请求后，判断本地用户列表是否存在客户端发送的用户名，如果没有返回认证失败，如果有，生成一个16位的随机数，被称之为“Challenge”， 然后使用登录用户名对应的NTLM Hash加密Challenge(16位随机字符)， 生成Challenge1保存在内存中。同时，生成Challenge1后，将Challenge(16位随机字符)发送给客户端。

客户端接受到Challenge后，使用自己提供的账户的密码转换（加密）成对应的NTLM Hash，然后使用这个NTLM Hash加密Challenge生成Response，然后将Response发送至服务器端。（当客户端收到challenge后,用在第一步中存储的NTLM Hash对其加密，然后再将加密后的challenge发送给服务器，也就是response，表现形式是Net-NTLM Hash。）

服务端在收到response后，会向DC发送针对客户端的验证请求。该请求主要包含以下三方面的内容：客户端用户名、客户端NTLM Hash加密的Challenge、原始的Challenge。

当DC接到过来的这三个值的以后,会根据用户名到DC的账号数据库(ntds.dit)里面找到该用户名对应的NTLM Hash,然后把这个hash拿出来和传过来的challenge值进行比较,相同则认证成功,反之,则失败。

KDC: Key Distribution Center，密钥分发中心，负责管理票据、认证票据、分发票据，但是KDC不是一个独立的服务，它由AS和TGS组成。

AS: Authentication Service，验证服务，为client生成TGT的服务

TGS: Ticket Granting Service，票据授予服务，为client生成某个服务的ticket

TGT: Ticket Granting Ticket，入场券，通过入场券能够获得票据，是一种临时凭证的存在。

Ticket:票据，是网络中各对象之间互相访问的凭证

AD: Account Database，存储所有client的白名单，只有存在于白名单的client才能顺利申请到TGT。

DC: Domain Controller，域控 KRBTGT: 每个域控制器都有一个krbtgt账户，是KDC的服务账户，用来创建TGS加密的密钥。

Kerberos提供了一个集中式的认证方式,在整个认证过程中总共要涉及到三方:客户端,服务端和KDC, 在Windows域环境中,KDC的角色由DC来担任,Kerberos是一种基于票据的认证方式,票据(Ticket)是用来安全的在认证服务器和用户请求的服务之间传递用户的身份,同时也会传递一些附加信息,用来保证使用Ticket的用户必须是Ticket中指定的用户,Ticket一旦生成,在生存时间内可以被Client多次使用来申请同一个Server的服务。这里就存在一个票据窃取问题。

举个例子，就是我们去动物园游玩，我们到了这个动物园的门前，我们不知道这个门后面是不是动物园以免进去以后尴尬，动物园也怕我们是不是带了危险物品，是不是在逃的逃犯，这些动物园方面都要检查。所以此时我们就需要一个类似于中介的身份来证明我是一个正常的游客，证明门后面就是动物园。

所以整个kerberos认证流程可以简化描述如下： 客户端在访问每个想要访问的网络服务时，他需要携带一个专门 用于访问该服务并且能够证明自己身份的票据，当服务端收到了该票据他才能认定客户端身份正确，向客户端提供 服务。所以整个认证流程可简化为两大步：

在上述的流程中，其实还有一个问题，那就是

KDC怎么知道你（客户端）就是真正的客户端？凭什么给你发放服务授予票据（Ticket）呢？

我们以去动物园为例，售票处凭什么给你买票，你如果是一个逃犯怎么办？其实买票的过程我们可以分为两步第一步是你拿着身份证去验证，第二步身份验证通过了才会给你票。

描述：当我们去动物园买票的时候，售票处主要分为两个部分，一个部分是安检部分，来看你是不是逃犯、是否携带危险工具，如果符合，就给你贴一个安全的标签，证明你已经通过了安检，可以去买票。此时我们被贴上的标签就叫TGT。我们拿着TGT去购票，所购的票就是一个票据Ticket。我们拿着Ticket去访问动物园的过程就是我们通过认证的过程。

为了获得能够用来访问服务端服务的票据，客户端首先需要来到KDC获得服务授予票据（Ticket）。由于客户端是 第一次访问KDC，此时KDC也不确定该客户端的身份，所以第一次通信的目的为KDC认证客户端身份，确认客户端 是一个可靠且拥有访问KDC权限的客户端。

1、客户端用户向KDC以明文的方式发起请求。该次请求中携带了自己的用户名，主机IP，和当前时间戳；

2、KDC当中的AS（Authentication Server）接收请求（AS是KDC中专门用来认证客户端身份的认证服务器）后去 kerberos认证数据库中根据用户名查找是否存在该用户，此时只会查找是否有相同用户名的用户，并不会判断身份的可 靠性；

3、如果没有该用户名，认证失败，服务结束；如果存在该用户名，则AS认证中心便认为用户存在，此时便会返回响应给 客户端，其中包含两部分内容：

3.1、第一部分内容称为TGT，他叫做票据授予票据，客户端需要使用TGT去KDC中的TGS（票据授予中心）获取访问 网络服务所需的Ticket（服务授予票据），TGT中包含的内容有kerberos数据库中存在的该客户端的Name，IP，当前时 间戳，客户端即将访问的TGS的Name，TGT的有效时间以及一把用于客户端和TGS间进行通信的Session_key(CT_SK)。 整个TGT使用TGS密钥加密，客户端是解密不了的，由于密钥从没有在网络中传输过，所以也不存在密钥被劫持破解的情 况。

3.2第二部分内容是使用客户端密钥加密的一段内容，其中包括用于客户端和TGS间通信的Session_key(CT_SK),客 户端即将访问的TGS的Name以及TGT的有效时间，和一个当前时间戳。该部分内容使用客户端密钥加密，所以客户端在拿 到该部分内容时可以通过自己的密钥解密。如果是一个假的客户端，那么他是不会拥有真正客户端的密钥的，因为该密 钥也从没在网络中进行传输过。这也同时认证了客户端的身份，如果是假客户端会由于解密失败从而终端认证流程。 至此，第一次通信完成。

此时的客户端收到了来自KDC（其实是AS）的响应，并获取到了其中的两部分内容。此时客户端会用自己的密钥将 第二部分内容进行解密，分别获得时间戳，自己将要访问的TGS的信息，和用于与TGS通信时的密钥CT_SK。首先 他会根据时间戳判断该时间戳与自己发送请求时的时间之间的差值是否大于5分钟，如果大于五分钟则认为该AS是 伪造的，认证至此失败。如果时间戳合理，客户端便准备向TGS发起请求。

客户端行为：

1、客户端使用CT_SK加密将自己的客户端信息发送给KDC，其中包括客户端名，IP，时间戳；

2、客户端将自己想要访问的Server服务以明文的方式发送给KDC；

3、客户端将使用TGS密钥加密的TGT也原封不动的也携带给KDC；

TGS行为：

1、此时KDC中的TGS（票据授予服务器）收到了来自客户端的请求。他首先根据客户端明文传输过来的Server服务IP查 看当前kerberos系统中是否存在可以被用户访问的该服务。如果不存在，认证失败结束。如果存在，继续接下来的认 证。

2、TGS使用自己的密钥将TGT中的内容进行解密，此时他看到了经过AS认证过后并记录的用户信息，一把Session_KEY即 CT_SK，还有时间戳信息，他会现根据时间戳判断此次通信是否真是可靠有无超出时延。

3、如果时延正常，则TGS会使用CT_SK对客户端的第一部分内容进行解密（使用CT_SK加密的客户端信息），取出其中的 用户信息和TGT中的用户信息进行比对，如果全部相同则认为客户端身份正确，方可继续进行下一步。

4、此时KDC将返回响应给客户端，响应内容包括：

第一部分：用于客户端访问网络服务的使用Server密码加密的ST（Servre Ticket），其中包括客户端的Name， IP，需要访问的网络服务的地址Server IP，ST的有效时间，时间戳以及用于客户端和服务端之间通信CS_SK（Session Key）。

第二部分：使用CT_SK加密的内容，其中包括CS_SK和时间戳，还有ST的有效时间。由于在第一次通信的过程中，AS 已将CT_SK通过客户端密码加密交给了客户端，且客户端解密并缓存了CT_SK，所以该部分内容在客户端接收到时是可以 自己解密的。 至此，第二次通信完成。

此时的客户端收到了来自KDC（TGS）的响应，并使用缓存在本地的CT_SK解密了第二部分内容（第一部分内容中 的ST是由Server密码加密的，客户端无法解密），检查时间戳无误后取出其中的CS_SK准备向服务端发起最后的请 求。

客户端：

1、客户端使用CS_SK将自己的主机信息和时间戳进行加密作为交给服务端的第一部分内容，然后将ST（服务授予票据） 作为第二部分内容都发送给服务端。

服务端：

1、服务器此时收到了来自客户端的请求，他会使用自己的密钥，即Server密钥将客户端第二部分内容进行解密，核对时 间戳之后将其中的CS_SK取出，使用CS_SK将客户端发来的第一部分内容进行解密，从而获得经过TGS认证过后的客户端 信息，此时他将这部分信息和客户端第二部分内容带来的自己的信息进行比对，最终确认该客户端就是经过了KDC认证的 具有真实身份的客户端，是他可以提供服务的客户端。此时服务端返回一段使用CT_SK加密的表示接收请求的响应给客户 端，在客户端收到请求之后，使用缓存在本地的CS_ST解密之后也确定了服务端的身份（其实服务端在通信的过程中还会 使用数字证书证明自己身份）。

至此，第三次通信完成。此时也代表着整个kerberos认证的完成，通信的双方都确认了对方的身份，此时便可以放心的 进行整个网络通信了