Requirements for Load Balancing During NTLM Authentication

Overview

A number of 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 article, along with recommended changes for impacted applications or virtual services.

Connection Multiplexing

Avi Vantage has connection multiplexing enabled by default within the HTTP application profile. Multiplexing enables the sharing of open, idle connections between Service Engines and the servers. This significantly accelerates connection establishment, however it is not compatible with NTLM, which establishes trust to a TCP connection rather than the session or request. For applications that rely on NTLM, Avi recommends disabling the Connection Multiplex option in the virtual service’s HTTP application profile as shown at right (navigate to Templates > Profiles).

Auto Detecting NTLM Connections

NTLM being enabled in the environment or if the backend servers having NTLM flow enabled by default goes unnoticed, thus leading to compatibility issues between NTLM and Connection Multiplexing.

Starting with Avi Vantage version 20.1.3, if connection multiplexing is enabled for a virtual service, Avi auto detects the NTLM connection using response headers, and disables connection multiplexing for the specific connection, until the connection terminates. Thus, seemlessly retaining the performance of the non-NTLM traffic and limiting the connection switching only to NTLM connections.

In the application profile configuration, the option detect_ntlm_app is enabled by default for connection strategy conversion.
This can be disabled, if required as shown below:

[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: Connection Strategy conversion happens only when Connection Multiplexing is enabled for the connection, but NTLM apps are detected irrespective of whether connection multiplexing is enabled or not.

Identifying the Connection Strategy Conversion

Avi Vantage generates logs and stats which help you in identifying a connection strategy conversion:

• Every time there is a connection strategy conversion, a significance log is generated.
  

To view the significance log, navigate to Applications > Virtual Services > Logs.

The significance logs are displayed as shown below:

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

Using NTLM Detection for Analytics

NTLM Authentication Status

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

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 then sends a final message (NTLM message) which carries the credentials. If the credentials are correct, the server will send a response code indicating that the user name and password are accepted. This is the authentication success state.

• Authentication Failure: In case the credentials are incorrect, then 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.

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 therefore help in identifying:

• If an NTLM flow was detected
• The status of authentication.

Monitoring

NTLM authenticated applications may require the HTTP health monitor to validate via NTLM for the check to succeed. This will require a custom, external monitor, such as the example below:

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=foo123

401 Unauthorized Errors

When a client first connects to the site, the server responds back with a 401 error code, which instructs the client it is not authorized and must first authenticate.  This is a standard part of connecting to an NTLM site.  By default, the Avi Vantage 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 do this, navigate to the Templates > Profiles > 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.

Document Revision History