When configuring NTLM Windows Authentication using CA access gateway, user keeps getting prompted for login.
ACO for the gateway already set the value of WindowsNativeAuthentication to no.
Auth scheme is configured exactly based on siteminder documentation, have tried ntlm only auth scheme and IWA auth chain with form scheme separately.
Tried enabled ACO named 'usentlmmapforntlmauth' and set the value to yes. No difference.
For working scenario, in web agent log, you will see:
[11/14/2019][15:14:55][4072][1636][50afcf84-d7d8f25f-07152c53-923a3fed-c4bcf3de-9][SmNtc::getCredentials][Request for SSPI NTLM Authentication]
[11/14/2019][15:14:55][4072][1636][50afcf84-d7d8f25f-07152c53-923a3fed-c4bcf3de-9][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 non-working scenario,
[11/18/2019][09:56:16][7024][1972][27c7c6d4-0a5f2972-3b38a36b-568a0836-cac25932-70][SmNtc::getCredentials][Request for SSPI NTLM Authentication]
[11/18/2019][09:56:16][7024][1972][27c7c6d4-0a5f2972-3b38a36b-568a0836-cac25932-70][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]
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 ntlm Negotiate token (the one looks like TlRMTVNTUAABA.......CAAAADw==).
For failed use case, the token sent is Kerberos token, not ntlm, as below, and its token content is much longer:
WWW-Authenticate Header (Negotiate) appears to be a Kerberos reply:
A1 81 83 30 81 80 A0 03 0A 01 01 A1 0B 06 09 2A ¡0 ....¡...*
86 48 82 F7 12 01 02 02 A2 6C 04 6A 60 68 06 09 H÷....¢l.j`h..
2A 86 48 86 F7 12 01 02 02 03 00 7E 59 30 57 A0 *H÷......~Y0W
03 02 01 05 A1 03 02 01 1E A4 11 18 0F 32 30 31 ....¡....¤...201
39 31 31 31 38 31 34 35 36 31 36 5A A5 05 02 03 91118145616Z¥...
07 68 5B A6 03 02 01 29 A9 0E 1B 0C 50 52 4F 44 .h[¦...)©...xxxx
2E 4D 54 42 2E 43 4F 4D AA 1C 30 1A A0 03 02 01 .xxx.COMª.0. ...
01 A1 13 30 11 1B 0F 73 73 6F 2D 31 73 73 6F 69 .¡.0...hostname
6E 74 30 30 31 24 001$
Ntlm token should be the intended and legit token to be used.
When NTLM credential collector only expects and accepts NTLM ticket, but receives a Kerberos ticket, thus it will fail. User subsequently gets prompted for window login.
Release : 12.8
Component : SITEMINDER SECURE PROXY SERVER
The issue happens is due to the fact that customer has Kerberos already configured working and now try to introduce ntlm(IWA) 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 NTLM token to communicate.
Please note that not all browsers can do that automatically or act the same way.
The fix is do not use a server name (CA 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, maybe ntlm(IWA) is not needed after all, but that will depend on customer's security infrastructure design.
https://ca-broadcomcsm.wolkenservicedesk.com/wolken/esd/knowledgebase_search?articleId=131594
https://community.broadcom.com/communities/community-home/digestviewer/viewthread?MID=806601#bm781726b8-2359-4096-abf6-ba4806b74146
https://blogs.technet.microsoft.com/tristank/2006/08/02/two-easy-ways-to-pick-kerberos-from-ntlm-in-an-http-capture/