Securing Reporting Services Reports

Question

Securing Reporting Services Reports

Mohamed I.

SSCrazy

Points: 2774
More actions
May 17, 2010 at 8:26 pm

#221112

Comments posted to this topic are about the item Securing Reporting Services Reports
:w00t: !!!GOOGLE IS YOUR BEST FRIEND!!! :w00t:

Viewing 15 posts - 1 through 15 (of 28 total)

You must be logged in to reply to this topic. Login to reply

Alasdair Thomson Hall of Fame Points: 3630 More actions · Answer 1

Good article, I too had to do something similar but the approach I took was to apply the SSRS security and also create a report that queried the security setup on the reports indicating whether the user had access or not. That way the security can still be managed easily using the SSRS security but also gave the customer a 1 stop shop at seeing what reports there are and what they do and don't have access too...

gavindux SSChasing Mays Points: 646 More actions · Answer 2

I used a similar approach to restrict the data that sales reps could see, and limit them to their accounts only.

Pyay Nyein Mr or Mrs. 500 Points: 575 More actions · Answer 3

I normally use SP to restrict what user can and can't see, by passing the user ID as parameter from the SSRS report. The soluting in this article is another way to control the report and user interaction. nice one.

Raghavender Chavva SSCrazy Eights Points: 8669 More actions · Answer 4

I have developed a SSRS project, and checked the preview and working fine.

When I tried to deploy that project at the end it is asking for login and passwords, I dont know which login and password to provide. I have tries to provide my domain account and password, sa password and different ways.

But at last it is showing you are not authorized to view this page.

I have set the url in report properties as http://localhost/reports.

Any help regarding this issue.

Thank You.

Regards,
Raghavender Chavva

gavindux SSChasing Mays Points: 646 More actions · Answer 5

Hi

That looks to me like the credentials of the datasource you published. You can (1) edit the datasource and lock down some credentials on the Report Server or (2) prompt for the credentials and ensure you users have sufficient user/pass access to the data. If you're on Active Directory then you can also use that.

Far to much to discuss here - lots of options - pro's and cons to all.

Luke L SSC-Dedicated Points: 35547 More actions · Answer 6

Just out of curiosity, what keeps a user who is not allowed to view a report from sending another username via a URL, or via some other method? As in the following http://msdn.microsoft.com/en-us/library/ms155391.aspx?PHPSESSID=ca9tbhkv7klmem4g3b2ru2q4d4.

It seems to me this security model is rather easy to bypass. Additionally, it increases the time it takes to maintain the security (having to enter a user in AD and then again in you table). I don't believe it's one I would recommend.

-Luke.

To help us help you read this[/url]For better help with performance problems please read this[/url]

gavindux SSChasing Mays Points: 646 More actions · Answer 7

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.

///EDIT///

I see what youre getting at Luke, in the ERP/Financial systems I am reporting on I will capture the AD login of the user against the resources/accounts/items/GL Accounts. In the query/SP that returns the report data, I filter the USERID.VALUE against that "hard coded" login.

When they login to SSRS with their AD login, I use that as a parameter and only return their records.

Raghavender Chavva SSCrazy Eights Points: 8669 More actions · Answer 8

Hi
That looks to me like the credentials of the datasource you published. You can (1) edit the datasource and lock down some credentials on the Report Server or (2) prompt for the credentials and ensure you users have sufficient user/pass access to the data. If you're on Active Directory then you can also use that.
Far to much to discuss here - lots of options - pro's and cons to all.[\b]

I have tried to Edit the datasource credentials, tried 3 types but no use, still its asking for credentials when I am deploying the project.

Thank You.

Regards,
Raghavender Chavva

gavindux SSChasing Mays Points: 646 More actions · Answer 9

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.

Luke L SSC-Dedicated Points: 35547 More actions · Answer 10

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[/url]For better help with performance problems please read this[/url]

Raghavender Chavva SSCrazy Eights Points: 8669 More actions · Answer 11

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.

Thank You.

Regards,
Raghavender Chavva

gavindux SSChasing Mays Points: 646 More actions · Answer 12

Forgetting about whether you can publish the report, are you able to login to the http://yourreportserver/reports site?

Wes W. SSC Journeyman Points: 84 More actions · Answer 13

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 SSCertifiable Points: 6109 More actions · Answer 14

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.