RS, SharePoint and Forefront UAG Series – Part 2 (Operational Reports)
Part 1 – Intro
Part 2 – Operational Reports (Classic RDL Reports) (you are here)
Part 3 – Power Pivot Gallery (Silverlight)
Part 4 – Export a Power View Report to PowerPoint
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.
From a fiddler trace, the patter we saw was the following just repeat itself:
# Result Protocol Host URL Body Caching Content-Type Process Comments Custom
368 200 HTTPS sptest.uaglab.com /_layouts/15/ReportServer/RSViewerPage.aspx?rv:RelativeReportUrl=/Reports/Company%20Sales%20SQL2008R2.rdl&Source=https%3A%2F%2Fsptest%2Euaglab%2Ecom%2FReports%2FForms%2FAllItems%2Easpx 96,899 private text/html; charset=utf-8 iexplore:3980
369 200 HTTPS sptest.uaglab.com /InternalSite/logoffParams.asp?site_name=sptest&secure=1 1,415 private,no-cache text/javascript iexplore:3980
370 304 HTTPS sptest.uaglab.com /InternalSite/scripts/applicationScripts/whlsp15.js 0 no-cache iexplore:3980
371 200 HTTPS sptest.uaglab.com /InternalSite/sharepoint.asp?site_name=sptest&secure=1 3,961 private,no-cache text/javascript iexplore:3980
372 200 HTTPS sptest.uaglab.com /InternalSite/?WhlST 30 no-cache iexplore:3980
373 200 HTTPS sptest.uaglab.com /InternalSite/?WhlSL 30 no-cache iexplore:3980
374 200 HTTPS sptest.uaglab.com /Reserved.ReportViewerWebPart.axd?OpType=SessionKeepAlive&ControlID=b19d27e5e8254cb69789caaa773937a7 122 private text/plain; charset=utf-8 iexplore:3980 <-- POST via AJAX call - x-requested-with: XMLHttpRequest
375 200 HTTPS sptest.uaglab.com /_layouts/15/ReportServer/RSViewerPage.aspx?rv:RelativeReportUrl=/Reports/Company%20Sales%20SQL2008R2.rdl&Source=https%3A%2F%2Fsptest%2Euaglab%2Ecom%2FReports%2FForms%2FAllItems%2Easpx 514 no-cache; Expires: -1 text/plain; charset=utf-8 iexplore:3980
376 302 HTTPS sptest.uaglab.com /_login/default.aspx?ReturnUrl=%2f_layouts%2f15%2fReportServer%2fRSViewerPage.aspx%3frv%3aRelativeReportUrl%3d%2fReports%2fCompany%2520Sales%2520SQL2008R2.rdl%26Source%3dhttps%253A%252F%252Fsptest%252Euaglab%252Ecom%252FReports%252FForms%252FAllItems%252Easpx&rv:RelativeReportUrl=/Reports/Company%20Sales%20SQL2008R2.rdl&Source=https%3A%2F%2Fsptest%2Euaglab%2Ecom%2FReports%2FForms%2FAllItems%2Easpx 583 private, no-store text/html; charset=utf-8 iexplore:3980
377 302 HTTPS sptest.uaglab.com /_windows/default.aspx?ReturnUrl=%2f_layouts%2f15%2fReportServer%2fRSViewerPage.aspx%3frv:RelativeReportUrl%3d%2fReports%2fCompany%2520Sales%2520SQL2008R2.rdl%26Source%3dhttps%253A%252F%252Fsptest%252Euaglab%252Ecom%252FReports%252FForms%252FAllItems%252Easpx&rv:RelativeReportUrl=/Reports/Company%20Sales%20SQL2008R2.rdl&Source=https:%2F%2Fsptest.uaglab.com%2FReports%2FForms%2FAllItems.aspx 617 private text/html; charset=utf-8 iexplore:3980
378 200 HTTPS sptest.uaglab.com /_layouts/15/ReportServer/RSViewerPage.aspx?rv:RelativeReportUrl=/Reports/Company%20Sales%20SQL2008R2.rdl&Source=https%3A%2F%2Fsptest%2Euaglab%2Ecom%2FReports%2FForms%2FAllItems%2Easpx 96,899 private text/html; charset=utf-8 iexplore:3980
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 thread, 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.
Workaround 1: Response.SuppressFormsAuthenticationRedirect
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 Response.SuppressFormsAuthenticationRedirect property. This article 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.
<script runat="server">
protected void Application_BeginRequest() {
if( FormsAuthentication.IsEnabled
&& Context.Request.RequestType == "POST"
&& Context.Request.Headers["x-requested-with"] == "XMLHttpRequest"
)
Context.Response.SuppressFormsAuthenticationRedirect = true; }</script>
The default path to the global.asax in our SharePoint deployment was: C:\inetpub\wwwroot\wss\VirtualDirectories\sptest.uaglab.com5196\. Reports were able to render properly at this point.
From fiddler, it looked as we expected it to, without the authentication loop.
# Result Protocol Host URL Body Caching Content-Type Process Comments Custom
13 200 HTTPS sptest.uaglab.com /_layouts/15/ReportServer/styles/1033/sqlrvdefault.css 3,362 max-age=31536000 text/css iexplore:4916
14 304 HTTPS sptest.uaglab.com /InternalSite/scripts/applicationScripts/whlsp15.js 0 no-cache iexplore:4916
15 200 HTTPS sptest.uaglab.com /InternalSite/sharepoint.asp?site_name=sptest&secure=1 3,961 private,no-cache text/javascript iexplore:4916
16 200 HTTPS sptest.uaglab.com /InternalSite/?WhlST 30 no-cache iexplore:4916
17 200 HTTPS sptest.uaglab.com /InternalSite/?WhlSL 30 no-cache iexplore:4916
18 200 HTTPS sptest.uaglab.com /Reserved.ReportViewerWebPart.axd?OpType=Resource&Version=11.0.3401.0&Name=ViewerScript 161,670 public; Expires: Fri, 23 May 2014 13:00:56 GMT application/javascript iexplore:4916
51 200 HTTPS sptest.uaglab.com /Reserved.ReportViewerWebPart.axd?OpType=SessionKeepAlive&ControlID=bee8fb2bf93e4e3bb3fd52acfcc3b7e7 122 private text/plain; charset=utf-8 iexplore:4916
52 200 HTTPS sptest.uaglab.com /_layouts/15/ReportServer/RSViewerPage.aspx?rv:RelativeReportUrl=/Reports/Company%20Sales%20SQL2008R2.rdl&Source=https%3A%2F%2Fsptest%2Euaglab%2Ecom%2FReports%2FForms%2FAllItems%2Easpx 82,166 private text/plain; charset=utf-8 iexplore:4916
Workaround 2: Web Application Proxy
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.
Web Application Proxy (WAP) Information:
Working with Web Application Proxy
https://technet.microsoft.com/en-us/library/dn584107.aspx
Installing and Configuring Web Application Proxy for Publishing Internal Applications
https://technet.microsoft.com/en-us/library/dn383650.aspx
Plan to Publish Applications through Web Application Proxy
https://technet.microsoft.com/en-us/library/dn383660.aspx
Step 3: Plan to Publish Applications using AD FS Pre-authentication
https://technet.microsoft.com/en-us/library/dn383641.aspx#BKMK_3_2
These TechNet articles include links to a complete walk-through guide to deploy a lab or POC environment with AD FS 2012 R2 and Web Application Proxy.
Getting Started with AD FS 2012 R2
https://technet.microsoft.com/en-us/library/dn452410.aspx
Overview: Connect to Applications and Services from Anywhere with Web Application Proxy
https://technet.microsoft.com/en-us/library/dn280942.aspx
Adam W. Saxton | Microsoft SQL Server Escalation Services
https://twitter.com/awsaxton