May 14, 2012 at 6:59 am
I currently use a domain login to get to reporting services either by logging on as Adminstrator so I can manage up Reporting services and as a reportuser where a person can view reports but not do anything else like an Administrator can. The idea is our sales managers' to log on to Reporting services with their own account. It was mentioned to me by my manager that he wants a login page created for this. That got me to thinking if I do this how would I get on to the page as an administrator to do what I need to do. I would like to know what anyone suggestions are for doing this. I don't really know how I would go about doing this and what kind of problems this may cause. Any suggestions?
May 14, 2012 at 7:06 am
Why introduce a login page when SSRS automatically handles the login methods via AD?
I can understand doing this as an external facing SSRS solution but not when its internal due to granting external users access to SSRS.
The best way to manage SSRS security is to use AD groups, and then you just assign that group the access it needs in SSRS so you can hide folders/reports etc.
If you do want to do a custom login page, you will need to look at forms based authentication or custom authentication
May 14, 2012 at 10:54 am
My question how would I set up AD is that set up on the server the report is running on or somewhere else?
Also if i set up my own login page which I'm sort of leaning towards because of the way our system is set up. Is there a way to differentiate when I, the Administrator logs in and the way the other, regular users can log in. I want to be able to go in as an administrator and change things if needed on Reporting Services but the other users don't get access to all of this. Sort of like how Reporting Services is set up now.
May 14, 2012 at 12:30 pm
Are you in a domain environment or are you in a workgroup environment? If domain then you will have AD setup already which manages your user accounts. Another way to know is do you use your windows accounts to connect to SQL or do you need to use SQL authentication?
In custom/forms based you use impersonation, so you would have an account that logs in to the app as administrator which then impersonates your ssrs admin user and gets the same rights.
May 14, 2012 at 1:09 pm
It is SQL authentication for the sql servers. So how would that be set up?
That's interesting about the impersonation. Didn't know you could do that.
May 15, 2012 at 1:02 am
if its all SQL authentication and your not in a domain environment then you will need to go down forms/custom authentication and create a number of accounts on the SSRS box for the impersonation to connect to SSRS as.
How do you login to your workstation, do you have a prefix at the begining like COMPANY\Username or is it MACHINENAME\Username?
May 15, 2012 at 7:16 am
anthony.green (5/15/2012)
if its all SQL authentication and your not in a domain environment then you will need to go down forms/custom authentication and create a number of accounts on the SSRS box for the impersonation to connect to SSRS as.How do you login to your workstation, do you have a prefix at the begining like COMPANY\Username or is it MACHINENAME\Username?
I login as MACHINENAME\Username
May 15, 2012 at 7:19 am
So yeah your in a workgroup environment with no AD, so you will need to write a custom authentication methods which impersonate accounts which exist on your SSRS server.
May 15, 2012 at 7:34 am
OK when you say create accounts on the SSRS box, do you mean login to my reports site as Admin and create the accounts or is this done through SQL Server Man. Studio? Just want to make sure I understand you correctly.
May 15, 2012 at 7:38 am
You will need to create a number of windows accounts in computer manager, then grant them the nessesary access they need in SQL, then grant them the nessesary access the need in SSRS.
Say you have a number of people (we will call them numbers 1-10, 11-20, 21-30) say 1-10 need access to 100 reports then in the impersonation, you will do, when user1 connects to the forms authentication page, then impersonate MACHINENAME\SSRSUser1-10, as the user MACHNENAME\SSRSUser1-10 has access to the 100 reports in a number of folders across your SSRS website.
May 15, 2012 at 8:18 am
OK so I'm assuming I'm creating them in computer management on the server the report is on, right?
So I also assume I would need their password since I'm impersonating? Sorry for so many questions but I haven't done this before and want to make sure I understand.
May 15, 2012 at 8:21 am
No, not to worry, I'm in the same boat at the moment where we are designing a internet facing SSRS solution for our new SaaS product which is in development so I totally understand what your going through, its been a nightmare as I'm only ever used to doing SSRS on a AD domain and keeping it within that domain.
May 15, 2012 at 9:50 am
Did you know the answers to these questions:
OK so I'm assuming I'm creating them in computer management on the server the report is on, right?
So I also assume I would need their password since I'm impersonating?
May 15, 2012 at 11:58 am
I guess you aren't coming back. I did notice something else when going into SSRS Report Manager as Administrator I have the abililty to set up 'Site-Wide Security' or system role assignments, item level roles, etc. Would this be something I could do as far as setting up users with their own accounts or does that get to risky?
May 16, 2012 at 1:08 am
Sorry I finish work at 4 UK time and dont have time on the forums due to family committments.
Yes you will create them in computer manager
Unsure on the passwords part, I would of thought so as it requires authentication, our development team are taking care of all that for me so unsure.
Personally I remove all accounts from any system level role and add in the one group which contains all the DBA's and SSRS Admins accounts so only them specific people can change security and system level properties.
One thing I would say is, when you have created the user accounts, create a group, then assign the users to that group, that way your managing security at the group level and not at the user level, so you only have to change (going off the example of 1-10, 11-20, 21-30) 3 groups permissions instead of 30 users permissions, makes life that little bit easier.
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply