For NTLM user-side authentication Netscaler had traditionaly used SMB Protocol to establish connection with Domain Controller and authenticate users.

The prerequisite for that is ability of Netscaler to resolve Domain name (internally or externally) to locate appropriate Domain Controller. Communication flow is drawn on the following picture:

Note: The author take Exchange Authentication (back-end authentication) process out of scope of this document and is using Outlook Web Access (OWA) only as an example of one of the most used web services in enterprise environment.

1. Client send HTTP Request to Netscaler to access Web service (Exchange OWA in this example).
2. Netscaler send Unauthorized response with Negotiate or NTLM Authenticate request.
3. Client response with NTLM Negotiate
4. Netscaler should locate Domain Controller and sends DNS request for domain name. It could be resolved at external DNS server or locally configured DNS Entry:

Netscaler tries to establish TCP Connection with first resolved Domain Controller at SMB port 445. In case of multiple FQDN Name Resolutions (multiple Domain Controllers), NetScaler will try to setup SMB connection to first resolved IP Address and in case of failure – will send new DNS request if timeout will be reached:

It could lead to longer authentication time or to inability to authenticate in case of incorrect DNS resolution on first hop.

5. In case of successful connection to Domain controller the user is authenticated and get   requested HTTP page.

The limitations of using SMB protocol for user authentication and probable problems with poor DNS design could be eliminated in new functionality of Netscaler build 11.0.64. It is possible to specify NTLM path to use external NTLM authentication provider or group of those.

1. Client send request to Netscaler to access Web service.
2. Netscaler send Unauthorized response with Negotiate or NTLM Authenticate request.
3. Client response with NTLM Negotiate
4. Netscaler setup secured or unsecured connection to NTLM URL Path, specified by the administrator.
5. Netscaler sends HTTP request to NTLM Authentication Web site (IIS in this example).
6. Web site sends Unauthorized response with NTLM Authenticate request. It is important to specify NTLM Authentication method, not Negotiate or Kerberos, because it could lead to authentication problems.
7. User sends his identity to Netscaler and Netscaler sends it to NTLM Authentication Web Site.
8. NTLM Authentication Web Site setup a RPC connection to Domain Controller and going through Netlogon with user identity. In case of successful authentication, it responses with HTTP 200 OK to Netscaler.
9. The user is authenticated and get requested HTTP page.

NetScaler configuration for using NTLM Path

1. Administrator should specify NTLM Path, when configure Server for Negotiate Basic Policy : Security -> AAA – Application Traffic -> Policies -> Authentication -> Basic Policies -> Negotiate -> Servers.

Or in CLI:

add authentication negotiateAction win2012exch2013.demomuc.local -domain demomuc.local -domainUser kcdnsc -domainUserPasswd 1c17ae5e4f3e976b20512d08412b95984abb30b3ea5d580ed484ff22f9c8e7eb -encrypted -encryptmethod ENCMTHD_3 -NTLMPath http://xenapp.demomuc.local/integrated/iisstart.htm

2. Negotiate Policy configuration:

add authentication negotiatePolicy Kerberos_FE_Policy ns_true win2012exch2013.demomuc.local

NTLM Authentication Web Site configuration

In this example IIS Web site is used with NTLM Authentication configured.

Testing

1. Start Web browser and point to Netscaler VIP – www.demomuc.local/owa . Automatic login was seen, as a PC was joined the domain and web browser was configured to automatically logon with current user name and password.

2. Output of Packet Trace on Netscaler:

We can see here, that Netscaler is setting a HTTP session to Authentication Web server (10.0.0.41) after receiving a request from the user (10.0.0.22) at his VIP (10.0.0.100). And after that the communication is been proxied through Netscaler to Authentication Web server.

3. Output of Packet Trace on NTLM Authentication Web Site:

Here we can see that after receiving user credentials from Netscaler (SNIP 10.0.0.12), Authentication Web server establishes RPC connection to Domain Controller (10.0.0.32) to authenticate the user.

4. Event in Event Manager at Domain Controller: