Issues configuring NTLM Windows Authentication with SiteMinder Access Gateway
Article ID: 140591
Updated On:
Products
Issue/Introduction
When configuring NTLM Windows Authentication using the Access Gateway, the user keeps getting prompted for login.
In the ACO for the gateway the value of WindowsNativeAuthentication is already set to "No".
The auth scheme is configured exactly based on SiteMinder documentation, have tried NTLM only auth scheme and IWA auth chain with the form scheme separately.
Tried enabling ACO named 'usentlmmapforntlmauth' and set the value to "Yes". No difference.
For the working scenario, in the web agent log, you will see:
[11/14/2019][15:14:55][4072][1636][<Transaction ID>][SmNtc::getCredentials][Request for SSPI NTLM Authentication]
[11/14/2019][15:14:55][4072][1636][<Transaction ID>][DeleteCookie][Deleted cookie 'SM_NTLMCTX'.]
[11/14/2019][15:14:55][4072][1636][][CSmSSPIServer::processNTLMRequest][AcceptSecurityContext returned : 0x00090312]
...then later
[11/14/2019][15:14:55][4072][1636][][CSmSSPIServer::processNTLMRequest][AcceptSecurityContext returned : 0x00000000]
For the non-working scenario,
[11/18/2019][09:56:16][7024][1972][<Transaction ID>][SmNtc::getCredentials][Request for SSPI NTLM Authentication]
[11/18/2019][09:56:16][7024][1972][<Transaction ID>][DeleteCookie][Deleted cookie 'SM_NTLMCTX'.]
[11/18/2019][09:56:16][7024][1972][][CSmSSPIServer::processNTLMRequest][AcceptSecurityContext returned : 0x00090312]
..then later
Stays at [AcceptSecurityContext returned : 0x00090312]
Environment
Release : 12.8
Component : SITEMINDER SECURE PROXY SERVER/ACCESS GATEWAY
Cause
From Microsoft documentation:
0x00000000L
The function succeeded. The security context received from the client was accepted. If the function generated an output token, the token must be sent to the client process.
0x00090312L
The function succeeded. The server must send the output token to the client and wait for a returned token. The returned token should be passed in pInput for another call to AcceptSecurityContext (CredSSP)
For all working scenarios, the browser is sending an NTLM Negotiate token (the one looks like TlRMTVNTUAABA.......CAAAADw==).
For failed use case, the token sent is a Kerberos token, not NTLM, as below, and its token content is much longer:
WWW-Authenticate Header (Negotiate) appears to be a Kerberos reply:
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ¡0 ....¡...*
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## H÷....¢l.j`h..
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## *H÷......~Y0W
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ....¡....¤...201
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## 91118145616Z¥...
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## .h[¦...)©...xxxx
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## .xxx.COMª.0. ...
## ## ## ## ## ## ## ## ## ## ## ## ## ## ## ## .¡.0...hostname
## ## ## ## ## ## 001$
NTLM token should be the intended and legit token to be used.
If the NTLM credential collector only expects and accepts an NTLM ticket, but receives a Kerberos ticket it will fail. The user subsequently gets prompted for Windows login.
Resolution
The issue happens due to the fact that the Kerberos configuration is working and now NTLM (IWA) is introduced into it.
If the browser receives a "WWW-Authenticate: Negotiate" response header with HTTP 401 response, then it will (if properly configured, e.g. site is in "Intranet" security zone) try and retrieve a Kerberos service ticket from the KDC. If it gets a service ticket, it will submit the ticket in another request in the "Authorization" request header.
If the NTLM credential collector receives a Kerberos ticket, it will fail. It only expects and accepts NTLM tickets, not Kerberos.
When NTLM works, is when the browser could not get a Kerberos ticket from KDC, or specifically use an NTLM token to communicate.
Please note that not all browsers can do that automatically or act the same way.
The fix is to not use a server name (SiteMinder Access Gateway) with an associated Kerberos service principal name. Use a different name for NTLM authentications than the one used for Kerberos authentications.
If an environment already has Kerberos working, NTLM (IWA) is likely not needed after all, but that will depend on the security infrastructure design used.
Additional Information
Feedback
