HTML to Windows Authorization ends in 403 error on IE only.

[Taylor Swanson]

We have been working on an issue at my company for about two weeks now in which when a user attempts to log in via the HTML Authorization scheme on SiteMinder v12.51 that then goes to authenticate  through windows authorization ends in the user getting a 403 error when done on Internet Explorer (any version) but not on other browsers. We are not able to solve the issue by switching browsers so it has been laid down to find this bug and fix what might be causing this issue. We have this setup using SiteMinder and its hosted from an Apache server (we dont think this is the issue since its working with other browsers). In another test reversing the operation from windows authorization then proceeding to the HTML authorization the process works and does not end in a 403 error for the user. This problem only persists when going from HTML to Windows authorization, if anyone has any information on this issue or an idea I'm all ears as I have found nothing in two weeks.

 

Updates:

I have also tried running the Trace function on SiteMinder to identify if there were any HTML header errors passing between the web agent and SiteMinder and this was not the case. Not sure if this matters but they are also using the same host and context root.

[Ujwol]

Hi Taylor,

 

This almost certainly looks like a browser issue.

My suggestion is to capture http header trace (fiddler trace) and also IIS failed request logs (for return code 403) and compare what is the difference between the working and non working scenario.

It looks to me that in the non working scenario, the browser is not sending back the authorization header properly.

 

Cheers,

Ujwol

[Taylor Swanson]

Hi Ujwol,

 

Our team has previously tried running a trace to check the HTML header in both situations with no differences being found, also we are using an Apache web server and not using IIS, so I have no logs to check for the 403 with. An element that was left out of the original post though was the fact that this behavior is spawned from first visiting a site that uses the HTML authentication then within the same browser (IE) session visiting a site that uses Windows based authentication. This is the point in the scenario that the user see a 403 page and we have not been able to identify what is causing it. If we reverse the situation and open a new browser window (within IE) and visit the Windows based authentication site first and then the HTML authentication site second the user does NOT see a 403 page. I hope this might help clarify the situation we are having here.

 

Regards,

Taylor

[Ujwol]

Hi Taylor,

 

So your current webserver is IIS right ?

and you can still reproduce the issue ?

 

If so, why are you not able to capture the failed request tracing from IIS ?

Even if it is Apache, you should be able to configure the detailed tracing and get some more info as to why it is sending the 403 response.

 

Cheers,

Ujwol

[Taylor Swanson]

Hi Ujwol,

 

     The server is an Apache server not IIS and we can reproduce the issue, I can also confirm the traces are not coming back with any information pertaining to header mismatches and 403 error source identifiers. After a meeting this morning we are investigating the possibility that this error could be coming from the FCC file we are using for the HTML login. We were also able to confirm yesterday that this error occurs in any environment (for us) in which the HTML authentication comes before the Windows, regardless of the application being logged into.

 

Regards,

Taylor