Windows认证协议

Windows有两种认证协议：NTLM（NT LAN Manager）和Kerberos。

域成员计算机在登录的时候可以选择登录到域中或此台电脑，选择登录到域一般会采用Kerberos协议在域控DC上进行认证。登录本地采用NTLM认证。

1、NTLM认证协议

基于挑战（Chalenge）/响应（Response）认证机制的一种认证模式。

NTLM协议基于NTLM hash，windows本地登陆的密码由LM hash和NTLM hash组成，存储在SAM文件中，前一部分是LM Hash，后一部分是NTLM Hash。

administrator:500:6f08d7b306b1dad4ff17365faf1ffe89:032f3db689bf1ee44c04d08c785710de:::

在登陆Windows的时候，系统会将用户输入的密码转换成NTLM hash并与SAM文件中的密码进行对比，如果相同，则认证成功。

C:\Windows\System32\config\SAM

将密码交给lsass进程产生NTLM hash：

明文->hex编码->Unicode编码->MD4

2、Kerberos认证协议

整个认证过程涉及到三方：客户端、服务端和 KDC（Key Distribution Center -域控上的一个服务），在 Windows 域环境中，KDC 的角色由 DC（Domain Controller）来担当。

Kerberos基于票据(Ticket)进行安全认证，票据是用来在认证服务器和用户请求的服务之间传递用户身份的凭证。

kerberos协议的认证流程：

第1步：KRB_AS_REQ：Client-A发送Authenticator（通过A密码加密的一个时间戳TimeStamp）向KDC的AS服务认证自己的身份；

第2步：KRB_AS_REP：AS通过KDC数据库中存储的Client-A密码的副本，解密收到的Authenticator，如果解密出的TimeStamp符合要求，则AS服务认为Client-A就是所谓的Client-A； 认证成功后，AS服务生成一个短期有效的SessionKeya-kdc，将该Key使用A的密码副本加密成密文1，另外将Key连同时间戳标志（控制该SessionKey的有效时间）通过TGS服务的密码也就是KDC的密码加密为密文2（称为TGT），将这两个密文组合成KRB_AS_REP返回给Client-A；

第3步：KRB_TGS_REQ：Client-A在接收到KRB_AS_REP后，首先使用自身密码解密密文1得到SessionKeya-kdc，此时需要注意的是，密文2（TGT）是被KDC的密码加密的，所以Client-A无法解密，这也是Kerberos协议设计的精妙之处，既解决了Server端（TGS相对于Client-A也称之为Server端） 无法及时接收SessionKey的问题，又不怕Client-A对该TGT的伪造，因为Client-A不知道Server端的密码。得到SessionKeya-kdc后，Client-A利用其加密时间戳生成Authenticator用于向TGS申请Client-A与Client-B进行认证所需的SessionKeya-b，连同刚才KRB_AS_REP接收的TGT一同组合成    KRB_TGS_REQ发送给TGS

第4步：KRB_TGS_REP：TGS在接收到KRB_TGS_REP之后，利用KDC密码解密TGT获得本来就该发送给自己的SessionKeya-kdc，然后用其解密KRB_TGS_REQ中的Authenticator得到Client-A发送过来的时间戳，如果时间戳符合要求，则生成一个短期有效的SessionKeya-b，注意此时利用SessionKeya-kdc将SessionKeya-b加密为密文1，然后利用Server-B的密码将SessionKeya-b加密为密文2（称为ServiceTicket），两个密文一同构成KRB_TGS_REP返回给Client-A；

第5步：KRB_AP_REQ：Client-A在接收到KRB_TGS_REP之后，首先使用缓存的SessionKeya-kdc将密文1中的SessionKeya-b解密出来，然后利用其加密时间戳生成Authenticator用于向B进行对自身的验证，另外，和刚才TGT一样，密文2也就是ServiceTicket是用Server-B的密码加密的，所以Client-A无法解密，也就无法伪造，这也同样解决了在三方认证中作为Server端的B无法及时接收SessionKey的问题，又不怕Client-A对ServiceTicket的伪造；

第6步：KRB_AP_REP：Server-B受到KRB_AP_REQ之后，利用自身密码解密ServiceTicket，得到SessionKeya-b，然后用SessionKeya-b解密Authenticator得到时间戳，验证A的身份。

域认证所参与的角色（KDC上又细分的一些服务）：

AD(account database)：储存所有client的白名单，只有存在于白名单的client才能顺利申请到TGT
AS（Authentication Service）:为client生成TGT的服务
TGS(Ticket Granting Service)：为client生成某个服务的ticket。生成ST的地方

域认证流程——粗略流程：

client向kerberos服务（就是我们的域控上的一个服务）请求，希望获得访问server的权限。kerberos服务得到了这个消息，首先判断client是否是可信赖的（就是判断是否是此域内的机器），也就是白名单黑名单的说法。这就是AS服务完成的工作，通过在AD中存储黑名单和白名单来区分client。成功后AS返回TGT给客户端。(AS_REQ与AS_REP)。
client得到TGT后，继续向kerberos服务请求，希望获得访问server的权限。kerberos服务得到了这个消息，这时通过client消息中的TGT，判断出了client拥有这个权限，于是给了client访问服务端的权限并返回了ST。(TGS_REQ与TGS_REP)
client得到ST后，终于可以访问server。这个ST只是针对这个server，其他server需要向TGS申请。(AP_REQ与AP_REP) 

PAC
在黄金/白银票据的构造分析中，说了开启PAC可以防止白银票据的攻击。

那么PAC是什么呢？

黄金票据的构造原理：掌握KRBTGT用户密码之后可以通过签发一张高权限用户的TGT票据，再利用这个TGT向KDC获取域内服务的ticket来实现对域的控制。那么这里的“高权限用户”是通过什么来判断的呢，答案就是PAC。

PAC在我们域认证中出现的节点是在哪的呢？

主要是两个节点：

当我们的客户端第一次向KDC去请求TGT的时候，我们返回的TGT票据中就包含了PAC。(AS_REP)
就是最后我们的客户端拿着ST去与服务端通信的时候，如果一切验证顺利，那么最后我们的服务端就会将解密出来的PAC发送给KDC去进行认证，KDC解密PAC。获取Client的sid，以及所在的组，再根据该服务的ACL，判断Client是否有访问服务的权限。防止白银票据其实主要也是这一步。 (AP_REP)
总结：
kerberos认证流程的本质上就是不停交换密钥，然后采用对称加密算法验证时间戳和身份，来完成的一个安全认证。