# NTLM认证协议与SSP(附录B).md

## NTLM认证协议与SSP（附录B）

## 附录B：NTLM的应用协议用法

本节研究了Microsoft的某些网络协议实现中NTLM身份验证的使用。

### NTLM HTTP身份验证

Microsoft已经为HTTP建立了专有的" NTLM"身份验证方案，以向IIS Web服务器提供集成身份验证。此身份验证机制允许客户端使用其Windows凭据访问资源，通常用于公司环境中，以向Intranet站点提供单点登录功能。从历史上看，Internet Explorer仅支持NTLM身份验证。但是，最近，已经向其他各种用户代理添加了支持。

NTLM HTTP身份验证机制的工作方式如下：

1. 客户端从服务器请求受保护的资源：

    GET /index.html HTTP / 1.1
2. 服务器以401状态响应，指示客户端必须进行身份验证。通过" WWW-Authenticate "标头将" NTLM"表示为受支持的身份验证机制。通常，服务器此时会关闭连接： HTTP / 1.1 401未经授权的 WWW身份验证：NTLM 连接：关闭 请注意，如果Internet Explorer是第一个提供的机制，它将仅选择NTLM。这与RFC 2616不一致，RFC 2616指出客户端必须选择支持最强的身份验证方案。
3. 客户端使用包含Type 1消息参数的" Authorization "标头重新提交请求。Type 1消息经过Base-64编码以进行传输。从这一点开始，连接保持打开状态。关闭连接需要重新验证后续请求。这意味着服务器和客户端必须通过HTTP 1.0样式的" Keep-Alive"标头或HTTP 1.1（默认情况下采用持久连接）来支持持久连接。相关的请求标头显示如下（下面的" Authorization "标头中的换行符仅用于显示目的，在实际消息中不存在）： GET /index.html HTTP / 1.1 授权：NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1 JLU1RBVElPTkRPTUFJTg ==
4. 服务器以401状态答复，该状态在" WWW-Authenticate "标头中包含Type 2消息（再次，以Base-64编码）。如下所示（" WWW-Authenticate "标头中的换行符仅出于编辑目的，在实际标头中不存在）。

    HTTP / 1.1 401未授权

    WWW验证：NTLM TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8 

    AAAAAAAAAAGIAYgA8AAAARABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTA 

    EUAUgBWAEUAUgAEABQAZABvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHI 

    ALgBkAG8AbQBhAGkAbgAuAGMAbwBtAAAAAAA =
5. 客户端通过使用包含包含Base-64编码的Type 3消息的" Authorization "标头重新提交请求来响应Type 2消息（同样，下面的" Authorization "标头中的换行符仅用于显示目的）：

    GET /index.html HTTP / 1.1 

    授权：NTLM TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAA 

    AACAAIAEwAAAAWABYAVAAAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIA 

    VwBPAFIASwBTAFQAQQBUAEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0 + d8ViWpjB 

    wx6BhHRmspst9GgPOZWPuMITqcxg ==
6. 最后，服务器验证客户端的Type 3消息中的响应，并允许访问资源。

    HTTP / 1.1 200 OK

此方案与大多数"常规" HTTP身份验证机制不同，因为通过身份验证的连接发出的后续请求本身不会被身份验证；NTLM是面向连接的，而不是面向请求的。因此，对" /index.html " 的第二个请求将不携带任何身份验证信息，并且服务器将不请求任何身份验证信息。如果服务器检测到与客户端的连接已断开，则对" /index.html " 的请求将导致服务器重新启动NTLM握手。

上面的一个显着例外是客户端在提交POST请求时的行为（通常在客户端向服务器发送表单数据时使用）。如果客户端确定服务器不是本地主机，则客户端将通过活动连接启动POST请求的重新认证。客户端将首先提交一个空的POST请求，并在" Authorization "标头中带有Type 1消息。服务器以Type 2消息作为响应（如上所示，在" WWW-Authenticate "标头中）。然后，客户端使用Type 3消息重新提交POST，并随请求发送表单数据。

NTLM HTTP机制也可以用于HTTP代理身份验证。该过程类似，除了：

* 服务器使用407响应代码（指示需要进行代理身份验证）而不是401。
* 客户端的1类和3类消息是在" 代理授权 "请求标头中发送的，而不是在" 授权 "标头中发送的。
* 服务器的Type 2质询在" Proxy-Authenticate "响应头中发送（而不是" WWW-Authenticate "）。

在Windows 2000中，Microsoft引入了"Negotiate" HTTP身份验证机制。虽然其主要目的是提供一种通过Kerberos通过Active Directory验证用户身份的方法，但它与NTLM方案向后兼容。当在"传统"模式下使用Negotiate机制时，在客户端和服务器之间传递的标头是相同的，只是将"Negotiate"（而不是" NTLM"）指定为机制名称。

### NTLM POP3身份验证

Microsoft的Exchange服务器为POP3协议提供了NTLM身份验证机制。这是RFC 1734中记录的与POP3 AUTH命令 一起使用的专有扩展 。在客户端，Outlook和Outlook Express支持此机制，称为"安全密码身份验证"。

POP3 NTLM身份验证握手在POP3"授权"状态期间发生，其工作方式如下：

1. 客户端可以通过发送不带参数的AUTH命令来请求支持的身份验证机制的列表：

    AUTH
2. 服务器以成功消息响应，然后是受支持机制的列表；此列表应包含" NTLM "，并以包含单个句点（" 。 "）的行结尾。

    +OK The operation completed successfully.

    NTLM

    .
3. 客户端通过发送一个将NTLM指定为身份验证机制的AUTH命令来启动NTLM身份验证：

    AUTH NTLM
4. 服务器将显示一条成功消息，如下所示。注意，" + "和" OK " 之间有一个空格；RFC 1734指出服务器应以质询进行答复，但是NTLM要求来自客户端的Type 1消息。因此，服务器发送"非challenge"消息，基本上是消息" OK "。

    +OK
5. 然后，客户端发送Type 1消息，以Base-64编码进行传输：

    TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1JLU1RBVElPTkRPTUFJTg ==
6. 服务器回复Type 2质询消息（再次，以Base-64编码）。它以RFC 1734指定的质询格式发送（" + "，后跟一个空格，后跟质询消息）。如下所示；换行符是出于编辑目的，不出现在服务器的答复中：
   * TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8AAAAAAAAAAGIAYgA8AAAA 

     RABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTAEUAUgBWAEUAUgAEABQAZA 

     BvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHIALgBkAG8AbQBhAGkAbgAu 

     AGMAbwBtAAAAAAA =
7. 客户端计算并发送Base-64编码的Type 3响应（下面的换行符仅用于显示目的）：

    TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVA 

    AAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBU 

    AEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0 + d8ViWpjBwx6BhHRmspst9GgPOZWP 

    uMITqcxg ==
8. 服务器验证响应并指示认证结果：

    +OK User successfully logged on

成功进行身份验证后，POP3会话进入"事务"状态，从而允许客户端检索消息。

### NTLM IMAP身份验证

Exchange提供了一种IMAP身份验证机制，其形式类似于前面讨论的POP3机制。RFC 1730中记录了IMAP身份验证 ；NTLM机制是Exchange提供的专有扩展，并由Outlook客户端家族支持。

握手序列类似于POP3机制：

1. 服务器可以在能力响应中指示对NTLM身份验证机制的支持。连接到IMAP服务器后，客户端将请求服务器功能列表：

    0000 CAPABILITY
2. 服务器以支持的功能列表作为响应；服务器回复中字符串" AUTH = NTLM " 的存在指示了NTLM身份验证扩展名：
   * CAPABILITY IMAP4 IMAP4rev1 IDLE LITERAL+ AUTH=NTLM

     0000 OK CAPABILITY completed.
3. 客户端通过发送 将NTLM指定为身份验证机制的AUTHENTICATE命令来启动NTLM身份验证：

    0001授权NTLM
4. 服务器以一个空的质询作为响应，该质询仅由" + "组成：

    \+
5. 然后，客户端发送Type 1消息，以Base-64编码进行传输：

    TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1JLU1RBVElPTkRPTUFJTg ==
6. 服务器回复Type 2质询消息（再次，以Base-64编码）。它以RFC 1730指定的质询格式发送（" + "，后跟一个空格，后跟质询消息）。如下所示；换行符是出于编辑目的，不出现在服务器的答复中：
   * TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8AAAAAAAAAAGIAYgA8AAAA 

     RABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTAEUAUgBWAEUAUgAEABQAZA 

     BvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHIALgBkAG8AbQBhAGkAbgAu 

     AGMAbwBtAAAAAAA =
7. 客户端计算并发送Base-64编码的Type 3响应（下面的换行符仅用于显示目的）：

    TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVA 

    AAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBU 

    AEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0 + d8ViWpjBwx6BhHRmspst9GgPOZWP 

    uMITqcxg ==
8. 服务器验证响应并指示认证结果：

    0001 OK AUTHENTICATE NTLM completed.

身份验证完成后，IMAP会话将进入身份验证状态。

### NTLM SMTP身份验证

除了为POP3和IMAP提供的NTLM身份验证机制外，Exchange还为SMTP协议提供了类似的功能。这样可以对发送外发邮件的用户进行NTLM身份验证。这是与SMTP AUTH命令一起使用的专有扩展（在 RFC 2554中记录）。

SMTP NTLM身份验证握手的操作如下：

1. 服务器可以在EHLO答复中指示支持NTLM作为身份验证机制。连接到SMTP服务器后，客户端将发送初始EHLO消息：

    EHLO client.example.com
2. 服务器以支持的扩展列表进行响应。NTLM身份验证扩展由其在AUTH机制列表中的存在指示，如下所示。请注意，AUTH 列表发送了两次（一次带有" = "，一次没有）。显然在RFC草案中指定了" AUTH = "形式。发送两种表格都可以确保支持针对该草案实施的客户。

    250-server.example.com Hello \[10.10.2.20]

    250-HELP

    250-AUTH LOGIN NTLM

    250-AUTH=LOGIN NTLM

    250 SIZE 10240000
3. 客户端通过发送一个AUTH 命令来启动NTLM身份验证，该命令将NTLM指定为身份验证机制，并提供Base-64编码的Type 1消息作为参数：

   AUTH NTLM TlRMTVNTUAABAAAABzIAAAYABgArAAAACwALACAAAABXT1JLU1RBVElPTkRPTUFJTg ==

根据RFC 2554，客户端可以选择不发送初始响应参数（而是仅发送" AUTH NTLM "并等待空服务器质询，然后以Type 1消息答复）。但是，在针对Exchange测试时，这似乎无法正常工作。

1. 服务器回复334响应，其中包含Type 2质询消息（同样是Base-64编码）。如下所示；换行符是出于编辑目的，不出现在服务器的答复中：

    334 TlRMTVNTUAACAAAADAAMADAAAAABAoEAASNFZ4mrze8AAAAAAAAAAGIAYgA8AAAA 

    RABPAE0AQQBJAE4AAgAMAEQATwBNAEEASQBOAAEADABTAEUAUgBWAEUAUgAEABQAZA 

    BvAG0AYQBpAG4ALgBjAG8AbQADACIAcwBlAHIAdgBlAHIALgBkAG8AbQBhAGkAbgAu 

    AGMAbwBtAAAAAAA =
2. 客户端计算并发送Base-64编码的Type 3响应（下面的换行符仅用于显示目的）：

    TlRMTVNTUAADAAAAGAAYAGoAAAAYABgAggAAAAwADABAAAAACAAIAEwAAAAWABYAVA 

    AAAAAAAACaAAAAAQIAAEQATwBNAEEASQBOAHUAcwBlAHIAVwBPAFIASwBTAFQAQQBU 

    AEkATwBOAMM3zVy9RPyXgqZnr21CfG3mfCDC0 + d8ViWpjBwx6BhHRmspst9GgPOZWP 

    uMITqcxg ==
3. 服务器验证响应并指示认证结果：

   235 NTLM authentication successful.

验证后，客户端可以正常发送消息。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://rootclay.gitbook.io/ntlm/ntlm-ren-zheng-xie-yi-yu-ssp-fu-lu-b.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.