Skip to content

Latest commit

 

History

History
144 lines (120 loc) · 11.1 KB

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

File metadata and controls

144 lines (120 loc) · 11.1 KB
Raw

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.

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