Windows域认证简介

Windows域认证简介
1.Kerberos认证
Windows认证协议有两种NTLM（NT LAN Manager）和Kerberos，前者主要应用于用于Windows NT 和Windows 2000 Server（or Later）工作组环境，而后者则主要应用于Windows 2000 Server（or Later）域（Domain）环境。

Kerberos较之NTLM更高效、更安全，同时认证过程也相对复杂。

Kerberos这个名字来源于希腊神话，是冥界守护神兽的名字。

Kerberos是一个三头怪兽，之所以用它来命名一种完全认证协议，是因为整个认证过程涉及到三方：客户端、服务端和KDC（Key Distribution Center）。

在Windows域环境中，KDC 的角色由DC（Domain Controller）来担当。

Kerberos实际上是一种基于票据（Ticket）的认证方式。

客户端要访问服务器的资源，需要首先购买服务端认可的票据。

也就是说，客户端在访问服务器之前需要预先买好票，等待服务验票之后才能入场。

在这之前，客户端需要先买票，但是这张票不能直接购买，需要一张认购权证。

客户端在买票之前需要预先获得一张认购权证。

这张认购权证和进入服务器的入场券均有KDC发售。

步骤一、二，如何获得“认购权证”
首先，我们来看看客户端如何获得“认购权证”。

这里的认购权证有个专有的名称——TGT（Ticket Granting Ticket），而TGT的是KDC一个重要的服务——认证服务（KAS：Kerberos Authentication Service）。

当某个用户通过输入域帐号和密码试图登录某台主机的时候，本机的Kerberos服务会向KDC的认证服务发送一个认证请求。

该请求主要包括两部分内容，明文形式的用户名和经过加密的用于证明访问者身份的Authenticator（Authenticator 在这里可以理解为仅限于验证双方预先知晓的内容，相当于联络暗号）。

当KDC接收到请求之后，通过AD获取该用户的信息。

通过获取的密码信息生成一个秘钥对Authenticator进行解密。

如果解密后的内容和已知的内容一致，则证明请求着提供的密码正确，即确定了登录者的真实身份。

KAS成功认证对方的身份之后，会先生成一个用于确保该用户和KDC之间通信安全的会话秘钥——Logon Session Key，并采用该用户密码派生的秘钥进行加密。

KAS接着为该用户创建“认购权证”——TGT。

TGT主要包含两方面的内容：用户相关信息和Logon Session Key，而整个TGT则通过KDC自己的密钥进行加密。

最终，被不同密钥加密的Logon Session Key和TGT返回给客户端。

步骤三、四，如何通过“认购权证”购买“入场券”？
经过上面的步骤，客户端获取了购买进入同域中其他主机入场券的“认购凭证”——TGT，以及Logon Session Key，它会在本地缓存此TGT和Logon Session Key。

如果现在它需要访问某台服务器的资源，它就需要凭借这张TGT向KDC购买相应的入场券。

这里的入场券也有一个专有的名称——服务票据（ST：Service Ticket）。

具体来说，ST是通过KDC的另一个服务TGS（Ticket Granting Service）出售的。

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

TGS接收到请求之后，现通过自己的密钥解密TGT并获取Logon Session Key，然后通过Logon Session Key解密Authenticator，进而验证了对方的真实身份。

TGS 存在的一个根本的目有两点：其一是避免让用户的密码客户端和KDC之间频繁传输而被窃取。

其二是因为密码属于Long Term Key（我们一般不会频繁的更新自己的密码），让它作为加密密钥的安全系数肯定小于一个频繁变换得密钥（Short Term Key）。

而这个Short Term Key就是Logon Session Key，它确保了客户端和KDC之间的通信安全。

TGS完成对客户端的认证之后，会生成一个用于确保客户端-服务器之间通信安全的会话秘钥——Service Session Key，该会话秘钥通过Logon Session Key进行加密。

然后出售给客户端需要的入场券——ST。

ST主要包含两方面的内容：客户端用户信息和Service Session Key，整个ST通过服务器密码派生的秘钥进行加密。

最终两个被加密的Service Session Key 和ST回复给客户端。

步骤五、六，凭票入场
客户端接收到TGS回复后，通过缓存的Logon Session Key解密获取Service Session Key。

同时它也得到了进入服务器的入场券——ST。

那么它在进行服务访问的时候就可以借助这张ST凭票入场了。

该Serivce Session Key和ST会被客户端缓存。

但是，服务端在接收到ST之后，如何确保它是通过TGS购买，而不是自己伪造的呢？这很好办，不要忘了ST是通过自己密码派生的秘钥进行加密的。

具体的操作过程是这样的，除了ST之外，服务请求还附加一份通过Service Session Key加密的Authenticator。

服务器在接收到请求之后，先通过自己密码派生的秘钥解密ST，并从中提取Service Session Key。

然后通过提取出来的Service Session Key解密Authenticator，进而验证了客户端的真实身份。

实际上，到目前为止，服务端已经完成了对客户端的验证，但是，整个认证过程还没有结束。

谈到认证，很多人都认为只是服务器对客户端的认证，实际上在大部分场合，我们需要的是双向验证（Mutual Authentication）——访问者和被访问者互相验证对方的身份。

现在服务器已经可以确保客户端是它所声称的那么用户，客户端还没有确认它所访问的不是一个钓鱼服务呢。

为了解决客户端对服务器的验证，服务要需要将解密后的Authenticator再次用Service Session Key进行加密，并发挥给客户端。

客户端再用缓存的Service Session Key进行解密，如果和之前的内容完全一样，则可以证明自己正在访问的服务器和自己拥有相同的Service Session Key，而这个会话秘钥不为外人知晓。

2.NTLM认证
NTLM使用在Windows NT和Windows 2000 Server工作组环境中（Kerberos用在域模式下）。

在AD域环境中，如果需要认证Windows NT系统，也必须采用NTLM。

较之Kerberos，基于NTLM的认证过程要简单很多。

NTLM采用一种质询/应答（Challenge /Response）消息交换模式。

●步骤一
用户通过输入Windows帐号和密码登录客户端主机。

在登录之前，客户端会缓存输入密码的哈希值，原始密码会被丢弃（“原始密码在任何情况下都不能被缓存”，这是一条基本的安全准则）。

成功登录客户端Windows的用户如果试图访问服务器资源，需要向对方发送一个请求。

该请求中包含一个以明文表示的用户名。

●步骤二
服务器接收到请求后，生成一个16位的随机数。

这个随机数被称为Challenge或者Nonce。

服务器在将该Challenge发送给客户端之前，该Challenge会先被保存起来。

Challenge 是以明文的形式发送的。

●步骤三
客户端在接收到服务器发回的Challenge后，用在步骤一中保存的密码哈希值对其加密，然后再将加密后的Challenge发送给服务器。

●步骤四
服务器接收到客户端发送回来的加密后的Challenge后，会向DC（Domain）发送针对客户端的验证请求。

该请求主要包含以下三方面的内容：客户端用户名；客户端密码哈希值加密的Challenge和原始的Challenge。

●步骤五、六
DC根据用户名获取该帐号的密码哈希值，对原始的Challenge进行加密。

如果加密后的Challenge和服务器发送的一致，则意味着用户拥有正确的密码，验证通过，否则验证失败。

DC将验证结果发给服务器，并最终反馈给客户端。