4

I'm dealing with a scenario where SSRS is being provided to remote clients on a different domain. We've discovered that they can launch Report Builder (a ClickOnce application) from their Report Manager browser session, but RB then uses their local credentials when trying to do anything (e.g. hit a datasource) in the RB session.

This article (http://technet.microsoft.com/en-us/library/ms365173(v=sql.105).aspx) seems to indicate that it won't be possible to hack our way around this; whereas this one about Azure (http://msdn.microsoft.com/en-us/library/windowsazure/dn189155.aspx) appears to indicate that a local RB session may be able to interact successfully with Azure - does this suggest there's a glimmer of hope?

We are currently running SQL 2008 R2.

sasfrog
  • 141
  • 1
  • 3

1 Answers1

1

I cant comment (not enough rep on this site) so I have to submit this as an answer.

  1. I have successfully set up a SharePoint SSRS portal using forms authentication (FBA). The SSRS part was not hard - very straightforward actually, just perform the SSRS install as SharePoint integrated. However, the SharePoint FBA part was very painful (not difficult, just lost a lot of hair and sleep over little stuff you didnt think would be necessary and couldnt find straight answers to.)

I know that you can use Report Builder 3.0 to save to a SharePoint site. I have not tried that using the FBA SharePoint portal. I dont work at that company anymore, so I dont have access to test that either. I would think it is very possible though. The portal I set up was accessed by non-domain users, which is why I had to use FBA. I was using SharePoint 2007 and SQL Server 2008 R2.

I know the following link tells of the permissions needed for Report Builder to save to a SharePoint library: http://technet.microsoft.com/en-us/library/dd255209(v=sql.105).aspx

  1. I did find a specific blog post about using Basic Authentication: Link.
    There is also an article on MS technet titled: "How to: Configure Report Builder Access"

  2. Another thing that is worth trying - You can use a domain account for report viewing only, then use the ReportViewer Web service/API/webpart/etc to have a report embedded within a web application. That way, the report connects using the username/password specified, not the user viewing the application. That has worked for an application I helped work on that was exposed on a DMZ web server, but used an SSRS report that was on the internal network. In that case, the SSRS instance was a Native install. If you are using .NET - you can use Visual Studio. It already has controls built in.

The only think I dont know about in this case is the use of Report Builder. Just thought I would mention it because it might help spur some thoughts.

Glorfindel
  • 2,205
  • 5
  • 19
  • 26
Glenda
  • 11
  • 1