Many Microsoft applications such as SharePoint and Outlook Anywhere rely on NTLM for session authentication. NTLM has a few unique requirements for load balancing that are addressed in this topic, along with recommended changes for impacted applications or virtual services.

Connection Multiplexing

The NSX Advanced Load Balancer has connection multiplexing enabled by default within the HTTP application profile. Multiplexing enables the sharing of open, idle connections between SEs and the servers. Though Connection Multiplexing significantly accelerates connection establishment, it is not compatible with NTLM, which establishes trust to a TCP connection instead of the session or request. For applications that rely on NTLM, the NSX Advanced Load Balancer recommends deactivating the Connection Multiplex option in the HTTP application profile of the virtual service. Navigate to Templates > Profiles to access the Edit Application Profile page.

Auto Detecting NTLM Connections

There can be instances where NTLM gets enabled in the environment or the backend servers having NTLM flow get enabled by default and these occurrences go completely unnoticed. This might lead to compatibility issues between NTLM and Connection Multiplexing.

If Connection Multiplexing is enabled for a virtual service, the NSX Advanced Load Balancer auto detects the NTLM connection using response headers, and disables connection multiplexing for the specific connection, until the connection terminates. This helps to seemlessly retain the performance of non-NTLM traffic and limit the connection switching only to NTLM connections. NSX Advanced Load Balancer detects NTLM apps using the NTLM header in the WWW-Authenticate Header. If NTLM string is present in the WWW-Authenticate header (WWW-Authenticate: NTLM) then the app is considered as an NTLM-based application.

Starting from NSX Advanced Load Balancer version 22.1.1, the app is considered as an NTLM based-app even if only the Negotiate header is present in the www-authenticate header (WWW-Authenticate: Negotiate) in the server response. This means if the NTLM string or Negotiate is present in WWW-Authenticate header then the app is considered as NTLM app.

In the application profile configuration, the option detect_ntlm_app is enabled by default for connection strategy conversion. This can be deactivated, if required as shown in the following example.

[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>
Note:

  • In the case of Kerberos string in the request header from the client i.e., Negotiate: Kerberos the connection strategy remains unchanged. We do not detect it as an NTLM based app. In such a scenario, deactivating Connection Multiplexing is recommended.

  • Though Connection Strategy Conversion happens only when Connection Multiplexing is enabled for the connection, NTLM apps are detected irrespective of whether Connection Multiplexing is enabled or not.

Identifying the Connection Strategy Conversion

The NSX Advanced Load Balancer generates logs and statistics which help you in identifying a connection strategy conversion: On every occurrence of Connection Strategy Conversion, a Significance log is generated. To view the Significance log, navigate to Applications > Virtual Services > Logs. Check the value for the Significance field.

Use show virtualservice vs-ntlm internal and show pool pool-ntlm connpool to view the statistics.

Using NTLM Detection for Analytics

Using NTLM detection, the following data can be obtained.

  • NTLM Authentication Status

  • User Name

NTLM Authentication Status

When connection strategy (detect_ntlm_app) is enabled, the NTLM request is intercepted, the NTLM parameters are detected, and the information fetched from this request-response will be used for analytics like identifying the authentication status, the user name, and so on.

Based on the intercepted NTLM requests and responses, the following statuses are identified and supported:

Unauthorized:

If a client tries to access a resource without providing credentials, NTLM requests authentication from the client. Such a request is an unauthorized request.

Negotiation:

The client starts a negotiation and the server sends a negotiation response.

Authentication Success:

The client sends a final message (NTLM message) which carries the credentials. If the credentials are correct, the server sends a response code indicating that the user name and password are accepted. This is the authentication success state.

Authentication Failure:

If the credentials are incorrect, a 401 status code is returned indicating authentication failure. An authentication failure triggers the generation of a significant log.

Authenticated Requests:

NTLM authentications are connection based. Once a request is authorized, all the subsequent requests under the same connection are authorized automatically unless a re-authentication is initiated. Such auto-authenticated requests are called authenticated requests.

By default, NSX Advanced Load Balancer strips off X-Accel headers in an HTTP response sent to a client. However, this option can be deactivated, if required and the X-Accel headers will pass along with the HTTP response sent to the client.

User Name

The user name is detected from Type 3 NTLM messages in the request, irrespective of whether the authentication is successful or not. Once this is done, the subsequent requests on the same connection do not carry the credentials. The app logs for these requests will have the same user name stamped as the initial authorized request. This will continue until the client requests a re-authorization.

The NTLM logs in the App logs help in identifying:

  • If an NTLM flow was detected.

  • The status of authentication.

Monitoring

NTLM authenticated applications might require the HTTP health monitor to validate through NTLM for the check to succeed. This requires a custom, external monitor, such as the following example.

  • Script

#!/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”

  • Script Variables

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

401 Unauthorized Errors

When a client first connects to the site, the server responds with a 401 error code, which instructs the client that it is not authorized and must first authenticate.  This is a standard part of connecting to an NTLM site.  By default, the NSX Advanced Load Balancer Authentication profile designates any 4xx response as an error.  This results in lowered health score (the Performance score is negatively impacted).  These responses are also logged as Significant.

Since 401 responses are expected, it is desirable to exclude these response codes from the defined error list.  To exclude the response codes, navigate to Templates > Profiles and access the Analytics page.  Edit the profile attached to the NTLM-enabled virtual service.  Add 401 to the Exclude HTTP Status codes from Error Classification section and Save.