很多 Microsoft 应用程序（例如 SharePoint 和 Outlook Anywhere）依靠 NTLM 进行会话身份验证。NTLM 对负载均衡具有一些独特的要求，在本主题中介绍了这些要求，并建议了对受影响的应用程序或虚拟服务进行的更改。

连接多路复用

默认情况下，NSX Advanced Load Balancer 在 HTTP 应用程序配置文件中启用了连接多路复用。多路复用可以在 SE 和服务器之间共享打开的空闲连接。尽管连接多路复用显著加快连接建立过程，但它与 NTLM 不兼容，NTLM 建立对 TCP 连接而不是会话或请求的信任关系。对于依赖于 NTLM 的应用程序，NSX Advanced Load Balancer 建议在虚拟服务的 HTTP 应用程序配置文件中停用连接多路复用选项。导航到模板 > 配置文件以访问编辑应用程序配置文件页面。

自动检测 NTLM 连接

在某些场景中，可能会在环境中启用 NTLM，或者默认启用具有 NTLM 流的后端服务器，而完全不会注意到这些情况。这可能会导致 NTLM 和连接多路复用之间的兼容性问题。

如果为虚拟服务启用了连接多路复用，则 NSX Advanced Load Balancer 使用响应标头自动检测 NTLM 连接，并为该特定连接禁用连接多路复用，直到该连接终止。这有助于无缝地保持非 NTLM 流量的性能，并将连接交换限制为仅 NTLM 连接。NSX Advanced Load Balancer 使用 WWW-Authenticate 标头中的 NTLM 标头检测 NTLM 应用程序。如果在 WWW-Authenticate 标头中存在 NTLM 字符串 (WWW-Authenticate: NTLM)，则将该应用程序视为基于 NTLM 的应用程序。

从 NSX Advanced Load Balancer 22.1.1 版本开始，即使在服务器响应的 WWW-Authenticate 标头中仅存在 Negotiate 标头 (WWW-Authenticate: Negotiate)，也将应用程序视为基于 NTLM 的应用程序。这意味着，如果在 WWW-Authenticate 标头中存在 NTLM 字符串或 Negotiate，则将应用程序视为 NTLM 应用程序。

在应用程序配置文件配置中，默认启用 detect_ntlm_app 选项以进行连接策略转换。如果需要，可以停用该选项，如以下示例中所示。

[admin:controller-vmdc2]: > configure applicationprofile applicationprofile-1
[admin:controller-vmdc2]: applicationprofile> http_profile
[admin:controller-vmdc2]: applicationprofile:http_profile> no detect_ntlm_app
[admin:controller-vmdc2]: applicationprofile:http_profile> save
[admin:controller-vmdc2]: applicationprofile>
注：

  • 对于来自客户端的请求标头中的 Kerberos 字符串（即 Negotiate: Kerberos），连接策略保持不变。我们不会将其检测为基于 NTLM 的应用程序。在此类场景中，建议停用连接多路复用。

  • 尽管仅在为连接启用了连接多路复用时才会发生连接策略转换，但无论是否启用连接多路复用，都会检测 NTLM 应用程序。

识别连接策略转换

NSX Advanced Load Balancer 生成日志和统计信息，以帮助您识别连接策略转换：每次发生连接策略转换时，都会生成一个重要日志。要查看重要日志，请导航到应用程序 > 虚拟服务 > 日志。检查重要性字段的值。

可以使用 show virtualservice vs-ntlm internal 和 show pool pool-ntlm connpool 查看统计信息。

使用 NTLM 检测进行分析

通过使用 NTLM 检测，可以获取以下数据。

  • NTLM 身份验证状态

  • 用户名

NTLM 身份验证状态

如果启用了连接策略 (detect_ntlm_app)，将拦截 NTLM 请求，检测 NTLM 参数，并使用从该请求响应中获取的信息进行分析，例如，识别身份验证状态、用户名等。

根据截获的 NTLM 请求和响应，将识别和支持以下状态：

未授权：

如果客户端尝试访问资源而未提供凭据，则 NTLM 从客户端请求身份验证。这种请求是未授权的请求。

协商：

客户端启动协商，服务器发送协商响应。

身份验证成功：

客户端发送包含凭据的最终消息（NTLM 消息）。如果凭据正确，则服务器发送响应代码，表示已接受用户名和密码。这是身份验证成功状态。

身份验证失败：

如果凭据不正确，则返回 401 状态代码，表示身份验证失败。身份验证失败将触发生成重要日志。

经过身份验证的请求：

NTLM 身份验证基于连接。在授权请求后，将自动授权同一连接上的所有后续请求，除非启动了重新身份验证。这种自动验证的请求称为经过身份验证的请求。

默认情况下，NSX Advanced Load Balancer 删除发送到客户端的 HTTP 响应中的 X-Accel 标头。不过，如果需要，可以停用该选项，X-Accel 标头将与发送到客户端的 HTTP 响应一起传送。

用户名

无论身份验证是否成功，都会从请求的类型 3 NTLM 消息中检测用户名。在完成该操作后，同一连接上的后续请求不会包含凭据。这些请求的应用程序日志标记与最初授权的请求相同的用户名。这种情况一直持续到客户端请求重新授权为止。

应用程序日志中的 NTLM 日志有助于确定：

  • 是否检测到 NTLM 流。

  • 身份验证状态。

监控

经过身份验证的 NTLM 应用程序可能要求 HTTP 运行状况监控器通过 NTLM 进行验证，检查才会成功。这需要使用自定义的外部监控器，例如以下示例。

  • 脚本

#!/bin/bash
#curl http://$IP:$PORT/Shared%20Documents/10m.dat -I -L --ntlm -u $USER:$PASS -I -L > /run/hmuser/$HM_NAME.out 2>/dev/null
curl http://$IP:$PORT/Shared%20Documents/10m.dat -I -L --ntlm -u $USER:$PASS -I -L  | grep "200 OK”

  • 脚本变量

USER='foo\administrator' PASS=*****

401 未授权错误

在客户端首次连接到站点时，服务器使用 401 错误代码进行响应，以指示客户端未授权，必须先进行身份验证。  这是 NTLM 站点连接过程的标准组成部分。  默认情况下，NSX Advanced Load Balancer 身份验证配置文件将任何 4xx 响应指定为错误。  这会导致运行状况分数降低（性能分数受到负面影响）。  这些响应也会记录为重要日志。

由于 401 响应是预期行为，因此，最好将这些响应代码从定义的错误列表中排除。  要排除响应代码，请导航到模板 > 配置文件并访问分析页面。  编辑附加到启用了 NTLM 的虚拟服务的配置文件。  将 401 添加到从错误分类中排除 HTTP 状态代码部分并保存。