I have set up a SQL Reporting Services-server on a couple of VMs running on a physical server and I have encountered a strange problem. While setting up a subscription to a report the owner name will appear as expected, COMPUTER_NAME\USER_NAME but when editing the same subscription the domain name will have changed to something like WIN-XXXXXXXXX\USER_NAME. When setting up SSRS on other VMs running on the same physical computer the same happens, with the domain name being replaced with the same thing. It seems that somehow SSRS replaces the domain name with the name of the physical machine.
The VM itself is not on the domain, having only local administrator accounts which is the one owning the subscription. The account has been set up in SSRS with the appropriate permissions. The vm has not changed name since installing SSRS.
The problem is that SSRS won't recognize the new name so the scheduled reports won't run and I can't edit the schedules. After searching online I could only find one other person with the same problem and unfortunately no solution was suggested. Is there any way I force SSRS to use the machine name of the vm instead of the physical machine? Or if there's a workaround to the issue entirely?
I bet your SSRS instance lives in a separate VM than your web application and is not set up under the same domain. As a workaround could you test this with mixed mode authentication and a local user account named 'LocalReportSubscriptionCreatorAccount'.
UPDATE
Subscriptions
SET
OwnerID = 'LocalReportSubscriptionCreatorAccount'
Figured out a fix: It seems that only one user was affected by this weird behavior, creating a new user and adding it to the administrator-group worked.
Related
we are using SSIS 2016 and with parameterize connections. Every time we open the solution the connection manager is trying to connect with the credentials available in the project.param , due to unavailability of the password and repeated trying the db user account is getting locked.
Looking for some inputs if there is any settings we could change for connection manager not to try to connect when the solution is opened.
Thanks for your time on this.
RR
If you change the project setting to work in Offline mode, you should be able to open the project without validation checks firing which should alleviate the ever-so-fun lockout policy. That might be a user solution file setting so each team member might need to set it.
A different approach is to leave the design time user value to a non existent account. The run-time will swap in the properly parameterized connection but any developer opening the packages won't lock anyone out.
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.
I'm helping our SA migrate a reporting service instance to a new server and we're encountering a strange issue. She installed SSRS 2005 and restored the reporting services databases without any issues. She then restore the encryption key from the previous server without a problem.
But when we try to open report manager, it goes to the URL of our previous SSRS instance instead of the new one (i.e. when going to https://[new URL]/reports, it takes us to https://[old URL]/reports/pages/folder.aspx). The only way we can get to the current reporting service instance is by specifying the entire URL (i.e. https://[new URL]/reports/pages/folder.aspx). Also, when hovering over the links at the top (i.e. Home, Site Settings, etc), the hyperlinks also point to the old URL. I imagine this doesn't have anything to do with the database we restored, so we're wondering if this has something to do with the encryption key from the old server.
Sorry if this isn't clear, but any input is appreciated.
Okay, this is going back in time but we had the exact same problem. Testing my memory, I believe the server name is stored in the Keys table in the ReportServer database in the column MachineName. That will be your old server name.
Take a backup!
Change it to your new server name.
Restart the Reporting Services service.
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 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.