I am an db admin on the server. I have granted the user with "SYSTEM user" on site setting, "Content Manager" on the Home folder, and also "Content Manager" on the her folder XXX.
However, she cannot deploys her report on BIDS and get this error instead:
The permissions granted to user 'WMSERVICE\xxx' are insufficient for performing this operation
I have gone through many site and most of the suggestion is to run it back as Administrator, or give her a SYSTEM Administrator privilege for the SSRS (this is the last resort that I should consider).
Any ideas?
Two things on SSRS:
SSRS has two permissions, roles and user levels. Giving someone a permssion role of admin to SSRS is not like giving them admin under Active Directory. Just to SSRS. You could always try that and see if that is the issue.
Is the user publishing to multiple locations with the:
Data Source(s)
Data Set(s)
Reports
Or are they self contained in the report itself?
They can tell by going into a Report Project and hitting properties and looking at their screen settings. If they are using 'Shared Data Sources' or 'Shared Data Sets' that adds more levels of complexity to the security issues as you have to deal with their deployment as well. If one of those report folders is different they may be getting denied. For a sub part of the total in which their deployment would tell them which object was failing and were at. Many times I have seen people NOT turn off the default for Data Sources which is root/Data Sources. SSRS can deploy a project, data source, data set, or report and it's dependencies. When in doubt give full access and verify it works, then remove access immiediately. Then trouble shoot deployments. It is probably a folder not being given rights to and then deployment is going for that folder first would be my guess.
Related
I have inherited an SSRS environment which is a mess; Folders named only with numbers, hundreds of reports not accessed in the last 2 months (I checked ExecutionLog), etc..
I wanted to achieve two things…
Because every other day someone asks for read access to random reports, is there any way of making it “public”, meaning anyone can read and open ANY report?
I want to revoke “folder/report creation/move” access to everyone; can it be done without going folder by folder?
Related to it, the other day I found another SSRS box, that had this access?! What is that “everyone” is it a group inside my domain, or is it an SSRS feature that you can make it public so anyone can access?
That Everyone group looks like a domain account that your organisation has created. At least, I have never come across it.
To grant access to everyone that has a windows login, you can use NT AUTHORITY\Authenticated Users and set their permission to just Browser which will prevent creation or modification of Folders or Reports.
Regarding removing permissions from your items, your options are to either go item by item or bulk update the ReportServer database, which is not supported by Microsoft. You break something, you're one your own.
A big thing you will need to watch out for with opening up every report to every user is whether or not there is any confidential or sensitive information in any of the reports. Your organisation will not want low level staff looking at executive, cross company summaries nor will HR want their reports visible to anyone other than themselves.
You can export ALL permissions from SSRS using PowerShell.
I've also detailed a script that allows you to revert every folder to "inherit parent security" so you can control every folder by simply setting the home folder security. Sorry for the shameless plug but I blogged about both in April on SQLShack actually Managing SSRS Security using PowerShell
Both scripts are in that post. I hope that helps
Our IT Dept gave me an SSRS 2016 Dev Instance to play with. But I have two things that I need to figure out, as I've hit a dead end on:
The AppId I need to run our subscriptions under. It's needed to be setup on the SSRS Server to allow Local Login or the reports would not work.
Can some explain why we would need to allow login locally? Or even if it's the correct way to handle it, or should I be setting up something different for the AppId to work correctly?
I also need to be able to setup shared schedules. However when I click the settings gear, I only have 'My Subscriptions', and I understand I need 'Site Settings' to show up here.
What permissions do they need to setup in order for me to gain access to Site Settings?
Sorry, I'm not sure how to answer the first one. I think because SSRS is an additional service external of SQL Server it needs a local SQL Server login. Not really my forte.
By default there is a BUILTIN\Administrators role. The following link will describe who gets placed in the BUILTIN\Administrators role. Once you're in there, you can get to site settings and add your own security settings and shared schedules.
BUILTIN\Administrators info link
Hope this helps.
We have 3 plants all interconnected with high speed WAN. Each plant has it's own SQL server (for it's own applications), but people from all three plants need to run reports on each server. If we host reports locally at each site and point to remote DB's, performance is terrible. IF we logon to SSRS remotely, performance is acceptable as only the screen rendering is across the WAN link, but then employees have to go to three URL's
The most heavily used SSRS server (plant A) has a front-end that is part of 3rd party's product. It has good user access control and lets us control access at the report level. From what I understand, the native SSRS web UI can only control access at the folder level, so we'd end up with huge set of folders to get correct level of access control granularity.
I did think about building my own BI front end. This would present available reports to a user based on a UserID/EmployeeID tuple in a custom table. When the user clicks a report it would simply navigate to the relevant URL (at any site - e.g. http://PlantB.com/reports/report1) (had to put on the .com to satisfy editor.
This did get me thinking: does anyone know of a commercial product that gives a single front end to a farm of SSRS servers. It's nothing to do with load balancing, just a single UI to control access to, and provide a single launchpad for users. So when UserA logs in, they see reports that they are allowed to run. If they are at Plant A and running a report located at plant B, it would simple point to http://PlantB.com/reports/report1
I googled it a bit, but didn't turn up anything
Regards
Mark
I think SharePoint would do the job. You could link to Report Manager reports or folders, add Web Parts to show reports in a SharePoint page, or fully integrate a new SSRS instance with SharePoint.
I'm having trouble figuring out how to setup user access rights for project portals in TFS 2010.
The permissions granted to user XXXXXXX are insufficient for performing this operation (rsAccessDenied)
I've tried adding the user to the various admin groups in TFS but the problem seems to only be related to Reporting Services permissions.
I mapped this user to the RSExec role in the RS databases as well as made sure they had access to the IIS virtual directory. I've tried several of the solutions found through Google but many of them are for previous versions of TFS/RS and the options don't even apply, others don't seem to work at all.
Ideally I would like to add an entire domain group to the entire project collection so that they can access any project portal underneath it, I don't want to have to setup custom permissions on each project, let alone various web parts.
Use this tool: http://tfsadmin.codeplex.com/ to administer TFS/SharePoint/SSRS in a consolidated interface.
I am developing SQL Server Reporting Services (SSRS) reports on SQL Server 2008 R2 and using Report Manager as a method to demonstrate and test reports. I am looking for a way to allow users of the same domain to connect to the Report Manager and run reports via a browser (not SharePoint) without letting the user have too much access to the data source. I currently have each user listed as db_owner for the database that the datasets and data source are associated with. I would like to limit this access and I have tried db_datareader but this level does not allow the user to run the reports and gives the user this error: “Cannot create a connection to data source 'DBname'. (rsErrorOpeningConnection)”.
My method of adding a user to The Report Manager site: I select the ‘Security’ tab under ‘Site Settings’ and then select ‘New Role Assignment’ adding the user as a ‘System User’. I then select ‘Folder Settings’ on the toolbar and again select ‘New Role Assignment’ adding the user as a ‘Browser’. I have tried adding a user as a ‘Content Manager’ but they still have the same error when it comes to the data source.
My method of adding a user to the data source: select new login from the Security tab for the server, add domain\username to ‘Login name:’, use Windows authentication and change the default database from master to the database that is the reports data source. I then select ‘User Mapping’ and put a check next to the database that is the data source. In the ‘Database role membership for: DBname’ section I choose db_owner and public is already selected. I have included screenshots below.
My question is what ‘Database role membership’ can I use for SSRS and Report Manager that would not be as broad as db_owner and would have the best security? I have tried db_datareader but then the user cannot connect to the data source when they run the report.
I have researched this question but I have not found any details accept for adding the user as a db_owner as I described. MSDN acts as if the settings in Report Manager are all that you need to set for the user/report to have access to the data source. I have tried only using the Report Manager settings with both settings for a data source, shared and imbedded with no luck.
Thank you in advance
Typically, the data sources in SSRS will be set to use a fixed account, either a Windows account or SQL authentication. This account should be given minimal privileges to the database: db_datareader is common.
Then security to the report is controlled through Report Manager as you describe above. this avoids the need for changing security on the database itself with changes in user permissions.
But the approach you describe above should work as well. The error you see when the user has db_datareader access is surprising if your query is a standard SQL query selecting from tables. If you are using Stored Procedures, you need to grant access to those as well. Use a test user account that is set to db_datareader; see if you can connect and execute your query through SQL Server Management Studio.
Depending on your security requirements, I would use a dedicated account for database access from the reports, say "ReportReader." Develop and test your reports accessing the databases as this user, and make sure the user has minimal access, read-only and/or limited to only the tables or procedures they need to execute.
The credentials used to access the database are set in the properties of the datasource. This is one reason that Shared datasources are often used, and the reports are linked to the shared datasources:
The screenshot shows a SQL server authenticated account in use. This could just as easily be a fixed Active Directory account; check the "Use as Windows credentials when..." in that case.