New IWA auth scheme only works with IE (NOT a browser config issue)

[Duc Tran]

​Hi Folks,

We have had our IWA authentication scheme working fine since 2012.  Our current IWA auth scheme runs on Windows 2008 Server with r12.0 SP3 IIS webagent.  InfoSec requires us to upgrade to Windows 2016 Server so we built a new Windows 2016 Server and installed r12.52 SP1 CR09 IIS webagent on this new server and configure IIS for IWA/NTLM authentication.

Here's the issue we're running into:

1) All of our web applications that uses the IWA authentication scheme works with Internet Explorer, FireFox, and Chrome when it is pointed to the existing IWA auth scheme from the Windows 2008 Server.

2) If we configure these apps to point them to the new IWA auth scheme on the new Windows 2016 Server then the Integrated Windows Authentication only works if the web browser is IE but not with FireFox or Chrome.

3) When using Chrome or FF, the agenttrace.log file on the new Windows 2016 Server indicated that it successfully authenticated the user and created the SMSESSION cookie, but when the web browser is redirected back to the web application TARGET, it does not contain the SMSESSION cookie and therefore the webagent on the application redirect the browser to the IWA auth scheme which does the same thing again as it goes into a loop.

4) reason why I don't think this is a web browser (Chrome/FF) configuration issue is because these browsers works fine when the IWA auth scheme is the old Windows 2008 Server.

I have a support case open with Broadcom Support, but I don't seem to be getting anywhere with them on this case so turning to the community for help.

Thanks in advance!

[Patrick Dussault]

Hi Duc,


For Chrome, you need to add 3 parameters to the configuration. To get
a sample to test it, check the following KD :


chrome IWA
https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=110055


Hope this helps,


Best Regards,
Patrick

[Duc Tran]

Hello Patrick,

Thank you for your response.  This is a very strange issue and I really don't think it is a web browser config/compatibility issue with Chrome or FireFox.  Let me give you a bit more background for your assessment:

Chrome and FireFox browsers currently works with IWA but only if the apps are pointing to the current/old IWA auth scheme which is a combination of IIS webagent r12.0 SP3 on Windows Server 2008.  We build a new Windows Server 2016 and installed  SiteMinder IIS webagent r12.52 SP1 CR09 and configured IIS website for IWA authentication.  Now when we point our internal intranet web apps to the new IWA auth scheme, then it appears to only work with IE but not with Chrome or FF.

The agenttrace.log file on the new IWA server shows that the user was authenticated by the policy server and identified the user as well as creating the SMSESSION cookie and then pass the browser back to the application TARGET, but it appears that the SMSESSION cookie would only exist on the IE browser but not on Chrome or FF and therefore the webagent on the application web server will redirect the request back to the IWA server to obtain SMSESSION cookie and hence, goes into a loop.

The fact that IWA works on both Chrome and FF if the browser is redirected to the old/current IWA auth scheme, but not on the new IWA auth scheme, this would make me think that both Chrome and FF browsers are configured to work with Windows Authentication.  Also when these browsers hit the new IWA auth scheme, the agenttrace.log file showed that it authenticated the user and created the SMSESSION cookie which proves that the browsers successfully passed the user's identity to the IWA server.

If you have any additional insights I would love the help.

Thanks!

[Peter Burant]

Hi Duc,

What is most likely happening is only IE is accepting the cookie from the new site.  I am assuming the host serving the authentication scheme is different between the two environments.  To verify this, gather a Fiddler or other http trace while reproducing the problem on Chrome or Firefox.  Chances are since you are seeing the smsession cookie set in the web agent trace log, you will also see the set cookie statement in the http trace.   While you are testing, observe the bottom of the browser window to see if it perhaps has a prompt to accept cookies (this prompt can be easy to miss).

Another test you can run is to switch the auth scheme to basic auth or forms auth in the new site and see if Chrome or FF can authenticate.  If not, it's likely because they are not accepting the session cookie from that host.

Regards,
Pete
Broadcom Siteminder Support

[Patrick Dussault]

Hi Duc,

Following

chrome IWA
https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=110055

make sure that the new server is listed and the target domain is
listed also in the different parameter you set.

Have you tried the command line for google chrome ? What is your command line ?

Best Regards,
Patrick

[Duc Tran]

Hi Pratrick,

Here is my command:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-plugins --process-per-site -auth-server-whitelist="vmslciwad01.regence.com, extn-cbc-dev.regence.com" -auth-negotiate-delegatewhitelist="vmslciwad01.regence.com, extn-cbc-dev.regence.com" -auth-schemes="digest,ntlm,negotiate" https://extn-dev-cbc.regence.com/cbc/Search.do​

This command launched Chrome and attempted to request the protected TARGET: https://extn-dev-cbc.regence.com which then gets redirected to the IWA auth scheme at: http://vmslciwad01.regence.com and according to the agenttrace.log file on the IWA server, it successfully authenticated the user and created the SMSESSION cookie and then passes the browser back to the TARGET, but for some reason Chrome does not present the SMESSION cookie to the webagent on the TARGET server and therefore, the redirect back to IWA happens again and goes into loop.

This is strange because of several factors:
*IWA auth scheme works just fine for IE/Chrome/FF when pointing to the old IWA auth scheme (Windows 2008 Server with IIS webagent r12.0)
*IWA auth scheme now only works for IE when pointing to NEW auth scheme (Windows 2016 Server with r12.52 webagent)
*The agenttrace.log fie on the NEW IWA server shows that it successfully authenticated the user on both Chrome and FF and created SMSESSION cookie so this leads you to believe that Windows / Kerberos authentication setting is NOT an issue with Chrome and FF

I am at lost here with this and Broadcom support wants to close out this case saying that because this works with IE but not Chrome or FireFox then it's a web browser config issue and not with SiteMinder.  But I contradict that base on the above.


​

[Patrick Dussault]

Hi Duc,

There's a mismatch in the command parameter and the target :

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
--disable-plugins --process-per-site
-auth-server-whitelist="vmslciwad01.regence.com,
extn-cbc-dev.regence.com"
-auth-negotiate-delegatewhitelist="vmslciwad01.regence.com,
extn-cbc-dev.regence.com" -auth-schemes="digest,ntlm,negotiate"
https://extn-dev-cbc.regence.com/cbc/Search.do​

should be :

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
--disable-plugins --process-per-site
-auth-server-whitelist="vmslciwad01.regence.com,
extn-cbc-dev.regence.com, extn-dev-cbc.regence.com"
-auth-negotiate-delegatewhitelist="vmslciwad01.regence.com,
extn-cbc-dev.regence.com, extn-dev-cbc.regence.com" -auth-schemes="digest,ntlm,negotiate"
https://extn-dev-cbc.regence.com/cbc/Search.do​

Indeed, this is probably related to the browser.

Best Regards,
Patrick

[Duc Tran]

Good Morning Patrick,

I copied the command that you corrected and ran that, but still getting the same result from the Chrome browser.  The agenttrace.log on IWA server showed that it generated SMSESSION cookie for my network/Active Directory user ID but after the browser redirected back to the target it then get redirected back to the IWA server again and goes into loop:

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --disable-plugins --process-per-site -auth-server-whitelist="vmslciwad01.regence.com, extn-cbc-dev.regence.com, extn-dev-cbc.regence.com" -auth-negotiate-delegatewhitelist="vmslciwad01.regence.com, extn-cbc-dev.regence.com, extn-dev-cbc.regence.com" -auth-schemes="digest,ntlm,negotiate" extn-dev-cbc.regence.com/cbc/Search.do

What other thoughts do you have?  The strangest thing about this is that the Chrome browser works perfectly fine if it is redirected to the old IWA auth scheme so the only other possible explanation is that it does NOT accept the SMSESSION cookie from the new IWA auth scheme server/host.​

[Duc Tran]

Hi Patrick,

I want to thank you for spending the time to help.  After much troubleshooting and researching through old documentations I finally got this resolved.  This whole issue with the new IWA server on the new IWA server (Windows 2016 Server / r12.52 webagent) ​not setting the SMSESSION cookie for the Chrome and FireFox browser is caused by the IIS application pool not having the right permission or correct service identity.

With the old IWA server that we have which runs on Windows 2008 with r12.0 webagent, I did not need to change the IIS app pool identity to run on a service account but instead it was running under the default "ApplicationPoolIdentity".  With the new IWA server on Windows 2016 Server, I have to change the .NET app pool to run under a specific AD service account and grant additional local policy rights to this account.

After making this change and rebooting the server, now both FireFox and Chrome browsers work with the new IWA auth scheme.

Thanks again for spending the time to help.

Regards,

Duc Tran