December 4, 2020 at 11:29 am
I am rewriting 100 or so reports on a SSRS 2012 server and migrating to a SSRS 2017(2016) server. I cannot find a good reference showing what site settings security is in relation to our users security groups and how that interacts with Home folder security.
On SSRS 2012 not sure how it was originally setup as it was setup before my time. Recently I removed all but a few SSRS support persons from Home as i didn't want users to use breadcrumbs link to get to Home. It transpired that only a few people out of around 200 could run reports after this, the error reporting their AD user name and RSAccess denied. On a vanilla version of SSRS 2017 users are able to go direct to a URL and run reports although they are not added by Ad group or person in Home foldersecurity.
December 4, 2020 at 3:05 pm
This link will help with what role does what
Permissions can be set at any level system, home, folder, subfolder, report so you need to check each piece of the chain to see where permissions have been applied.
eg I have a root folder of business. Two sub folders of marketing and finance I set permissions at the subfolder marketing for the marketing team and the subfolder finance for the finance team.
The people don’t have access to home or the root business folder, they need to access the marketing folder or finance folder directly via those specific urls.
December 4, 2020 at 9:46 pm
As Anthony Green indicated, permissions can be granted to anything in SSRS.
What I am guessing you did is had it set up with inherited permissions, then removed permissions at the root (home).
Alternately, it could be permissions at the data source level too. You can have SSRS pass the credentials through to SQL when it gets the data OR you can have a specific user account configured to get that data. If it is a specific user account, it could be that user account doesn't have access to the data.
We took a different approach at my workplace - permissions are granted so everyone can see the root level and we restrict on an as-needed bases further down the chain. We found that most reports did not require any special restrictions on them as the information was considered "internally public" meaning that once you are inside the company, that data is not a secret. This makes managing the report permissions a LOT easier. If it is requested to make it a "private" report, we require justification as it is extra administration overhead. PII, financial data, and anything GDPR related would fall under justifiably secret, but it made our job a LOT easier not having to hide all of the reports.
We also learned that a lot of reports that had very specific permissions (like only 3 people in the company apart from the admins can view this report) came about by mis-interpreting the requirements. End user said "Users A, B, and C must be able to see this report" and it was interpreted as "ONLY users A, B, and C can see this report".
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
December 7, 2020 at 9:15 am
Thanks Anthony
I have already browsed that article, I have found the same as you for SSRS 2016 that as long as the URL destination has permission it doesn't matter about the higher hierarchy permissions. However that doesn't seem to be the case with SSRS 2012.
Thanks Graham
Thanks Brian
The way that SSRS security is set up in your workplace is similar to ourselves in that we restrict further down the chain. The reason for removing security at the home folder level was to implement an application that (mirrored the top level folders of SSRS and was able to link to 1 of 2 SSRS servers) as we migrate reports a high level SSRS folder at a time. The issue was that the breadcrumbs allowed users to get to the original home, whereas we wanted them to use the app.
Thanks Graham
December 7, 2020 at 10:05 am
Not played with SSRS since SQL 2012, remember the deployment I did for that had broken and inherited permissions at different levels of the hierarchy depending who needed access to which folder.
URL's where built from the application as to what they would browse to within an iFrame of the app if anyone tried to access the SSRS site directly they would get an access denied error as there where no permissions at the home/root level.
December 7, 2020 at 10:20 am
Hi Anthony
Apologies I am not understanding your second paragraph. Your initial reply stated:
eg I have a root folder of business. Two sub folders of marketing and finance I set permissions at the subfolder marketing for the marketing team and the subfolder finance for the finance team.
The people don’t have access to home or the root business folder, they need to access the marketing folder or finance folder directly via those specific urls.
The above is similar to how I intended the SSRS 2012 to work, which it doesn't via the app. SSRS 2016/17 works as above, but haven't tried accessing directly from Application yet, are you saying this will fail as well although the URL pointed to has permissions for certain users to access?
Regards Graham
December 7, 2020 at 10:29 am
Maybe some miss communication on this.
When I mention SSRS I mean the SSRS portal in browser http://ssrsreportserver/reports
When I mention the application, this is a custom built vb.net application which spawns an iFrame with the direct URL to the direct report.
So in SSRS (in browser) Home - No permissions
Marketing folder - Browser Permissions to DOMAIN\MarketingTeam
Finance folder - Browser Permissions to DOMAIN\FinanceTeam
Any user tries to access http://ssrsreportserver/reports - they should get access denied
User from Marketing tries to access reports/marketing they have access, they try to access reports/finance they get access denied
User from Finance tries to access reports/marketing they get access denied, they try to access reports/finance they have access
This should be the behaviour in all SSRS versions, however not played with the more recent versions so could be mistaken, pretty sure this is how it was in 2012.
December 7, 2020 at 10:45 am
Hi Anthony
Fully concur with your comments, there must be something else going on here as I am using SSRS 2012 and nobody can access reports unless the person or an AD group with that person exists at the Home folder - very strange. Thank you for your replies
Regards Graham
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply