February 10, 2011 at 10:11 am
Hi guys,
I am using the Reporting Service 2008 and I used the Security Tab to define which user (AD-Users) has access to my Reports.
As the access is regulated I didn't want to administrate every user on the Database/Tables as well, so I created a SQL-Login to access the data in the Report.
Now I would like to customize a few Reports meaning filtering the sql for a group of users. I created a AD-SecurityGroup that contain all Users for a filter. In my database I have a view that checks if the user is_meber(group) and filters.
As I have the SQL Login to access it would check if my SQL-User is in that group. So I checked to Impersonate the User after connection to source.
However it seems that the report tries to access the query with the AD-User-Login not with the sql-Login and that is denied.
Is there a way to fix that?
Thx
Mitch
February 11, 2011 at 2:24 am
hi again,
I guess I fixed it.
I gave the AD-Group "public"-rights on the Database, so no rights to select, update, delete.
In the report I call a stored prodecure with my sql-login passing the user_name (DOMAIN\user) as variable.
In the SP I use
EXECUTE AS USER = @user_name and the IS_MEMBER just works fine without giving the User rights to execute or select the SP or Tables selected within.
However I would be glad if you can share with my if that is the usual way to do it, or there is a "best practice" that is different
Mitch
Viewing 2 posts - 1 through 1 (of 1 total)
You must be logged in to reply to this topic. Login to reply