Windows中的认证体系

在这之前，我们先了解几个基本的概念

SSPI (Security Service Provider Interface 或 Security Support Provider Interface) 安全服务提供接口，这是 Windows 定义的一套接口，该接口定义了与安全有关的功能函数，包含但不限于：

身份验证机制
为其他协议提供的 Session security 机制。Session Security 指的是会话安全，即为通讯提供数据完整性校验以及数据的加、解密功能

SSP (Security Service Provider) 安全服务提供，SSPI 的实现者，微软自己实现了如下的 SSP，用于提供安全功能：

NTLM SSP
Kerberos
Cred SSP
Digest SSP
Negotiate SSP

因为 SSPI 中定义了与 Session security 有关的 API。所以，基本上层应用利用任何 SSP 与远程的服务进行了身份验证后，此 SSP 都会为本次连接生成一个随机 key。这个 key 往往被称为 Session key。上层应用在经过身份验证后，可以选择性地使用这个 key 来对之后发往服务端或接收自服务端的数据进行签名或加密。

不同的 SSP，实现的身份验证机制是不一样的。比如 NTLM SSP 实现的就是一种 Challenge based 身份验证机制。而 Kerberos 实现的就是基于 Ticket 的身份验证机制。我们可以编写自己的 SSP，然后注册到操作系统中，让操作系统支持更多的自定义的身份验证方法。

Windows认证方式

Windows系统有几种认证体系：Kerberos、NTLM 和 LM。

LM(LAN Manager) 是windows最早期的认证方式，它是如此简单以至于很容易就被破解。

于是，微软提出了Windows NT 挑战/响应验证机制，称之为NTLM(NT LAN Manager)，即NT LAN管理器，NTLM是windows早期的安全协议，因向后兼容性而保留了下来。NTLM适用范围非常广，既可用于域内的认证服务，也可用于没有域的工作组环境，让两台独立电脑相互认证。

现在已经有了更新的 NTLMv2 以及 Kerberos 验证体系。

在Win2000之前，Windows主要采用NTLM认证协议。从Win2000开始，在环境允许的条件下，首选认证协议为 Kerboros。Kerberos较之NTLM更高效、更安全，同时认证过程也相对复杂。NTLM采用一种质询/应答（Challenge/Response）消息交换模式。而Kerberos认证过程涉及到三方：客户端、服务端和 KDC（Key Distribution Center）。在Windows域环境中，KDC的角色由DC域控（Domain Controller）来担当。

NTLM的认证方式(域环境中)

用户通过输入Windows帐号和密码登录客户端主机，客户端会缓存密码的哈希值NTLM-Hash。成功登录客户端Windows的用户如果试图访问服务器资源，需要向对方发送一个请求，该请求利用 NTLM SSP 生成 NTLM_NEGOTIATE 消息（被称为 TYPE 1 消息），并将 TYPE 1 消息发送给服务端中，该TYPE 1消息中包含一个以明文表示的用户名。
服务端接收到客户端发送过来的 TYPE 1 消息，传入 NTLM SSP，得到 NTLM_CHALLENGE 消息（被称为 TYPE 2 消息），并将此TYPE 2消息发回给客户端。此TYPE 2消息中包含了一个由服务端生成的16位随机值，此随机值被称为 Challenge，服务器将该Challenge保存起来。
客户端收到服务端返回的 TYPE 2 消息，并取出其中的随机值Challenge后，用缓存的密码的哈希值NTLM-Hash对其进行加密，得到 Net NTLM-Hash(加密后的Challenge)，并且将Net NTLM-Hash封装到 NTLM_AUTH 消息中（被称为 TYPE 3 消息），发往服务端
服务器接收到客户端发送来的NTLM_AUTH的TYPE 3消息后，取出其中的Net NTLM-Hash值，并向DC域控（Domain Control）发送针对客户端的验证请求。该请求主要包含以下三方面的内容：客户端用户名、原始的Challenge 和加密后的Challenge(也就是Net NTLM-Hash)。
DC根据用户名获取该帐号的密码哈希值NTLM-Hash，用密码哈希值NTLM-Hash对原始的Challenge进行加密得到Net NTLM-Hash。如果加密后的Challenge和服务器发送的一致，则意味着用户拥有正确的密码，验证通过，否则验证失败。DC将验证结果发给服务器。
服务器根据DC返回的结果，对客户端进行认证。

Kerberos认证方式

Kerberos实际上是一种基于票据（Ticket）的认证方式。客户端要访问服务器的资源，需要首先购买服务端认可的ST服务票据。也就是说，客户端在访问服务器之前需要预先买好票，等待服务验票之后才能入场。在这之前，客户端需要先买票，但是这张票不能直接购买，需要一张TGT认购权证（Ticket Granting Ticket)。也就是说，客户端在买票之前必须先获得一张TGT认购权证。这张认购权证和服务票据均有KDC发售。

如何获得认购权证？

首先，我们来看看客户端如何获得 TGT认购权证。TGT是KDC的KAS认证服务（Kerberos Authentication Service）发放的。

1、当某个用户通过输入域帐号和密码试图登录某台主机的时候，本机的Kerberos服务会向KDC的认证服务发送一个认证请求。该请求主要包括两部分内容，明文形式的用户名和用用户秘钥加密后的的Authenticator(Authenticator是服务端可以用于验证客户端身份的一个东西)。

2、当KDC接收到请求之后，通过AD获取该用户的信息。通过获取的密码信息对Authenticator进行解密得到原始的 Authenticator。如果解密后的Authenticator和已知的Authenticator一致，则证明请求者提供的密码正确，即确定了登录者的真实身份。KAS成功认证对方的身份之后，会先生成一个用用户密码加密后的用于确保该用户和KDC之间通信安全的Logon Session Key会话秘钥。KAS接着为该用户创建 TGT认购权证。TGT主要包含两方面的内容：用户相关信息和原始Logon Session Key，而整个TGT则通过KDC自己的密钥进行加密。最终，被不同密钥加密的Logon Session Key 和 TGT返回给客户端。

如何获得ST服务票据？

经过上面的步骤，客户端获取了进入同域中其他主机入场券的 TGT认购权证和 Logon Session Key，然后用自己的密钥解密Logon Session Key得到原始的Logon Session Key。然后它会在本地缓存此 TGT 和原始Logon Session Key。如果现在它需要访问某台服务器的资源，它就需要凭借这张TGT向KDC购买相应的入场券。这里的入场券也有一个专有的名称——ST服务票据（Service Ticket）。具体来说，ST是通过KDC的另一个服务TGS（Ticket Granting Service）出售的。

3、客户端先向TGS发送一个ST购买请求，该请求主要包含如下的内容：客户端用户名、通过Logon Session Key加密的Authenticator、TGT和访问的服务器名(其实是服务)。

4.、TGS接收到请求之后，通过自己的秘钥解密TGT并得到原始Logon Session Key，然后通过Logon Session Key解密Authenticator，进而验证了对方的真实身份。TGS完成对客户端的认证之后，会生成一个用Logon Session Key加密后的用于确保客户端-服务器之间通信安全的Service Session Key会话秘钥。然后为该客户端生成ST服务票据。ST服务票据主要包含两方面的内容：客户端用户信息和原始Service Session Key，整个ST通过服务器密码派生的秘钥进行加密。最终两个被加密的Service Session Key和ST回复给客户端。

如何用ST服务票据双向认证？

5、客户端接收到TGS回复后，通过缓存的Logon Session Key解密得到原始Service Session Key，同时它也得到了进入服务器ST服务票据。该Serivce Session Key和ST服务票据会被客户端缓存。客户端访问某服务器资源，将ST服务票据和Service Session Key加密的Authenticator发送给服务端。

6、服务器收到客户端发来的ST服务票据。但是，服务端如何确保客户端发来的ST服务票据是通过TGS购买，而不是自己伪造的呢？这很好办，不要忘了ST是通过服务器自己密码派生的秘钥进行加密的。具体的操作过程是这样的，服务器在接收到请求之后，先通过自己密码派生的秘钥解密ST，并从中提取Service Session Key。然后通过提取出来的Service Session Key解密Authenticator，进而验证了客户端的真实身份。实际上，到目前为止，服务端已经完成了对客户端的验证，但是，整个认证过程还没有结束。谈到认证，很多人都认为只是服务器对客户端的认证，实际上在大部分场合，我们需要的是双向验证（Mutual Authentication）——访问者和被访问者互相验证对方的身份。现在服务器已经可以确保客户端是它所声称的那么用户，客户端还没有确认它所访问的不是一个钓鱼服务呢。为了解决客户端对服务器的验证，服务端需要将解密后的Authenticator再次用Service Session Key进行加密，并发挥给客户端。客户端再用缓存的Service Session Key进行解密，如果和之前的内容完全一样，则可以证明自己正在访问的服务器和自己拥有相同的Service Session Key。

参考文章：http://www.cnblogs.com/artech/archive/2011/01/25/NTLM.html

http://www.cnblogs.com/artech/archive/2011/01/24/kerberos.html