May 2, 2012 at 2:14 am
Hi
New to SSRS, setting up some basic reports for users. At the moment, the reports are for different departments. For example, an invoices reports for the Account department.
Now the Accounts department is an Active Directory group, so it was easy to secure the invoices report. But what should I do in the future? Should I set up new AD groups just for SSRS? Or should I use existing groups where possible?
Thanks
May 2, 2012 at 2:36 am
Its all personal preference.
Personally I am in favour of creating brand new groups for SSRS access so that you know exactly what the groups are called and you can give them a meaningfull description in AD. Also you then have somewhat control over who is in the group as you might have 100 people in one group but you only want 10 people from that group to access SSRS so a custom group solves that for you.
It will be a case of weighing up what is nessesary, if a request comes in to say grant all accounts people access then your pretty much good to go with using the accounts group as it is, but if its we only want person X, Y and Z to do it then create a custom AD group.
Groups is by far the easiest way to manage access in SSRS as granting individual users accounts becomes a nightmare
May 3, 2012 at 2:07 am
Thanks. It seems like the same model we use for company folders would do. Certain folders are restricted to people in a a particular area (e.g. HR), others are subsets of existing groups.
May 3, 2012 at 2:11 am
One more point on this. Lets say I have a Sales report. So I give the Sales department access to the report. Does this not also mean they have access to the underlying data, that they could query through Excel?
May 3, 2012 at 2:21 am
depends how you setup the data source which links the report to the data.
if its set at windows authentication then yes they could bypass SSRS and use Excel if they are clever enough to know how to link Excel into SQL.
if its set to use SQL authentication then no unless they know the password or you have granted there AD group access to the SQL server.
you could set the data source up once deployed to use a specific windows account that way you dont grant the AD group access, you dont have a SQL account which can be used, the only way they could connect is if they know the password to the account used in the data source and then run Excel as that user, but if you create the account with a complex password you could mitigate that access.
all depends how you manage security at the SQL server level and the data source level.
May 3, 2012 at 4:00 am
I've used Windows Authentication for all my reports so far, I guess its time for me to investigate using the SQL way. Thanks for all your help.
May 3, 2012 at 4:20 am
Personally I would leave it as Windows, but once you have deployed the data source, change it to use a specific windows account, that has a stupid password that way your not granting the Windows Groups access to SQL.
Should say in the deployed source - Use windows authentication, change it to use a credential stored seculry on the report server then pass in the username and password.
May 15, 2012 at 4:08 am
Hi
I've been trying the method you mentioned, but I can't seem to figure it out. I've deployed then changed the creditanials to SSRS_User, but it won't work for me.
Is there a guide somewhere?
Thanks
May 15, 2012 at 4:42 am
have you granted the user the access to the sql server to run the t-sql/procs that your reports use?
what errors do you get?
May 15, 2012 at 8:38 am
anthony.green (5/15/2012)
have you granted the user the access to the sql server to run the t-sql/procs that your reports use?what errors do you get?
After reading your question, I double checked the permissions.
Hah, it turns out I had not given the SSRS_User premissions on one of the views!
Again, thanks for your help, I think I have it now.
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply