Issues configuring NTLM Windows Authentication

Products

CA Single Sign On Secure Proxy Server (SiteMinder) AXIOMATICS POLICY SERVER CA Single Sign On Agents (SiteMinder) CA Single Sign On Federation (SiteMinder) CA Single Sign On SOA Security Manager (SiteMinder) SITEMINDER

Issue/Introduction

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]

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 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.

Environment

Release : 12.8

Component : SITEMINDER SECURE PROXY SERVER

Resolution

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.

Additional Information

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/