NTLM 工作原理概述

NTLM 工作原理概述

1. 为何采用NTLM

微软采用 Kerberos 作为 Windows 2000及之后的活动目录域的默认认证协议。当某个服务器隶属于一个Windows 服务器域或者通过某种方式（如Linux到Windows AD的认证）与Windows 服务器域建立了信任关系的时候，通常采用Kerberos作为认证协议。但是无论你是否拥有活动目录域，NTLM都可以被采用。

2. NTLM仍然使用在以下场景

（1） 客户端使用 IP 地址向服务器认证
（2） 客户端向另一个有 Legacy NTLM 信任而非传递性林间信任的活动目录域林的服务器认证
（3） 客户端向一个未加入域的服务器认证
（4）未使用活动目录的场景（通常指 ‘工作组’ 或 ‘对等网络’）
（5） 防火墙策略限制了 Kerberos 使用的端口（通常为 TCP port 88）

3. NTLM 工作过程简介

以下步骤刻画了 NTLM 非交互式认证过程， 第一步中提供了用户的 NTLM 认证信息，该步是用户交互式认证（Logon）过程的一部分。
（1） （交互式登录到某客户机）用户使用：域名、用户名、密码，登陆到某台客户端。客户端计算并存储用户密码的加密散列值（Hash），然后将真实的密码丢掉（即不保存用户真实的密码）
（2） 客户端将用户名以纯文本的方式发送到要访问的服务器
（3） 服务器产生一个 16 字节的随机数并将该随机数发送给客户端，该随机数通常称为：挑战（Challenge）
（4） 客户端使用用户密码的散列值加密服务器发送过来的 Challenge，并将结果发回给服务器， 该步骤通常称为：应答 （Response）
（5） 服务器将下面三项内容发送到域控制器 （Domain Controller）

a. 用户名
b. 发送给客户端的 Challenge
c. 从客户端收到的 Response

（6） 域控制器使用 用户名 从安全账号管理数据库 （Security Account Manager database）中获得用户密码的散列值， 并使用获得的密码散列值来加密 Challenge
（7） 域控制器比较步骤（6）中计算得到的加密后的 Challenge值与步骤（4）中客户端加密得到的 Response，如果两者一致，则认证通过

你的应用程序不应该直接访问 NTLM 安全软件包（security package），而应该使用 Negotiate（协商） 安全软件包。Negotiate 允许你的应用程序优先采用更高级的安全协议，如果这些高级的安全协议被认证过程中涉及的各个系统所支持的话。目前， Negotiate 安全包在 Kerberos 和 NTLM 间进行选择，它会先选择 Kerberos，除非涉及到的认证系统中有的部分不支持 Kerberos.

4. 从状态码看 NTLM 工作流程

不同于 Kerberos 认证，在 Windows NT 挑战/应答 （Windows NT Challenge/Response， NTCR）协议中，服务器会给 HTTP 客户端发送随机的 Challenge, 客户端会给服务器发送对应的 Response. 通过这种方式，客户端的密码无需在网络上进行传递。使用 NTCR 协议认证的流程如下：

• 典型的，客户端先发起匿名请求。当匿名请求被拒绝后，IIS Server 会返回 401.2 错误 和 WWW-Authenticate 认证头给客户端。
• 如果客户端不支持 Kerberos 或 Kerberos 认证失败，Negotiate NTLM 头会发起 NTCR 认证。客户端会关闭原有的 TCP 连接， 重新开启一个新的连接发送和之前一样的请求，只是请求头部中附加了 Authorization: NTLM 相关的头。该头部的值里面还包括了 Base64编码后的 用户名、主机名、域名等相关代表用户身份的信息。这串文本信息会被传递给 Windows 安全支持提供者接口(Windows Security Support Provider Interface, SSPI)，用来产生随机的 Challenge. 如果用户账户不是 IIS Server 本地账号的话， 这串数据会被传送给相关的域控制器，后者会生成相关的 Challenge.
• IIS Server 返回错误码 401.1 并发送Challenge 给客户端
  
• 客户端使用其密码哈希值和所得到的 Challenge 经过运算产生另一个哈希值 Response。客户端再次发起请求到 IIS Server，并在 Authorization： NTLM 头部把编码后的 Response 发回去。
  
• 服务器收到 Response，并使用本地的安全提供者或相应的域控制器来对 Chanllenge 运算重新产生 Response， 然后将计算得到的 Response与收到的Response对比。如果二者相同，则认证成功。

5.从Fiddler抓包看 NTLM 工作流程

在下面的实验场景中， IIS 被配置成只支持 NTLM 协议。在 IIS 6.0 及更早的版本中，可以将元数据中 NTAuthenticationProviders 设置成 "NTLM"。在 7.0及以后的版本中，NTLM 协议必须被列在 部分作为一个提供者。

IE 打开新连接发起的第一个请求中不包含任何认证相关的信息。

如果没有将 IIS 服务器配置成支持匿名认证的话，服务器将会返回 401.2 状态来告诉客户端它还没有认证。同时服务器会在响应中把他自身支持的认证协议告诉客户端。在仅支持 NTLM 认证的情况下， IIS 服务器返回给客户端的响应头如下：

同时 IIS 回写类似下面的一条消息到 IIS 的日志中：

当客户端收到服务器的响应，得知其支持 NTLM 认证协议后。客户端会关闭连接，在一个新打开的连接中重新发送原来的请求，并把认证信息包含在 Authorization 头中：

作为 NTLM 交互的一部分， 现在服务器已经知道客户端给它发来了认证信息。但是，服务器还需要客户端给它进一步发送更多的信息，因此服务器回复了类似下面的响应：

IIS 服务器然后在其自己的日志文件中写入类似下面的一条记录：

IIS 服务器发送 401.1 状态来告诉客户端，客户端必须提供剩下的有效的认证信息。客户端收到这串响应中的 Challenge 后，客户端会再次发起一次类似下面的请求，把 Response 发送给服务器：

当 IIS 服务器收到该请求后， IIS 服务器会联系相关的域控制器来完成认证。当客户端的请求被认证通过后， IIS 就把客户端所请求的页面发送给它，返回的响应头如下：

响应发送后，IIS 会在其日志文件中记录如下的日志：

参考文献：

http://en.wikipedia.org/wiki/NTLM
http://msdn.microsoft.com/en‐us/library/windows/desktop/aa378749﴾v=vs.85﴿.aspx
http://msdn.microsoft.com/en‐us/library/bb643328.aspx
http://msdn.microsoft.com/en‐us/library/bb643328.aspx