NTLM认证协议及SSPI的NTLM实现

没错，NTLM就是微软应用最广泛的认证协议之一。 NTLM是NT LAN Manager的缩写，这也说明了协议的来源。NTLM 是 Windows NT 早期版本的标准安全协议。Windows 2000内置三种基本安全协议之一。 NTLM适用范围非常广，既可用于域内的认证服务，也可用于没有AD的环境，让两台独立电脑相互认证。

你可能知道NTLM可以认证用户身份，但是你可能不知道NTLM可以提供会话安全服务（NTLM Session security）。

本文也会分成几篇来写，现在计划可能包含下面几个大方面的内容：

1. NTLM协议的认证

包括 NTLMv1 和 NTLMv2 两个版本。涉及到NTLM的认证全过程，以及NTLM 的 EPA（Extended Protection for Authentication）实现。

2. NTLM Session Security

即NTLM的会话安全，或者说是NTLM的SSPI实现。这一部分内容可能不是很常用，能找到的资料也比较少。这里先简单的说两句。我们都知道NTLM可以用于认证，实际上，认证过后，NTLM还能提供安全服务。比如提供对后续通信的安全签名，防篡改，或者对后续通信进行安全可信赖加密，防止被窃听。这一部分实际上是微软SSPI服务内容。 SSPI是Security Support Provider Interface（Microsoft安全支持提供器接口）。 SSPI是一个安全框架，很多协议都对它有实现。比如我们熟知的Kerberos认证协议，它也有SSPI实现的部分。

3. NTLM消息的实例

这一部分，我们会找一个具体的实例来解释认证的全过程。

值得注意的是 NTLM 现在已经不光用于windows平台了，Linux 或者 java 平台也可以进行 NTLM 认证，使用 NTLM 的安全服务（但是Java平台对NTLM的会话安全支持貌似有问题）。

作为一个开始，我们先来介绍几个基础概念，概念清楚了，然后再看技术细节。

1. 什么是认证。

认证就是承认和证明的意思。就是你能证明你的身份。比如你要访问一个受保护的资源，服务器需要认证你的身份。你可以声称你是系统管理员，但是怎么证明你就是管理员呢。方法很多，这里有个简单直接的方法就是证明你知道管理员的密码。

认证的问题转化为：怎么证明你知道你所声称的用户的密码？.

一个简单暴力的证明方法是，让你直接提供密码给服务器，然后服务器去数据库里面比对，看你提供的密码对不对。如果对，认证通过。否则失败。常见的所谓Windows Forms认证，或者叫做windows basic 认证就是这种方式。简单直接。但是密码需要在网络上传输，安全问题就不说了，你懂的。

怎样在不直接提供密码的情况下，间接证明你知道密码呢？ NTLM就是干这个的了。

什么是NTLM 认证。

NTLM是一种在不直接提供密码的情况下，间接证明客户端知道用户密码的方法。

NTLM认证最常见的应用场景恐怕就是用在浏览器（http协议）上的认证了。但是实际上，NTLM 只规定了认证的流程，和认证消息格式。并不跟具体的协议相关。所以跟http就更没有必然联系了。浏览器只是在http协议头上携带了NTLM的消息而已，通过了认证。我们知道http通常是明文的，所以如果直接传输密码非常不安全，NTLM就有效的防止了这个问题。

怎么理解这个问题呢，举个夸张点的例子，如果不嫌烦，客户端和服务端甚至可以通过传递小纸条的方式传递NTLM消息，来认证身份。而纸条的内容是明文的，中间传递者都可以随意查看，但是却无法知道密码，也无法伪造。

现在可以开始技术细节了，我们还是采取由大及小的方式。先从整体介绍，再逐步深入。

NTLM 的认证消息，及认证流程。

前面说过了，NTLM消息并不和任何传输协议绑定，它的认证消息理论上可以通过任何方式传递，所以我们的讨论都集中在协议本身，而不去关心下层的传输方式。

我们先看一个图：

NTLM认证共需要三个消息完成：

(1). Type1 消息。 Negotiate 协商消息。

客户端在发起认证时，首先向服务器发送协商消息。协商需要认证的主体，用户，机器以及需要使用的安全服务等等信息。并通知服务器自己支持的协议内容，加密等级等等。

(2). Type2 消息。 Challenge 挑战消息。

服务器在收到客户端的协商消息之后，会读取其中的内容，并从中选择出自己所能接受的服务内容，加密等级，安全服务等等。并生成一个随机数challenge, 然后生成challenge消息返回给客户端。

(3). Type3 消息。 Authenticate认证消息。

客户端在收到服务端发回的Challenge消息之后，读取熬服务端所支持的内容，和随机数challenge。决定服务端所支持的内容是否满足自己的要求。如果满足，则使用自己的密码以及服务器的随机数challenge通过复杂的运算，期间可能需要自己生成一个客户端随机数client challenge也加入运算，并最终生成一个认证消息。并发回给服务器。

(4). 服务器在收到 Type3的消息之后，回经过几乎同样的运算，并比较自己计算出的认证消息和服务端发回来的认证消息是否匹配。如果匹配，则证明客户端掌握了正确的密码，认证成功。允许客户端使用后续服务。如果不匹配，则认证失败。

NTLM 认证消息的结构.

NTLM的消息很简单，只有三种， Type1, Type2 和 Type3. 它们都有相似的结构。认证消息都是二进制的，但是通常我们见到的都是它们的Base64的编码格式。类似这种：

TlRMTVNTUAADAAAAGAAYAHAAAACSAJIAiAAAAAAAAAAAAAAAGgAaAEgAAAAOAA4AYgAAAAAAAAAAAAAABYKIogAAAAAAAAAPYQBkAG0AaQBuAGkAcwB0AHIAYQB0AG8AcgBOAEUASQBMAC0AUABDALZLpLeO2n6Sx1s9JjrAfQOqf2QsmfTeP9cjC86k7BsjZEsKzjOoYBcBAQAAAAAAAEDGE3IuR88Bqn9kLJn03j8AAAAAAgAEAEsAQQABAAoARgBTAFcARQBCAAQADABrAGEALgBjAG8AbQADABgAZgBzAHcAZQBiAC4AawBhAC4AYwBvAG0ABQAMAGsAYQAuAGMAbwBtAAcACAC0gtdyLkfPAQAAAAAAAAAA

所以，如果你看到这种形式不要吃惊，把他们用Base64解码即可。

协议中的数字都是采用小端的方式存储。

(1). 消息头

这三种消息都具有相似的消息头：

(2) Flags 标记。

这三种消息一般都会携带一个 4字节的int值，作为消息的Flags。 Flags在三种消息中的位置不一样，所以没有当做消息头来介绍。不过，这个flags非常重要。这里先单独来介绍：

（下面是我的代码片段，重点标志我做了注释，后面用到的时候会进一步介绍）


flagsExps[0x1] = "Unicode";
flagsExps[0x2] = "OEM";
flagsExps[0x4] = "Request Target";
flagsExps[0x8] = "r10(must be zero)";

flagsExps[0x10] = "Negotiate Sign"; // 需要协商签名服务
flagsExps[0x20] = "Negotiate Seal"; // 需要协商加密服务
flagsExps[0x40] = "Negotiate Datagram Style"; //UDP 非连接模式
flagsExps[0x80] = "Negotiate Lan Manager Key"; // 在某些特定的NTLMv1下使用 Lan manager key 后面会详细介绍

//================================
flagsExps[0x100] = "Negotiate Netware(r9 must be zero)";
flagsExps[0x200] = "Negotiate NTLM";
flagsExps[0x400] = "r8(should be zero)";
flagsExps[0x800] = "Negotiate Anonymous"; //使用匿名登录

flagsExps[0x1000] = "Negotiate Domain Supplied";
flagsExps[0x2000] = "Negotiate Workstation Supplied";
flagsExps[0x4000] = "Negotiate Local Call(r7)";
flagsExps[0x8000] = "Negotiate Always Sign";


//===============================
flagsExps[0x10000] = "Target Type is a Domain.";
flagsExps[0x20000] = "Target Type is a Server.";
flagsExps[0x40000] = "Target Type Share(r6)";
flagsExps[0x80000] = "Negotiate NTLM2 Key(EXTENDED_SESSIONSECURITY)"; //使用扩展会话安全

flagsExps[0x100000] = "Request Init Response(NTLMSSP_NEGOTIATE_IDENTIFY)";
flagsExps[0x200000] = "Request Accept Response(r5, must be zero)";
flagsExps[0x400000] = "Request Non-NT Session Key";
flagsExps[0x800000] = "Negotiate Target Info"; //协商 携带 TargetInfo

//===============================
flagsExps[0x1000000] = "r4(must be zero)";
flagsExps[0x2000000] = "NTLMSSP_NEGOTIATE_VERSION(协商携带操作系统版本号, 一般会忽略此项，仅供调试用途 )";
flagsExps[0x4000000] = "r3(must be zero)";
flagsExps[0x8000000] = "r2(must be zero)";

flagsExps[0x10000000] = "r1(must be zero)";
flagsExps[0x20000000] = "Negotiate 128"; // 协商128位加密
flagsExps[0x40000000] = "Negotiate Key Exchange"; //协商交换key， 在会话安全中，使用交换key来加密内容，而不是直接使用会话key
flagsExps[0x80000000] = "Negotiate 56"; //协商56位加密

(3). Type 1 消息

我这里使用下面参考文档2中的一个图来介绍：

a . 前面首先是 8个字节+4个字节的协议头。前面已经介绍过了。注意，消息类型为1

b . 然后是四个字节的Flags。前面也介绍过了。这个Flags中表达了客户端想要使用的NTLM的认证服务，以及客户端自己所支持的服务。

c. 然后，是若干个可选的security buffer。

注意上图中的 security buffer，安全缓冲区。它是一个8字节固定大小的结构体。它看起来像是这个样子：

它其实是一个缓冲区指针。它指向一个区域，这个区域相对于Type1消息起始的偏移量为 offset，这个区域的大小长度为 MaxLength, 其中的有效使用大小为：Length.

如果 Flags 中包含 0x1000 标记，则需要提供域。把域名写入到这个缓冲区中。字符集由Flags中的 OEM或者Unicode决定。

如果Flags中包含0x2000标记，则需要提供workstation的名字。方法同上。

d. 然后是8字节的操作系统版本号。

如果Flags中包含0x2000000，则需要提供操作系统的版本号。

操作系统版本号的写法，请参考参考文档1 的 2.2.2.10 节。

e. 然后，就是携带的前面security buffer中所指向的数据了。

在Type1的消息中，只有前面的 a 和 b项，是必须的，后面的都是可选的。

(4) Type2 消息

服务端在收到 Type1消息之后，会生成Type2消息返回给客户端。

这个也比较简单，我们还是用参考文档2 中的一个图来介绍：

a . 前面首先还是 8个字节+4个字节的协议头。前面已经介绍过了。注意此时的消息类型已经是 2了。

b . 然后是四个字节的Flags。前面也介绍过了。这个Flags中表达了服务端所能接受的服务。

c. 上图中的TargetName 是要访问的机器名。存储方法是security buffer. 前面介绍过了，不多说了。

d. Flags 不多说了。

e. Challenge, 这是一个服务端生成的8字节的随机数，客户端会用来计算key. 后面会详细介绍用法。

f. Context, 这是一个8字节的值，其实是两个连续的32位值。表示一个内部handle。当服务端发现客户端就是自身的时候（在用一台电脑上），就会生成一个内部的安全handle，填充到这个字段。并且在Flags中设置 0x4000标记。表示这是一个本地认证。

g. TargetInformation 也是一个security buffer。其存储方式前面介绍过。但是它的buffer中的内容需要介绍一下。基本上，TargetInformation是由一系列连续的 AV_PAIR 结构体连接起来的。

而AV_PAIR的结构如下：

（请参考下面参考文档1 的 2.2.2.1节）

i) 先是两个字节的int16值，表示 id，表示这个AV结构的类型。

目前有如下类型：

ii) 然后是两个字节的int16值，表示值的长度。

iii) 然后就是值。它的长度在上面指定的。

这个TargetInformation 结构非常重要。后面Type3中还会用到。

h. 然后是8字节的操作系统版本号。 Type1中已经介绍过了。不多说了。

然后后面就是要携带的数据了。

到这里先告一段落吧，这里介绍了 NTLM 的概念以及认证流程。并详细介绍了Type1和Type2消息，以及Flags每个标志位的意义。这大概覆盖了NTLM内容的30%左右的内容。 Type3消息是整个认证中最为复杂和关键的部分，我们将在下一篇中独立介绍。

希望大家多多支持。

欢迎访问我的个人独立博客： http://byNeil.com , 希望和大家多多交流共同进步。

参考文档：