May 31, 2017 at 7:56 am
Hi all,
Can I setup a DS with shared AD accounts?
So I'm trying to find a way where user can access the DS from a AD group instead of individual accounts
Thanks
May 31, 2017 at 9:26 am
Just set your data source to use "As the user viewing the report" instead of a hard coded name. There is other setup steps you need to do to avoid the double hop problem (that I had, but IT didn't want to allow delegation to a user, so we are stuck connecting as a hard coded user).
Or you can use a hard coded account and then mark off the check box "Log in using these credentials, but then try to impersonate the user viewing the 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.
May 31, 2017 at 10:25 am
thanks bmg002
Can this be done by Service account ?
What will be the best practice to avoid user and setup AD group to manage users
Thanks
May 31, 2017 at 10:53 am
The main concern I have is user not going to access the other parts of Server
May 31, 2017 at 11:13 am
Do you have end users building their own reports? If not, they will only have access to what you give them access to inside the report.
If you do have them building their own report, they will likey be connecting via a shared data source which (if they don't have a SQL account or you don't provide the shared data source to them) will be using their account by default.
I am not sure what you mean by the user having access to other parts of the server. They will only have access to what the SSRS report gives them access to. You can't (as far as I am aware) access other parts of the server from a report. And I am fairly certain that as long as they are not administrators on their local machines, they cannot install software and thus cannot install the BI tools to make their own reports without you knowing.
What we do is have an account on the database that has SELECT permissions on the tables that the report needs to get data from and we try to keep that accounts permissions restricted (ie it cannot insert, update or execute anything). Then we have the shared data source connect to the database as that user. We then store the reports in different folders on the SSRS server and set permissions on the folder based on either AD user (if a small set of users should be able to see the data) or AD group or we have the folder set so everyone can browse it for things that do not contain sensitive data.
This model works well for us, but your environment may be different.
I am not sure if that is "best practice", but since we cannot use any method of connecting to the database as a user (due to the double hop problem and our IT department not allowing us to set up delegation), it is the only option we have.
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.
May 31, 2017 at 12:05 pm
qew420 - Wednesday, May 31, 2017 10:53 AMThe main concern I have is user not going to access the other parts of Server
Do you mean on the database server that is the data source for the report(s)?
Sue
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply