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.
Related
For my company there is a report that ends up in an access database format (.accdb) when it gets to my department. We want to deploy an SSRS with this information. While I was able to do it in Visual Studio the database manager questioned whether this can actually be deployed and work in the server environment. Can this this be achieved?
Are you talking about an Access report, or data inside of Access?
SQL server reports are not built in Access and have absolute nothing to do with Access. The only issue would be then since the report cannot be built in Access, then why attempt to have SQL server open an accDB file for the data source? You would be much better off to simply have Access transfer the table data to SQL server and then continue to use the reports built in SQL server.
So a report in Access has ZERO relationship to SQL server reports. As such, the reports in Access are of no use and if your plan is to use SSRS, then the reports have to be built in SSRS.
It is possible to place an Access accDB data file on the server and have SQL server connect such data, but it generally does not allow or work well with multiple users.
Keep in mind, the reverse is certainly possible and often recommended. You place and keep all data on SQL server tables. You then link the Access application to SQL server. In this setup then the data ALWAYS resides on SQL server, but the reports are in Access. And the general forms etc. built in Access will save + send their data to SQL server (and this works without having to write code).
The above thus suggests that the Access application with the reports has to be distributed to users that need such reports. And such users will thus all share only ONE copy of the data since such data resides on SQL server. And this setup would also allow one to create reports in SSRS without having to upload any kind of data, since the live operating data from the Access application always resides on SQL server.
So in summary:
Access reports are Access reports, just like FoxPro reports are FoxPro reports, and FileMaker reports are FileMaker reports. As such, these reports cannot be used, viewed, or utilized by SQL server in anyway.
However, the reverse is not only possible, but is a common solution. Thus the Access (front end) is linked to SQL server and the data tables for forms, code, reports etc. for the Access application now resides on SQL server.
If you place the actual accDB data file from Access ON the SQL server, then SQL server can read the data, but any code, forms, reports etc. from Access cannot be used by SQL server. So a report in Access is of ZERO use to SSRS.
So if SSRS is a goal, then anything built in Access from a user interface point of view cannot be used. SSRS thus can only consume the data in tables.
Since SSRS can ONLY consume data from Access (and nothing else), then a far better solution in place of moving up a accDB file to the server is to simply push up the data from Access tables to a SQL server tables. And if such a data transfer is to occur often, then likely better is to ALWAYS keep the tables and data in SQL server, and have the Access front end part “link” to the data on SQL server. Access reports, forms and even VBA code will in most cases run as before, but the live data always resides in SQL server. You thus eliminate all the dance and song of attempting to transfer data between two systems. The SQL server data is thus always “live” and update to date, and only ONE copy of the table data EVER exists.
Most Access applications and reports and forms can work with very few (if any) modifications when you place the data tables on SQL server, and have the front end Access part “link” to SQL server.
Since a given specialized report in SSRS is going to require a pre-determined and non changing table structure, then the most prudent solution would be to have Access link to and use the data from SQL server tables (not the other way around).
So Access reports can ONLY be used by those with Access (or the free runtime) installed on each client desktop computer. Such Access reports have to be 100% re-built if your goal is to have such reports be used with SSRS.
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.
I'm a very new user to SSRS. I learned the basic things and am able to make reports using VS 2008 and BIDS. But I can't move further. I want to use the dynamic data source. My issues are:
First the user should input four credentials: a)Server name b) database name c) user id 4) password. It will help to make the connection with database and make the data source. The credential should be stored in session or cookie.
Now the user will be able to see all the reports without giving the credential because he/she has already given them.
I made a dynamic data source but the credentials are asked for every time I open a report.
Any demo project or an articles will be highly appreciated.
It sounds like SSRS alone will not accomplish what you want. SSRS will not provide a good interface for end users to create new datasources, or change existing datasources. There are some potential workarounds that get some of the functionality you desire, such as a method to change servers found at:
http://blog.softartisans.com/2011/04/19/how-to-create-a-dynamic-reporting-services-shared-data-source-using-linked-servers/
(requires the ability to use linked servers.)
But to manage the user session or cookies, you will need more than SSRS. The easiest way to get at this will be with a .NET web site to manage the credentials. It might be able to use a ReportViewer control, or other method of accessing SSRS, such as URL access, to get reporting functionality.
I am in the process of moving several Access databases into a SQL 2008 R2 server using Access 2007 Projects as the frontends and we're running into problems when users are trying to filter data from the forms.
Example:
I have one project file setup so that the users can search customer data and I'm using a login to the server that only has "CONNECT" and "SELECT" rights so they can't change any of the data. The only form in this project has it's record source set directly to the table, no views or queries. If a user selects the "Customer#" and then presses the "Filter" button, selects "Text Filter" and enters a customer number they get an "Enter a valid value" error (same thing happens if they select a field on the form and right click and try to set a filter). If the user uses the "Advanced/Filter By Form" there's no problems.
There are no other filters set on the form or in code, no input validations, just a plan form.
Anyone have any ideas where to start on debugging this?
Thanks.
At first, you need to confirm that it is a MSSQL permission issue. To check this - try the same with MSSQL user that doesn't have any permission restrictions. Then, you can use MSSQL profiler to look at what actual MSSQL statements are being sent by Access. I beleive that it is not the simple "SELECT", but it will be some system stored procedures calls (that's how Access works with MSSQL). Look at this trace and try to understand permissions that should be added. If your Access application works on the tables level, then may be it would be easier to deny update/delete instead of granting select only - not sure that it will help, but it's just an idea what you can try.
I would like to be able to programatically add a user to the report server by creating some stored procedure that accepts user_id and does inserts into ReportServer..Users and other associated tables. I am having trouble doing this (especially the column ReportServer..Users.Sid).
Has anyone been able to accomplish this in the past?
The end goal would be to have a script on my local PC that connects via osql to add users to the database so they can ad-hoc query and also add them to the report server so they can have access to the reports website. I have gotten the database access working...that was fairly easy. Having problems with report server.
Thanks!
You don't add users to RS this way. It's a seriously bad idea.
Why not just add "Everyone" into the "Browser" role? This is effectively what you are doing...