This piece took the longest amount of time to narrow down what was going on. This issue was when they were trying to Render a report that was integrated within SharePoint 2013, being accessed by an external client going through a Forefront UAG. The result was that the report would get into this loop. It would almost look like a flicker.
trace, the patter we saw was the following just repeat itself:
What was apparently happening is that every POST request needs to be authenticated in the UAG setting. Not new POST contains the necessary credential. As a result, SharePoint issues a 401 in response to each POST. These are handled by UAG, which does the challenge/response handshake and then sends the final response back to the client. However, for some POST requests (like the ones sent from Reporting Services), the 401 gets modified before sent to UAG. According to this
, the forms authentication module intercepts any 401 and replaces them with redirects.
With a SharePoint Claims configuration, you will have both Forms Authentication and Windows Authentication enabled.
The forms authentication module intercepts any 401s and replaces them with redirects. Since we have Forms and Windows authentication enabled, which according to IIS Manager is not supported, we get this behavior for what appeared to be only the AJAX requests coming from the Report Viewer Control.
There were two workarounds we came up with to avoid this looping behavior and to get reports to work.
Note: Following this workaround will put SharePoint into an unsupported configuration. Please use at your own risk as this has not been tested with other functionality within SharePoint. If you encounter an issue and call support, you may be asked to remove this snippet to continue. Also, installing updates to SharePoint may remove this snippet.
While Reporting Services 2012 uses the .NET Framework 2.0/3.5, SharePoint 2013 uses the 4.5 framework. There was a property introduced in the 4.5 framework, on the Response object, to suppress those Forms Auth Redirects (302). This is the
talks about some of the challenges with light weight services and using jQuery. We added the following snippet to the global.asax. After doing so, the reports loaded fine.
This was mentioned in the Intro post, but I’ll mention it here as well. When setting up the Web Application Proxy, via Windows 2012 R2, we did not encounter any issues with regards to this problem. Reports rendered fine out of the box. No configuration changes were necessary. The win here is that this configuration is fully supported for both the Proxy perspective, SharePoint and Reporting Services. This is definitely the cleaner way to go, with less hassle. This also allowed Power View reports to just work, which I’ll talk about in the next post. I’ll post the information on Web Application Proxy here again for reference.