Report Builder 3.0 - Dataset Credentials Do Not Work

Question

I am using SSRS 2008 R2 and Report Builder 3.0. I set up a shared data source via the browser (http://myserver/reports/) wherein the "credentials are stored securely in the report server" to use with multiple reports. Testing the connection via the browser works.

Now, I fire up Report Builder 3.0. I start a new report and "Add Data Source". I select the "Use a shared connection", browse to the server, and select the above data source. Click "Test Connection" and all is well.

I then try to "Add Dataset". In the dialog, I select "Use a dataset embedded in my report", I select my data source added above, type in the SQL string and click OK. The "Enter Data Source Credentials" appears. No matter what permutation of valid domain (like the domain admin account and others) or SQL Server (like the 'sa' account) credentials plus checkboxes I use, I get an "Unable to connect to data source".

Security settings on the shared data source allow BUILTIN\administrators and domain\administrator all roles. The data source does work, as some legacy migrated reports run fine. Report Builder says the data source connects okay. But, I cannot create new reports, nor modify existing ones.

Any suggestions?

Rift

Answer 1

After much gnashing and wailing seems like Report Builder uses information in definitions in Report Server to then run queries locally by itself, and not through Reporting Services.

My mistaken belief was that when I did something like Refresh Fields when setting up a Dataset, Report Builder was going through Report Services to get the relevant output and/or metadata. This seems to not be the case.

I had defined the connection string of the shared data source as Data Source=(local);Initial Catalog=<database name>. Now, this works when you are in Reporting Services' browser interface, but Report Builder seems to read the connection string and use it for itself. Reporting Services on my local development machine does not have any of the setup on the target server running these reports, so anything I would use will fail.

Changing the connection string to Data Source=<server name>;Initial Catalog=<database name>, instead of localhost, allowed Report Builder to work properly. (RB still popped up "Enter Data Source Credentials". I used my Windows credentials, which is a valid login on the target server.)

Rift

I had a similar problem and your answer pushed me in the right direction. The difference was the client installed on the local workstation was the Native Client 10 and the Server had Native Client 11. The connection string on the server had to change the Provider name from SQLNCI11.1 to SQLNCI10.1 to work from the local machine. The final fix was to install the Native Client 11 on the workstation. – Bullring

Cool. Glad I could be the nucleus of a different solution for you! Thanks for adding to it. – Rift

Answer 2

To accomplish what you are attempting, it sounds like you will need to use windows integrated security.

According to MSDN stored credentials are not passed to client applications. They are for use only by the report server for things like scheduled reports.

http://msdn.microsoft.com/en-us/library/ms159736.aspx

I can tell you that the prompt "Enter Data Source Credentials" is looking for SQL authentication, not domain accounts.

Instrumentation

Well, I've used the one "stored securely in the report server" for that data source. And, other valid SQL logins. But, none seem to work. – Rift

Answer 3

Outstanding question and answer. I really appreciate your careful description. I had the same problem. In my case the problem was that I was accessing Report Builder from a machine connected to my home office by VPN. I guess because I was outside of the Windows network of the home office, RB couldn't authenticate me. Working with a Remote Desktop connected to a machine at the office allowed me to side-step the problem. Your and @RichShealer's answers reminded me that when running the reports from the browser, they're being served up by an inside server machine. This is not the case when running RB, a desktop app.

Quorum