Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Securing Reporting Services Reports


Securing Reporting Services Reports

Author
Message
Luke L
Luke L
SSCrazy
SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)SSCrazy (2.7K reputation)

Group: General Forum Members
Points: 2680 Visits: 6103
gavindux (5/18/2010)
My preferred method to block user's from seeing other peoples data - especially sales and financial data, is using AD logins on the report server. The AD policy forces password changes regularly so its not that easy for others to get in with "other" credentials. My end-users are generally quite IT illiterate so I depend on AD to lock them down and keep out of each others figures. So far its worked well.

But yes, if one of them had to "steal" or guess a login then they would get in to that users data. Same goes for their email or windows profile and documents. Worst case (on SSRS) they get to see one other user's sales figures. The data source they're connecting through is using fixed credentials, with execute on a single SP, so that should be secure enough to block a "hacker" from getting further than that result set.

I didn't want to give them too many user names and passwords to fill in as it does mean more support work for their IT department.


Sorry, I was referring to the method presented in the article. There's no problem using the Global USerid to filter records on a report because that would require the user to know both username and password to actually log in as that user. I was referring to the use of a parameter to store the username and filter based only on the parameter as the only security method in place. With the method in the article I can open the website via a URL and add &rs:Command=Render&User=domain\userwithprivs and bingo I'm in. I'm thinking that a SOX or HIPPA (or insert your country's Laws that define auditing regulations) auditor may find some very large issues with this.

This is compounded by the use of domain login names as email addresses in some companies. If I know your email address, then I know your Username so it makes it very easy to defeat it. I now have every piece of information that I need to defeat the security model presented in the article.

-Luke.

To help us help you read this

For better help with performance problems please read this
Raghavender
Raghavender
Ten Centuries
Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)Ten Centuries (1.1K reputation)

Group: General Forum Members
Points: 1059 Visits: 1201
gavindux (5/18/2010)
My apologies - I misunderstood - I thought you meant when executing a report. When deploying that would be credentials of a user that is allowed to publish on the server. Usually a reportserver\admin account, or, sql server sysadmin account, or or whichever accounts have been granted publisher rights are required.


Sorry to trouble you more...how to find out which user has the access to that reports... as we are the admins to that box and also to the SQL Server. But from our account we are failing.

Thanks and Regards!!

Raghavender Chavva
gavindux
gavindux
SSC Rookie
SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)SSC Rookie (30 reputation)

Group: General Forum Members
Points: 30 Visits: 211
Forgetting about whether you can publish the report, are you able to login to the http://yourreportserver/reports site?
Wes W.
Wes W.
Grasshopper
Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)Grasshopper (16 reputation)

Group: General Forum Members
Points: 16 Visits: 255
Personally I'm not a fan of even allowing someone any access to the report directory if they don't have sufficient rights for all the reports in the directory. For rights management of report data in reports, we use SSAS databases with appropriate segregation of ActiveDirectory roles for each database component (dimension, cube, etc.) to limit the data each AD role returns to the reports.

In summary, users either have access to a report directory and all reports within the directory, or none at all.
GoofyGuy
GoofyGuy
SSC-Addicted
SSC-Addicted (409 reputation)SSC-Addicted (409 reputation)SSC-Addicted (409 reputation)SSC-Addicted (409 reputation)SSC-Addicted (409 reputation)SSC-Addicted (409 reputation)SSC-Addicted (409 reputation)SSC-Addicted (409 reputation)

Group: General Forum Members
Points: 409 Visits: 971
Maybe I'm missing the point of this article. Why not use the native SSRS security model instead? Our shop relies upon it, in conjunction with the AD-based report user groups we've created to limit user access rights to specific folders and reports.

Rather than administering individual users' access rights to individual reports, without benefit of a programmatic interface, rights are administered at the group level, using web-based AD interfaces, such as Quest's ActiveRoles Server.
SQLRNNR
SQLRNNR
SSC-Insane
SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)SSC-Insane (21K reputation)

Group: General Forum Members
Points: 21075 Visits: 18259
Interesting solution to security for SSRS. I think I would weigh heavily the comments made in this discussion when looking to secure reports in SSRS.



Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw

thomas.briscoe
thomas.briscoe
Grasshopper
Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)

Group: General Forum Members
Points: 19 Visits: 87
Nice article. We have hundreds of reports with tens of agencies accessing those reports restricted to only their data. My solution to this was creating a stored procedure which looked up their user id from this parameter and returned their coresponding agency. There was an agency table with a listing of agencies and users and their user ids.
Then in the dataset that returned the report data, only the data for agency to which the user belong was returned.
This allows many users from different agencies to view the same report, but with only their data.

(58.30115757480578, -134.4143772125244)
dforck
dforck
SSC-Enthusiastic
SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)SSC-Enthusiastic (100 reputation)

Group: General Forum Members
Points: 100 Visits: 111
Seems like a good way to hide protions of a report from specific people, but i dont' understand why you would hide an entire report when you can just hide it using SSRS's security.
rbarbati
rbarbati
Forum Newbie
Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)Forum Newbie (9 reputation)

Group: General Forum Members
Points: 9 Visits: 69
We implemented a solution that combines the features mentioned here, along with a table sub-struture and temporary login tokens.
The user is detected, we drill into the transactional data itself to determine if they should have access (as our security model is quite complex with multiple user roles and such), we enter a token along with userID into a table and that is the validation key.

It is all sproc driven and adds little overhead to the reports themselves once established.

The URL backtracking mentioned above is a key factor and is why we introduced the tokens.
If not the same user, and not within a 30 min period, the URL itself actually expires. (but easily regenerated in the background for any valid user on return - if needed)

There is some setup and coding, but it's a nice combination of the different topics mentioned in this article.


Good reading - thanks !
JP-470
JP-470
Grasshopper
Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)Grasshopper (12 reputation)

Group: General Forum Members
Points: 12 Visits: 76
This method is good for a small and stable pool of users and reports. However, we find it more practical to control access through AD groups. We are too short handed to administer additions and deletions of individual access for a couple thousand users against several hundred reports.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search