设置对需要登录数据源的 SSRS 报告的访问

Question

I have a report that accesses sensitive data and I'm required to have the user log in to the SSRS portal and then again into the data source to make sure the data isn't viewed by the wrong staff.

I feel like I've tried everything at this point, but no matter what I try I cannot access a data source by logging in to it from an SSRS report. I've tried:

• Logging in with a windows authenticated db_owner account. Produces "Cannot create a connection to data source" error without any other info.
• Logging in with a SQL authenticated account with select permissions to the view used by the data source with the same result.
• Using current users credentials, same result.
• I've enable remote errors on SSRS, but cannot locate a log of errors and the errors produced on SSRS portal have not changed.
• I've read just about every tutorial about creating logins and users and how to set them up to access data sources.
• Voodoo
• Psychics
• Therapists

All users have access through to the data when i run a select statement in SSMS, so I'm stumped. I've messed around with giving explicit rights to Connect, Select, Authenticate for the Server, DB, view and still no luck.

Answer 1

Are your users in Active Directory, or are you using SQL Authentication? Because if your users are in AD you can do this easily. I think you need the SSRS in Native Mode not SharePoint mode too, but I'm not 100% certain about that.

1. Create an AD group to hold privileged users, I'll call it MyOU\\SSRSViewers
2. Put all the users who can access this sensitive data in this group
3. In SSRS, in the security settings for the reports, data sets, and data sources, give this group read or read/execute permissions
4. In the database create stored procedures to access your sensitive data (you can give data_reader access instead, but if you want to lock down data then access through stored procedures is much easier to control).
5. In the database, create a USER for the MyOU\\SSRSViewers group. At the server level users need PUBLIC role, this lets them see the server at all. They probably already inherit that from elsewhere, but if not you can tie it to this group, too.
6. Grant EXECUTE permission on those stored procedures to the MyOU\\SSRSViewers user (it's a group, but it looks like a user in SSMS, don't worry)
7. Create or modify your report data sources to use WINDOWS AUTHENTICATION method and data sets to call the stored procedures to get the data instead of SELECT statements.
8. Make sure you don't have any explicit deny permissions on the data in question, or if you do at least test them very carefully, because they can mess up this access (by denying access to somebody who should have it, not by leaking your data)

If you do all this, here's how access works - when a users first goes to SSRS to view a report, SSRS will check to see if the user has permission to see the (empty) report. If they are in the group (or have permissions another way, so this is hard for a developer to test on their own machine) they get the empty report.

SSRS then checks the data source (which has no credentials!) to see if they can use it. Again, if in the group, yes. They still don't have data, but they can get the connection details. If they can, SSRS will pass a token from their windows session to the database to see if they can actually get the data.

If they make it this far, SQL will only let them execute the stored procedure (and get the data) if they are in that group with EXECUTE permissions on that stored procedure.

The users don't see these logins, the browser is automatically forwarding their login tokens (not credentials), but authorization is checked at every step and is very secure.

A few notes: First, your SSRS server has to be in a trusted zone for this to work smoothly, if it is then the browser will pass authentication tokens to SSRS seamlessly. If not, they'll have to "log in" to SSRS every time, which gets old fast. Set this with your Group Policy.

Second, some configurations may include 2-hop authentication, a problem for ordinary NTLM. You may need to set up Delegated Constraints to make this work smoothly.

I didn't do either of these myself, but we had to do both at my company. Neither was particularly painful (or at least the guy who did it didn't complain), but I couldn't tell you how to do either, and I may not be using the ideal descriptions/terms.

Third, this scales well, if you have 3 different types of reports, you can create 3 different groups and your users can be in any combination of groups, getting access to only the data relevant to the groups they are in.