NTLM Authentication on NetScaler
Article ID: CTX215684
Updated On:
Description
With the release of NetScaler 11 build 64.34, the requirements and configuration for NTLM authentication have changed.
It is a common use case to authenticate using Kerberos when users are internal on the network but for external users who cannot reach Active Directory, we fallback to NTLM.
The scope of this article is to describe the use case when users fallback to NTLM authentication.
Requirements
- A load balanced virtual server
- A back-end resource with “Windows Authentication” enabled and the correct providers set (Negotiate and NTLM)
- AAA virtual server for authentication
- An authentication negotiate policy
- An authentication negotiate server
- An NTLM path URL
Communication Flow
To better understand the full communication flow, let us looks at the relevant packets from a packet capture.
-
First, the client issues a GET request for the target resource, which the load balancer responds to with a “401 Unauthorized.”
-
Within the “401” response, the load balancer tells the client it accepts “Negotiate” and “NTLM” for authentication.
As the client is external to my network, it cannot reach the Active Directory/Kerberos Distribution Center to request a ticket, so it responds saying it wants to authenticate using NTLM.
-
The following is the same response at the header level.
-
The NetScaler will now send a GET request to the back-end server defined in the “NTLM Path” (this is a parameter we configure in the Negotiate Action as will be seen below) and specify it wants to use NTLM authentication.
-
The site that we specify in the NTLM path should be enabled for Windows Authentication with NTLM included in the Provider list as seen below:
-
The back-end server responds with an NTLM challenge that the NetScaler forwards to the client. The client responds with its credentials, which are then sent back to the server and if successful, a “200 OK” is returned, the NetScaler treats this as a successful logon.
- The client has now successfully authenticated.
Sequence Diagram
The following is the sequence of steps described above:
NetScaler Configuration Steps
#create backend server and then create service
add server AAA-serv dc.aaa.com
add service AAA-service dc.aaa.com HTTP 80
#Add Negotiate authentication policy and action
add authentication negotiateAction administrator -domain aaa.com -domainUser administrator -domainUserPasswd Password -NTLMPath “http://10.217.28.180/integrated.html”
add authentication negotiatePolicy Kerberos-auth-policy ns_true administrator
*Note: NTLM Path is mandatory here since we want NTLM Authentication.
#Create AAA vserver
add authentication vserver aaa_vserver SSL 1.1.1.1 443
#Bind Negotiate policy to AAA vserver
bind authentication vserver aaa_vserver –policy Kerberos-auth-policy
#Create the LB vserver and bind the AAA vserver
add lb vserver LB_HTTP HTTP 2.2.2.2 80 -authn401 ON -authnVsName aaa_vserver
Troubleshooting
The following are some of the ns.log messages seen for different scenarios. Also, we need to enable debug log level to see all the messages.
-
Successful authentication case:
Jul 28 22:38:58 <local0.debug> 10.217.28.160 07/28/2016:22:38:58 GMT 0-PPE-1 : default AAATM Message 186 0 : "NTLM AUTH RESP: ns_aaatm_ntlm_hc_resp_handler, received response, code: 401, header len: 422 content len: 341, nsb app_payload len: 763, payload: HTTP/1.1 401 Unauthorized^M Content-Type: text/html; charset=us-ascii^M Server: Microsoft-HTTPAPI/2.0^M WWW-Authenticate: NTLM TlRMTVNTUAACAAAACgAKADgAAAAFgokCRkX2GPGKRZIAAAAAAAAAAG4AbgBCAAAABgOAJQAAAA9BAEEAQQBUAE0AAgAKAEEAQQBBAFQATQABAAQARABDAAQAEgBhAGEAYQB0AG0ALgBjAG8AbQADABgAZABjAC4AYQBhAGEAdABtAC4AYwBvAG0ABQASAGEAYQBhAHQAbQAuAGMAbwBtAAcACABVtuX1IOnRAQAAAAA=^M Date: Thu, 28 Jul 2016 22:39:54 GMT^M Content-Length: 341^M ^M <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN""http://www.w3.org/TR/html4/strict.dtd">^M <HTML><HEAD><TITLE>Not Authorized</TITLE>^M </HEAD>^M <BODY><h2>Not Authorized</h2>^M <hr><p>HTTP Error 401. The requested resource requires user authentication.</p>^M </BODY></HTML>^M "
Jul 28 22:38:58 <local0.debug> 10.217.28.160 07/28/2016:22:38:58 GMT 0-PPE-1 : default AAATM Message 187 0 : "NTLM: Sent NTLM Challenge to client"
Jul 28 22:38:58 <local0.debug> 10.217.28.160 07/28/2016:22:38:58 GMT 0-PPE-1 : default AAATM Message 188 0 : "NTLM AUTH RESP: ns_aaatm_ntlm_hc_resp_handler, received response, code: 200, header len: 294 content len: 74, nsb app_payload len: 368, payload: HTTP/1.1 200 OK^M Cache-Control: no-cache^M Content-Type: text/html^M Last-Modified: Fri, 17 May 2013 03:10:20 GMT^M Accept-Ranges: bytes^M ETag: "c0e67910ac52ce1:0"^M Server: Microsoft-IIS/8.5^M Persistent-Auth: true^M X-Powered-By: ASP.NET^M Date: Thu, 28 Jul 2016 22:39:54 GMT^M Content-Length: 74^M ^M <html>^M Integrated Authentication 10.217.22.241^M Server Running^M </html>^M "
Jul 28 22:38:58 <local0.debug> 10.217.28.160 07/28/2016:22:38:58 GMT 0-PPE-1 : default AAATM Message 189 0 : "ns_aaatm_ntlm_hc_resp_handler: NTLM auth successful!, user: user1 "
Jul 28 22:38:58 <local0.info> 10.217.28.160 07/28/2016:22:38:58 GMT 0-PPE-1 : default AAATM Message 190 0 : "NTLM: Auth successful for user 'user1'" -
When NTLM Path is not set:
Jul 28 22:42:23 <local0.err> 10.217.28.160 07/28/2016:22:42:23 GMT 0-PPE-2 : default AAATM Message 865 0 : "NTLM: Couldnt open server connection to " -
When NTLM path is set to some server which does not send 401:
Jul 28 22:43:23 <local0.err> 10.217.28.160 07/28/2016:22:43:23 GMT 0-PPE-2 : default AAATM Message 870 0 : "NTLM RESP: Expected type2, found response code '200' is not 401, bailing out " - Pay special attention to the NTLM path - it must have a full FQDN and PATH , ie http://FQDN/PATH.html, using only the http://FQDN will result in a “Http/1.1 Internal Server Error 43550” error upon logging in. This is being tracked via an internal bug and will be resolved soon.
Environment
Issue/Introduction
