Windows有两种认证协议：NTLM（NT LAN Manager）和Kerberos。
域成员计算机在登录的时候可以选择登录到域中或此台电脑，选择登录到域一般会采用Kerberos协议在域控DC上进行认证。
NTLM认证协议
NTLM是一种网络认证协议，它是基于挑战（Chalenge）/响应（Response）认证机制的一种认证模式。
这个协议只支持Windows，NTLM认证协议大概流程：
可以看到NTLM协议基于NTLM hash，Windows本地登录的密码由LM hash和NTLM hash组成,存储在SAM文件中,前一部分是LM Hash，后一部分是NTLM Hash。
administrator:500:6f08d7b306b1dad4ff17365faf1ffe89:032f3db689bf1ee44c04d08c785710de:::
在登录Windows的时候，系统会将用户输入的密码转换成NTLM hash并与SAM文件中的密码进行对比，如果相同，则认证成功。
Kerberos认证协议
Kerberos是一种网络认证协议，整个认证过程涉及到三方：客户端、服务端和 KDC（Key Distribution Center），在 Windows 域环境中，KDC 的角色由 DC（Domain Controller）来担当。
Kerberos基于票据(Ticket)进行安全认证，票据是用来在认证服务器和用户请求的服务之间传递用户身份的凭证。
以下是kerberos协议的认证流程：
-
KRB_AS_REQ：Client-A发送Authenticator（通过A密码加密的一个时间戳TimeStamp）向KDC的AS服务认证自己的身份；
-
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；
-
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
-
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；
-
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的伪造；
-
KRB_AP_REP：Server-B受到KRB_AP_REQ之后，利用自身密码解密ServiceTicket，得到SessionKeya-b，然后用SessionKeya-b解密Authenticator得到时间戳，验证A的身份。