SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Securing Reporting Services Reports


Securing Reporting Services Reports

Author
Message
Mohamed I.
Mohamed I.
SSC Veteran
SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)SSC Veteran (222 reputation)

Group: General Forum Members
Points: 222 Visits: 348
Comments posted to this topic are about the item Securing Reporting Services Reports

w00t !!!GOOGLE IS YOUR BEST FRIEND!!! w00t
Alasdair Thomson
Alasdair Thomson
SSChasing Mays
SSChasing Mays (624 reputation)SSChasing Mays (624 reputation)SSChasing Mays (624 reputation)SSChasing Mays (624 reputation)SSChasing Mays (624 reputation)SSChasing Mays (624 reputation)SSChasing Mays (624 reputation)SSChasing Mays (624 reputation)

Group: General Forum Members
Points: 624 Visits: 506
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
gavindux
Valued Member
Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)

Group: General Forum Members
Points: 52 Visits: 211
I used a similar approach to restrict the data that sales reps could see, and limit them to their accounts only.
Pyay Nyein
Pyay Nyein
SSC-Enthusiastic
SSC-Enthusiastic (151 reputation)SSC-Enthusiastic (151 reputation)SSC-Enthusiastic (151 reputation)SSC-Enthusiastic (151 reputation)SSC-Enthusiastic (151 reputation)SSC-Enthusiastic (151 reputation)SSC-Enthusiastic (151 reputation)SSC-Enthusiastic (151 reputation)

Group: General Forum Members
Points: 151 Visits: 404
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
Raghavender Chavva
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1574 Visits: 1285
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.

Thanks and Regards!!

Raghavender Chavva
gavindux
gavindux
Valued Member
Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)

Group: General Forum Members
Points: 52 Visits: 211
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
Luke L
SSCarpal Tunnel
SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)SSCarpal Tunnel (4.8K reputation)

Group: General Forum Members
Points: 4801 Visits: 6135
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

For better help with performance problems please read this
gavindux
gavindux
Valued Member
Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)

Group: General Forum Members
Points: 52 Visits: 211
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
Raghavender Chavva
SSCommitted
SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)SSCommitted (1.6K reputation)

Group: General Forum Members
Points: 1574 Visits: 1285
[b]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.

Thanks and Regards!!

Raghavender Chavva
gavindux
gavindux
Valued Member
Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)Valued Member (52 reputation)

Group: General Forum Members
Points: 52 Visits: 211
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.
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