December 11, 2015 at 8:07 am
So i met with the Dev team yesterday to gather requirements for the SSRS installation on 2014. Right now the 2008 is sitting on its own box, and all report requests go to that box which has its own IIS on it.
We'd like to use the load balancer instead, and that part seems pretty doable.
The question i have is a front-end question. Currently each report has a list of AD accounts that can browse or run that report. These AD accounts are not AD groups, but individual people. Its a mess. There is no rhyme or reason, people were granted access to things if they asked, or the developer set the access to all domain users. Right now the more 'secure' reports are sometimes open the whole domain as well.
I want to tighten this down, and they agreed. They have their own internal permission engine that grants people access to different parts of the internal website. I'm not sure how to set up SSRS's IIS to work with this. Do i need to just have it open to the world and depend on their front end to control who can see what, is there any way to prevent casual browsing if someone figures out the backend SSRS URL?
December 11, 2015 at 11:50 am
I have worked with a system something like that before. We locked down the SSRS server by only allowing the service account that the security application ran under to have access.
Perhaps this is something you could explore/ask about.
December 11, 2015 at 12:05 pm
Brad Feaker-195979 (12/11/2015)
I have worked with a system something like that before. We locked down the SSRS server by only allowing the service account that the security application ran under to have access.Perhaps this is something you could explore/ask about.
How was that accomplished? Impersonation?
I'm going down the path of implementing a security extension. This should be interesting since my usual 'programming' is done in PowerShell.
December 11, 2015 at 1:20 pm
No impersonation - the service account had 'Browser' permissions on the SSRS folders and it handled all the security access and report access via a custom web page and database. It was role based (not database roles - our custom ones) to allow us to better match reports to the groups of users.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply